ProwlFi documentation

Confidential payment infrastructure for AI agents on Solana. This guide covers the cryptography, the threat model it closes, the agentic economy framing it unlocks, and the three surfaces it ships through — SDK, MCP server, and REST API.

Introduction

ProwlFi is an agent-native value transfer layer built on Solana. The link the public ledger exposes — who paid whom, how much, and when — is the surface area ProwlFi removes. Stealth addresses make every payment land at a fresh, single-use destination; x402 carries those payments over plain HTTP so agents can transact without an account, an API key, or a monthly invoice.

The design goal is narrow and concrete: break the on-chain link between an agent's public identity and the addresses it transacts with, while preserving the operator's ability to audit every payment. ProwlFi is a noise-and-link-cut tool. Each payment is a directed one-to-one stealth transfer, recoverable with a viewing key held by the operator.

What you get

• Single-use stealth addresses — derived per payment, on ed25519. No address reuse, no clustering.
• Client-side cryptography — your seed never leaves the agent's process, on Solana or off. No custody.
• Gasless sweeps — SOL + SPL fee-sponsored via a Kora-style facilitator. No SOL pre-funded at a destination.
• x402 stealth payments — HTTP 402 challenges settle into a fresh stealth address, unlinkable on-chain.
• Three surfaces — SDK, MCP server, REST API. Same engine, same guarantees.
• Viewing keys — the operator exports a complete, attributable audit trail on demand.

The agentic economy

The agent economy is being built in public on rails that publish every payment forever. Humans tolerate this because most consequential transactions are low-frequency and few signals reach the public ledger. Agents invert that: they transact continuously, in the open, with strategy encoded into every move.

What today's public-by-default ledger looks like for an autonomous agent:

• Every fill, rebalance, and hedge published to a pumpable graph.
• Every API call paid for revealed as the customer-vendor link, in the clear.
• Every counterparty, settlement timing, and amount permanently linkable.

ProwlFi closes this address layer so the agent can keep operating on public-infrastructure Solana liquidity, standard wallets, without surrendering its strategy to anyone with a block explorer. Critically, none of this requires a new chain, a new metalayer, or a new wallet — the noise-and-link-cut happens at the destination, and the rest of the agent's stack stays the default.

Stealth addresses 101

A stealth address is a one-time destination only the recipient can spend from, derived freshly for each payment. The recipient publishes a single, long-lived meta-address; senders use it to compute unique destinations that cannot be correlated to one another or back to the meta-address.

The protocol, briefly

1. The recipient generates two keypairs — a spending key and a viewing key — and publishes their public halves as a meta-address (prowl:<spend>.<view>).
2. To pay, the sender generates an ephemeral keypair and combines its private half with the recipient's public keys to derive a unique stealth address.
3. The sender publishes the ephemeral public key in an on-chain announcement and sends funds to the stealth address.
4. The recipient scans announcements with their viewing key, recognizes payments meant for them, and derives the matching private key to spend.

// recipient: one meta-address, published once
const meta = agent.metaAddress()
// "prowl:8Qk…spend.3rT…view"

// sender: derive a fresh destination, client-side
const { address, ephemeral, viewTag } =
  await agent.stealth(meta)

await agent.send({ to: address, amount: 25, token: "USDC" })
await agent.announce({ ephemeral, viewTag })

View tags

Scanning every announcement on-chain would be expensive. The published sRFC includes a one-byte view tag: a one-byte hint derived alongside each payment. A recipient checks the tag first — a single byte comparison — and only performs the full derivation on the ~1-in-256 announcements that match. ProwlFi's scan handles view-tag filtering automatically.

x402 stealth payments

x402 (Payment Required) was reserved in the original spec and stayed effectively unused for decades. With an open USDC + SPL settlement layer on Solana, it becomes the natural way for one agent to charge another over plain HTTP. ProwlFi adds the missing privacy layer: the payment lands at a stealth address, not at a fixed, public account.

The flow

1. An agent calls a vendor endpoint.
2. Vendor responds 402 Payment Required with payment terms — amount, token, recipient meta-address, x402 version.
3. ProwlFi derives a fresh stealth address from the meta-address; the sender signs an SPL transfer authorization.
4. The agent retries with the signed envelope in the X-PAYMENT header.
5. A facilitator confirms settlement; the vendor serves the resource and the stealth address vanishes into the graph.

The on-chain footprint is one transfer to a one-time address, plus one announcement. Nothing links the buyer to a vendor-facing public account. The buyer's wallet is opaque to the public — but the receipt is verifiable to the buyer, and the audit trail is recoverable to the operator.

// vendor: gate any route behind x402
import { x402 } from "@prowlfi/server"

server.use("/infer", x402({
  price: "0.02 USDC", to: meta, chain: "solana"
}))

// agent: pays automatically on 402, unlinkably
const res = await agent.fetch("https://api.vendor.xyz/infer")
// → 402 → derive stealth → sign → retry → 200

The same primitives are available as payX402 on the client side, as x402_pay on MCP, and as POST /v1/x402/pay on REST. Try the live demo in the SDK reference.

Threat model

ProwlFi is designed against a specific adversary: a passive on-chain observer with full visibility of Solana's public ledger and unbounded analysis budget. This is the realistic threat for an autonomous agent — competitors, MEV searchers, and analysts who reconstruct strategy from the transaction graph.

Stealth addresses cut linkability at the address layer. They do not encrypt the transferred amount (an EVM equivalent, BN-254 confidential amounts, is a separate roadmap track) and do not defend against a compromised host. Read the limitations for the full boundary.

Privacy invariants

These properties are guaranteed by construction. They hold as long as the underlying cryptographic assumptions (ed25519 / curve25519 ECDH, Keccak-256 KDF) hold and a correct viewing key is held by the operator.

• Unlinkability — no two stealth addresses derived for the same recipient can be linked to each other, or to the recipient's meta-address, without the viewing key.
• Non-custody — ProwlFi never holds, escrows, or pools user funds. Spending authority for every stealth address remains solely with the recipient's spending key.
• Operator auditability — the holder of the viewing key can deterministically recover the complete set of payments to a meta-address, without revoking or revealing spend authority.
• Selective disclosure — a viewing key can be shared with an auditor to reveal incoming payments without granting spend authority, and without revoking live strategy.
• No plaintext amounts in error strings — ECDH error states and facilitator failures never echo amounts, addresses, or signature bytes.
• Spend-key-never-exfiltrates — the spending key never leaves the agent's process; it is derived from the master seed and stays client-side.

Architecture

ProwlFi is three layers: a thin on-chain program, a pure-TypeScript privacy engine, and three surfaces. Your agent can call it anywhere. Everything cryptographic happens client-side.

On-chain program

A single Anchor program, deployed on Solana mainnet:

• Announce — emits the ephemeral public key + one-byte view tag per payment. Append-only, no state read on the hot path.
• Registry — optional meta-address registry so an agent can resolve prowl:<handle> to a published meta-address.
• Sweep — fee-sponsored forwarder so a stealth address with no SOL can be swept gaslessly by a facilitator.

All four are source-verified on Solana.fm and deployed at a stable program address. Addresses are on the status page.

Privacy engine

The core: key derivation, view-tag scanning, x402 payment planning, and receipt verification — all pure client TypeScript with zero network dependencies beyond an RPC endpoint. The seed never leaves the agent. No ProwlFi server sits in the payment path.

Three surfaces

One engine, three integration shapes — pick the one that matches your runtime:

For full coverage — install commands, signature types, and error tables — see the SDK reference.

Limitations

ProwlFi is explicit about its boundary. The following are out of scope and should be addressed separately in any production deployment:

• Network-layer privacy — ProwlFi breaks the on-chain link, but RPC and endpoint calls still reveal IPs. Route agent traffic through a proxy or mixnet if network metadata matters to your threat model.
• Confidential amounts — transfer values are visible on Solana today. Amount obfuscation (BN-254 confidential transfers) is a scoped roadmap track, not yet shipped.
• Timing correlation — a passive observer can correlate by timing. Batching and jitter help; a determined analyst with low payment volume may still narrow the set.
• Host security — ProwlFi protects the ledger, not the machine. A compromised agent host exposes the master seed. Use a TEE, HSM, or hardware signer for high-value agents.
• Independent audit pending — the stealth scheme and on-chain program are scoped for third-party audit. Until that completes, treat mainnet usage accordingly.