---
title: Paid on proof, settled in silence
summary: pAI, a private and proof-conditioned settlement protocol for AI agents on Robinhood Chain.
version: Draft v0.2
date: October 2026
---

> **What is live.** The delivery proofs are live on Robinhood Chain: PaiEscrowV2 refuses any order without a valid Groth16 proof that the encrypted delivery opens, under the key the payment is locked against, to exactly the committed content. Amounts and addresses are public today; the shielded escrow in section 4 is the next step. The [status page](/docs/overview/status-and-roadmap) tracks what runs.

## Abstract

Autonomous agents are becoming buyers and sellers of work: data, inference, code, research. They need a way to pay each other that is safe without trust and that does not publish their business. Today they have neither. A plain transfer is final whether or not the work arrives, and it is readable by anyone. pAI is a settlement protocol in which a payment is locked only against a delivery proven in zero knowledge, released only when the seller reveals the key that opens it, and refunded by the clock otherwise. Its next step records each settlement as a nullifier with no amount and no parties. This paper describes the problem, the design, its limits and the role of the $PAI token.

## 1. The problem

Two facts about agent payments make them different from human ones.

First, agents transact often and in small amounts, with counterparties they have never met. There is no reputation to lean on, no customer service, no chargeback. A buyer that pays first is exposed to a seller that never delivers. A seller that delivers first is exposed to a buyer that never pays. Human commerce solves this with intermediaries and courts. Agents cannot wait for either.

Second, an agent's payments are its strategy. A trading agent that pays a particular signal provider every hour has told the world which signals it trusts. A research agent that buys from the same three data vendors has published its sources. On a transparent chain, the payment history of a successful agent is a recipe anyone can copy.

Existing tools address one fact or the other. Escrow contracts solve counterparty risk but publish everything. Shielded pools hide transfers but know nothing about delivery. pAI is designed for both at once.

## 2. Design goals

1. **Conditional.** Funds move only if the delivery satisfies conditions both sides committed to before any money moved.
2. **Private.** Amounts and counterparties never appear on-chain. Only the parties, and whoever they share a viewing key with, can read the terms.
3. **Arbiter-free.** No human or committee decides outcomes. The proof decides, or the clock does.
4. **Agent-native.** The protocol plugs into how agents already pay for resources, in particular the HTTP 402 flow known as x402.
5. **Honest about limits.** What cannot be proven is not promised.

## 3. Protocol overview

A pAI payment, as it runs today, has four steps. It is a zero-knowledge contingent payment.

**Prove.** The seller encrypts the delivery `D` with a one-time key `k` as a Poseidon keystream, `C[i] = D[i] + Poseidon(k, i)`, and produces a Groth16 proof that `Poseidon(k) = keyHash`, that the ciphertext hashes to `cHash` and that the plaintext hashes to `dHash`. It hands the buyer the ciphertext, the three public values and the proof. The key stays with the seller.

**Lock.** The buyer verifies the proof and checks the ciphertext against `cHash`, then opens an order: seller, asset, amount, deadline, a salted commitment to its terms, the public values and the proof. The escrow contract verifies the proof itself. No valid proof, no order.

**Reveal.** The seller claims the order with `k`. The contract checks `Poseidon(k) = keyHash`, pays the seller minus the protocol fee and records `k`.

**Open or refund.** The buyer, the only holder of the ciphertext, decrypts it with `k` and gets exactly the content behind `dHash`. If no key arrives before the deadline, anyone can return the funds to the buyer.

## 4. Privacy model

Today the terms are a salted commitment, the delivery never touches the chain and the proof reveals neither; the amount and both addresses are public like any transfer. The next version moves the money itself out of view. In it, the escrow is a single pool per asset. Every locked payment is a note inside it. The contract knows its total balance and the root of the commitment tree, nothing more.

An observer sees: deposits into the pool, the creation of commitments, output hashes posted against order hashes, and nullifiers spent with valid proofs. An observer does not see: which deposit funded which order, the amount of any order, the identity of the buyer or the seller.

Each agent derives a read-only viewing key. With it, the agent, or anyone it chooses, can decrypt its own notes in full. This gives agents and their owners clean books and gives auditors a path to verify activity, without exposing anything to the public.

The protocol does not hide timing, and it cannot hide amounts at the boundary when funds enter or leave the pool from transparent addresses. The anonymity set is the set of active users of a pool, so privacy improves with adoption. The SDK mitigates amount matching by splitting deposits into standard denominations.

## 5. Delivery proofs

The live circuit proves one statement, the one every sale needs: the delivery the buyer will unlock is exactly the content committed in the order. It covers deliveries of up to 1 953 bytes in 46 095 constraints, proves in a few seconds in a browser tab, and is verified on-chain by a snarkjs-generated Groth16 verifier. The trusted setup uses the public Perpetual Powers of Tau ceremony for phase 1 and, for now, a single contribution for phase 2; a multi-party phase 2 ceremony replaces it next.

Further conditions combine with it, each as its own circuit:

- **Schema**, for structured outputs that must parse and validate.
- **Signed source**, for data that must come from a whitelisted signer.
- **Test suite**, for code that must compile and pass named tests, proven in a zkVM.

A proof says nothing about quality beyond what the conditions express. pAI does not try to judge whether a report is good. Buyers who care about quality express it as something checkable: a held-out test set, a scoring program with a threshold, a signature from a reviewer they trust. This is the price of removing the arbiter, and it is paid knowingly.

## 6. x402

x402 lets an HTTP server answer `402 Payment Required` with payment terms, and lets a client pay and retry in the same exchange. pAI keeps this handshake and adds the proof to it. The server's 402 carries its answer encrypted, with the proof of what it is. The client verifies the proof, locks the price in escrow against it, and retries with the order id in a header. The server claims the order, which reveals the key, and the client decrypts the answer it already holds. A live endpoint and a buyer agent that pays it run on Robinhood Chain today.

## 7. Provers

Sellers can prove for themselves. For heavy proofs, they can hire a prover from an open network. Provers register by staking $PAI. Stake caps the volume a prover may carry at once. A prover that relays an invalid attestation, or withholds a proof it was paid to produce until an order expires, is slashed, and the slashed amount goes to the harmed party.

Provers see the output they prove over, but never the amount: the payment terms are not inputs to the delivery circuit. Sellers who cannot share the output with anyone prove locally.

## 8. Token

$PAI launches on Pons on Robinhood Chain. It has two functions in the protocol.

**Fee sink.** Each settlement pays a protocol fee, a fraction of a percent of the settled amount, capped in the contract. Fees are used to buy $PAI on the market and burn it.

**Prover collateral.** Provers stake $PAI to serve orders and lose it when they misbehave.

The token has no governance over individual settlements and no ability to reverse them. Parameter changes are subject to a delay so that users can exit before they apply.

## 9. Security considerations

- **Soundness.** The protocol is only as sound as its circuits and their setup. The delivery circuit ships with its source, its specification and Foundry tests against real proofs, including tampered ones. Its phase 2 setup has one contribution today; whoever held that randomness could forge proofs, which is why a public multi-party ceremony comes first on the roadmap.
- **Deposit caps.** Early mainnet pools carry deposit caps that rise with time and review coverage.
- **Liveness.** Refunds depend only on the buyer and the clock. A seller or a prover going offline cannot trap funds past the deadline.
- **Key loss.** Losing a spending key loses access to notes, as with any self-custodied wallet. Viewing keys cannot spend.

## 10. Roadmap

1. Multi-party phase 2 ceremony for the delivery circuit, then a new verifier.
2. SDK alpha with local proving.
3. x402 middleware for any server.
4. Schema and signed-source circuits.
5. Chunked proofs and a prover network for larger deliveries, with prover staking in $PAI.
6. Shielded escrow: pool, tree, nullifiers, viewing keys, with deposit caps after external review.

## 11. Conclusion

Agents will pay each other at a scale no human market has seen. If every one of those payments is final on send and readable by all, agent commerce will be either unsafe or public, and usually both. pAI proposes a narrow fix: lock the money against a commitment, let a proof open it, let the clock refund it, and let the chain record only that it happened. Paid on proof, settled in silence.