Agent payments
Agent payments settle on promises. They should settle on proof
AI agents can now pay per request on Solana in seconds. But a payment only proves someone agreed to pay, not that the work was done. A design for settlement that waits for evidence.
PrizenLabs//4 min read/5 sources
- The problem
- x402 and payment channels let agents pay for APIs and compute, but settlement is blind to whether the inference ran, on which model, or how many tokens it really used.
- Our proposal
- Settle only against two signatures: the agent's spending voucher and a usage receipt signed inside the provider's attested enclave, with payments stopping the moment attestation lapses.
In May 2026 the Solana Foundation and Google Cloud launched Pay.sh, a gateway that lets agents pay for APIs per request in stablecoins, with no account and no API key. It builds on x402, the HTTP payment standard, and the Foundation now ships payment building blocks in nine languages. Agents paying machines is no longer a demo.
What it still is, in most implementations, is trust on credit. A payment proves the payer authorised an amount. It does not prove the provider delivered.
The problem: settlement is blind to delivery
Take an agent buying inference from a GPU provider. Today the flow is roughly:
- 01The agent sends a request with a payment, or opens a payment channel with a spending ceiling.
- 02The provider runs something and returns a response.
- 03Money moves according to what the provider reports.
Nothing in that flow proves the inference ran at all, that it ran the advertised model rather than a cheaper one, that it ran on the hardware claimed, or that the token count billed matches the work. For a person buying one API call, that risk is tolerable. For an agent making ten thousand calls an hour on an owner's budget, it is the whole problem.
Why the usual fixes fall short
- Reputation and ratings come after the fact and can be farmed. We cover that separately in reputation that cannot be bought.
- Escrow with disputes works for large purchases. It does not work at a cent per call.
- Trusting the provider's logs puts the party being paid in charge of the meter.
The proposal: attestation-gated, metered settlement
The fix is to make the meter something the provider cannot fake. Confidential computing gives us that: a trusted execution environment (Intel TDX or AMD SEV-SNP, with GPU confidential computing) can generate a key inside the enclave and produce a hardware attestation that the key belongs to a specific, measured workload.
So every settlement needs two signatures:
- A voucher, signed by the agent's session key: "I authorise up to X in total."
- A usage receipt, signed by the key generated inside the provider's enclave: "this enclave served N units."
The program pays the minimum of the voucher, N times the price, and the deposit, and only while the provider's attestation is valid. If a verifier revokes the attestation, payments stop and the payer can exit immediately.
We built this as an open-source Solana program, AgentsPay, with five modules: an attestation registry approved by an M-of-N verifier committee, attested payment sessions, agent vaults with per-session caps and a kill switch, compute credits backed one to one by escrow, and ratings that can only come from sessions that settled real value. On devnet, one transaction settles several paid inference calls and refunds the rest.
What this changes for each side
- Agents and their owners pay for measured work, and the budget lives in an onchain vault with limits, not in a prompt.
- Providers can prove they ran what they sold, which is a selling point against cheaper, unverifiable competitors.
- Protocols can gate access on attested providers, and tokenise GPU capacity with credits that refund at par if the provider defaults.
Where it gets hard
Attestation is only as good as the measurement policy: someone has to decide which workload images are approved, and that committee is a trust assumption to make visible and decentralise over time. Simulated enclaves are fine for development and useless as a security boundary. And prompts sent to a provider should be sealed to the enclave key, or the provider's host can still read them.
What to measure
- Settled versus billed. The share of provider claims that settle in full against an enclave receipt. Anything well below 100 percent is either a bug or a dispute worth understanding.
- Attestation uptime. How long each provider's attestation stays valid, and how fast payments stop after a revocation.
- Refund rate. How much of each deposit returns to the payer unused; a healthy channel refunds what it did not need.
- Cost per verified unit. Price per thousand tokens or per GPU-second that was actually proven, compared with unverified providers.
How we would start
For a team selling compute or APIs to agents, the first step is small: put an x402 paywall on one endpoint, then move metered customers to channels with enclave receipts. For a team building agents, give each one a vault with caps and an allowlist before giving it a budget. Both are part of our onchain AI agents and Solana work, and close to what we built for Zynd AI.
Sources
- 01AgentsPay: attestation-gated metered payments for AI agents on Solana (GitHub)
- 02Solana Foundation: Pay.sh launched with Google Cloud
- 03Solana Foundation pay-kit: x402, MPP and AP2 building blocks (GitHub)
- 04AI on Solana
- 05x402: an open payment standard for the internet
Figures are as reported by the sources on the date above. Where sources disagreed, we say so in the text. Nothing here is legal or investment advice.