The problem
x402 turns an HTTP request into a payment. A client asks an API for a resource, the server answers "402 Payment Required", the client pays in USDC, and the resource comes straight back. That works well when one buyer makes one request, which is the usual case for machine-to-machine micropayments.
Some things are only worth making if enough buyers pay for them, such as a dataset, a report or a group trip. Paying first means carrying the risk alone, and nothing in x402 lets a buyer say "only if enough of us pay".
What we built
An escrow application on Algorand that holds standard x402 USDC payments against a deadline and a release condition, along with the x402 server, the web app and the operator tooling around it.
There are two release conditions. A quorum agreement releases the money once enough distinct buyers have joined. A hash agreement releases it when the delivered file's sha256 matches a commitment written on-chain before anyone could pay. One agreement can require both.
On MainNet, Earnest sells the Algorand x402 Route Index, a paid report built by probing every x402 endpoint in the facilitator's directory (2,257 of them for the latest edition). Each edition is produced and hashed before its seats open. On TestNet, a free demo called Earnest Travel lets three travellers fund a sample group trip with test USDC.
None of this changes x402. Each buyer's payment is a standard exact payment, grouped atomically with a join call, and the facilitator settles it like any other.
How it works
- The seller opens an agreement with a seat price, a number of seats, a deadline and the sha256 of the file to be delivered. All of it is written on-chain before anyone can pay.
- Each buyer pays over x402. The USDC goes to the escrow application's account, never to the seller.
- The contract counts the seats, one per wallet.
- When the seats fill and the seller releases bytes that match the committed sha256, the money goes to the seller and every buyer gets the file. The release transaction carries the file's IPFS address, so buyers can hash what they receive.
- If the seats don't fill, or the file isn't released by the deadline, every seat is refunded on-chain to the wallet that paid. Anyone can trigger the refunds.
Engineering highlights
Cannot be changed or deleted
The contract has no update or delete path, so the program you verify is the program that runs for the life of the application.
Pausing cannot trap money
The admin's pause flag only blocks new agreements and new payments. Refunds and releases ignore it.
Refunds don't need us
After the deadline, anyone can trigger expiry and refunds, including any buyer. 47 test cases cover that path.
No race at the deadline
A release must land before the deadline. After it, the only possible path is the refund.
Reproducible build
The compiler version is pinned. Anyone can hash the deployed program and the committed artifact and get the same digest.
Identical bytes across languages
Shared test vectors make the TypeScript and Python payment builders produce byte-identical transaction groups.
How it was built
One senior engineer directed AI coding agents against six written specifications: the escrow contract, the pool client, edition release, the delivery-escrow backend and client, and discovery and attribution. The specifications defined the system, the agents sped up the build, and the tests decided what shipped.
Three CI jobs run 1,477 tests on every change: the contract on a local Algorand network, the Python backend and the React client. CI also checks that the committed compiled contract matches a fresh build. Real TestNet settlements, including a full expire-and-refund run, were rehearsed before anything touched MainNet.
Status, stated plainly
Live with real USDC since September 2026, and both outcomes have happened on-chain. Edition 1 did not fill: two buyers joined, the edition was not published, and the contract refunded both. Edition 2 filled: five buyers joined, and the release paid the seller 25 USDC on .
There is one limit. For a hash agreement, the contract guarantees a refund if the file does not arrive, but it cannot guarantee delivery. It checks that released bytes match the commitment; it cannot force the seller to release them. The deadline is what enforces the refund, and the project's README says so openly.
Volumes are small. This shows the mechanism working with real money; it is not a claim of traction. The delivery-escrow route is built up to settlement only and is switched off on the live hosts.
As of .
Verify it yourself
- The escrow is live on MainNet Open application 3710645149 on Lora to see the escrow application and its transactions.
- What runs is what's published Follow the README's three verification steps. The deployed program and the committed artifact both hash to 9413f24811ab11b4ed0006da32f4f10741996e11f9019415c45e300087a0b647
- Edition 2 paid out The release transaction moved 25 USDC from the escrow to the seller, with the edition's IPFS address in the note.
- Edition 1 was refunded The refund transaction sent 5 USDC back to each of the two buyers. One of the buyers triggered it.
- The tests pass The latest CI run on main passed 140 contract, 511 API and 826 web tests.
- The limit is documented Read "The limit, stated plainly" in the README.