home›Agentic Systems›

How ProwlFi Enables Confidential Solana Transactions for AI Agents

Leverage stealth addresses and x402 HTTP payments for private, auditable on-chain activity without sacrificing security or using special tokens.

June 7, 2026

#Agents #Automation #Dev Tools #LLM #Open Source

ProwlFi provides infrastructure for Solana-based AI agents to achieve transaction confidentiality using single-use stealth addresses and x402 HTTP payments. Learn how it offers a private, auditable trail for operators while keeping payments unlinkable and invisible to the public, all on standard Solana infrastructure.

What ProwlFi Does

ProwlFi brings transaction confidentiality to Solana-based AI agents. It combines stealth addresses with x402 HTTP payments so every payment lands at a fresh, unlinkable address while the operator keeps a private audit trail.

The problem is clear: a public ledger exposes every payment an agent makes — who it pays, how much, and when. For autonomous agents transacting constantly, this leaks strategy, relationships, and cash flows.

ProwlFi solves this by letting recipients publish one long-lived meta-address. Senders derive a new single-use destination for each payment. The resulting addresses are cryptographically unlinkable. A viewing key lets the operator scan the chain and attribute all payments privately. Confidentiality is from the public, not from the operator.

The system works on standard Solana with regular wallets and SPL tokens — no special tokens or mixing required.

Getting Started

Install the SDK from npm:

npm install @prowlfi/sdk

The SDK is TypeScript-based and runs in Node.js. Create a Prowl instance with a single option:

import { createProwl } from "@prowlfi/sdk";

const agent = createProwl({ chain: "solana" });

The chain parameter initializes the derivation engine, key material, and internal state. No environment variables or additional configuration files are needed.

The meta-address format is prowl:<spend>.<view>, encoding the recipient’s public spend and view keys. The SDK surfaces three interfaces — TypeScript SDK, MCP server, and a REST API — though configuration details for the latter two are not yet documented.

Making an x402 Payment

Use agent.payX402() to pay an agent endpoint identified by a Prowl meta-address. You specify the HTTP endpoint, amount, and token:

const { receipt } = await agent.payX402({
  url: "https://api.vendor.xyz/infer",
  to: "prowl:vendor-7",
  amount: 0.02,
  token: "USDC",
});

Under the hood this resolves the recipient’s meta-address, generates an ephemeral keypair, derives a one-time stealth address, sends an HTTP request, settles the payment on-chain, and emits an announcement containing the ephemeral public key plus a 1-byte view tag.

The dormant HTTP 402 Payment Required status code becomes a working settlement layer — agents pay each other directly over HTTP, with funds landing at freshly derived addresses.

Scanning and Sweeping

On the recipient side, scan for incoming payments using the viewing key:

const incoming = await agent.scan(agent.viewingKey());

The scan method fetches on-chain announcements and filters them using the 1-byte view tag, discarding roughly 99.6% of irrelevant data immediately. For the remainder, it attempts derivation with the viewing key to recover spendable keys, returning a list of addresses and amounts.

The SDK also supports gasless sweeps — moving funds from stealth addresses without requiring SOL at the destination. The protocol can bundle sweep transactions or sponsor gas fees, though exact mechanics aren’t detailed in the current documentation.

Constraints and Limitations

Several important constraints apply:

Unaudited — The stealth scheme and on-chain program are in active development and not yet audited. Mainnet usage is at your own risk.
Amounts visible — While recipient identity is hidden, payment amounts remain on-chain. Confidential amounts (using BN-254) are on the roadmap.
Solana-only — Currently supports only Solana mainnet. Cross-SVM coverage is planned.
Confidentiality, not anonymity — The operator with the viewing key can attribute all payments. This is not a mixer.
No migration steps — No information about contract upgrades, versioning, or data migration is provided.

Best Practices

Secure the viewing key — It is the sole link between unlinkable addresses and the agent’s identity, enabling a complete audit trail.
Non-custodial design — Spending keys derive from your seed and never leave your process. Never share the seed or spend key.
Use SDK abstractions — Payment logic, announcement scanning, and sweeping are handled for you. Don’t manually derive stealth addresses unless you fully understand the cryptography.
Monitor audit progress — Limit exposure until an independent audit is completed. Follow project updates for when that milestone is reached.

For security vulnerability reports, refer to the SECURITY.md file rather than public issues.

GitHub