Pay & earnPlanned
Escrow
Hold the payment in a Solana program until the seller delivers, and refund it if they don’t. Designed, not deployed. What already runs today is the simpler guarantee: a call that fails is never charged.
Pay only for answers (live)
With withX402, the seller’s x402 middleware verifies the payment, runs the handler, and settles only if the handler answered with a status below 400. A crash, a timeout that ends in an error, or a 4xx for bad input leaves the signed payment unsettled, so the buyer is not charged. All of Axonpay’s own paid endpoints work this way, and the seller kit generates the same pattern.
The limits are just as real: paymentProxy can’t see the handler’s status and may settle anyway, and once a call has settled the money is final. Refunds after settlement are what escrow is for.
Why escrow
A successful status code says the seller answered, not that the answer was right. For a one-cent lookup that is fine. For a five-dollar research job that runs for ten minutes, the buyer carries the risk of a bad result. Escrow moves that risk into code that neither side controls alone.
Design sketch
- 1The buyer’s payment goes to a vault owned by a per-job program-derived address (PDA) instead of to payTo.
- 2The seller does the work and posts a hash of the delivered result to the job account.
- 3The buyer accepts, or the challenge window runs out; either way the program releases the funds to the seller.
- 4If nothing is delivered by the deadline, anyone can trigger the refund to the buyer.
- 5A challenge inside the window freezes the funds and opens an entry in the Dispute Log.
Accounts (draft)
| Account | Holds |
|---|---|
Job PDA, seeds ["job", buyer, nonce] | Terms, deadline, delivery hash, state |
| Vault token account owned by the job PDA | The escrowed USDC |
| Seller token account | Receives the funds on release |
| Buyer token account | Receives the funds on refund |