Your agent has a strategy.
The chain has a copy.
Every x402 payment is public by default. Who paid, who got paid, how much — forever. Connect the receipts and anyone can reconstruct your agent's next move.
Your strategy. On display.
YourAgent…7Qxyour identityDataAPI…k2Pthe seller0.25 USDCstandard modeforeveryour playbookA payment from nobody.
shielded_poolnot your walletDataAPI…k2Pthe seller0.25 USDCstandard modenoneno path back to youPrivacy should be the default, not a workaround. Kage breaks the link between your wallet and your payments.
Shield once.
Pay anywhere.
The slow part happens before the payment.
The private part happens on every payment.
Shield↗
Move USDC into your self-custodied shielded balance. Only your keys can spend it.
Prepare↗
Prepare privacy proofs in the background, before your agent ever sees a price.
Pay↗
Your agent signs with its own keys. The facilitator verifies and settles the payment.
Delivered↗
The seller receives USDC and serves the request. No public link to your wallet.
APILLMDATAHow much should
the world see?
Same payment. Anonymous payer.
Compatible with standard x402 middleware. The seller receives USDC from a prepared pocket funded by the shielded pool — never directly from your agent's wallet.
Keep your middleware.
Change one URL.
Your endpoints. Your prices. Your wallet. Kage fits into the x402 flow you already know — with standard /verify and /settle routes.
01 import { HTTPFacilitatorClient }
02 from "@x402/core/server";
03 // The only thing that changes.
04 const facilitator = new
05 HTTPFacilitatorClient({
06 url: "https://your-kage-node
.example/x402",07 });
08 // Keep everything else.Act autonomously.
Pay anonymously.
The private balance belongs to your agent.
Not a platform. Not a custodian. Not us.
Keys are created, kept, and used on your machine.
$ kage balance
$ kage pay api.example/v1/inference
$
Your keys never leave.
On-device signing. Self-custodied private notes. No hosted wallet quietly holding your money.
Built for the machine loop.
Prepare ahead, handle a 402, sign, and continue. Privacy fits into the workflow — not on top of it.
Your spending isn't a signal.
Keep your research, suppliers, and strategy out of a public wallet-to-seller payment graph.
Open to inspect.
Private to use.
Know the protocol before you trust the rail.
Read the flow, inspect the examples, and try the difference.
No black boxes.
Just answers.
For the standard private path, sellers keep their x402 middleware, endpoint, USDC pricing, and receiving wallet. The integration changes the facilitator URL. Confidential and fully shielded modes require the corresponding scheme support, and fully shielded receiving needs a seller-side key process.
The agent's keys stay on its own machine. The self-custody design means only those keys can authorize spending from its private balance. A facilitator verifies and relays settlement; it is not intended to become an account-based custodian. Secure implementation, recovery handling, and independent audits are essential before a real deployment.
Explore the payment flow, read the seller integration guide, or open the agent manual. Onchain payments require a deployed facilitator and a compatible wallet.
No. Standard mode hides the payer but leaves the receiving seller and payment amount visible. Confidential mode is designed to hide the amount too; fully shielded mode also protects the payee. Network metadata, deposits, timing correlation, and a small anonymity set can still affect privacy. See the privacy notes in the documentation.