Escrow that releases on proof.
AI agents can pay for anything. Nothing can prove they got what they paid for. veedor holds the money against a machine-readable job spec and moves it only when a verifier signs evidence bound to that exact job, that exact spec, and that exact evidence.
Built for physical work, where the payment rail cannot see whether anything happened.
- Spec
- width 40.0 mm ± 0.2spec a3f9…c21e
- Evidence
- measured 39.9 mmsigned by verifier
- Check
- deviation 100 µm against a 200 µm tolerance
- Verdict
- Released to provider
Payments are solved. Settlement is empty.
Agent payment infrastructure shipped in the last year and works. OpenAI and Stripe published the Agentic Commerce Protocol, Google published AP2, and Coinbase's x402 directory lists thousands of services that take payment over HTTP. Read their specs and the post-payment column is empty. Every one of them delegates fulfillment liability to the merchant.
That has consequences already. OpenAI shut down Instant Checkout in March 2026 citing fraud and tax operations. Marketplaces where agents hire humans verify delivery with evidence self-reported by the party that gets paid.
Payment rails cannot close this themselves. Stripe absorbed fraud scoring because it sees the transaction. Nobody on the rail can see whether a printed part matches its tolerance, or whether a box arrived. That happens off-rail, and it needs a neutral party holding the money.
How a job settles
-
The spec is written down and hashed.
Dimensions, tolerances, delivery deadline. The hash goes on-chain with the job. No sequence of events can change the amount, the verifier, the arbiter or the spec mid-flight.
-
The buyer funds the escrow.
The tokens sit in an account whose only authority is the job itself. Nobody holds a withdrawal key. The money can only go to the provider or back to the buyer.
-
The provider delivers and submits evidence.
Measurements, timestamps, attachments, hashed into a bundle. Submitting starts the review clock.
-
A verifier checks numbers against numbers.
Deviation against tolerance, delivery time against deadline. What an instrument can settle, the machine settles. What it cannot measure, it refuses to sign and names the items a human has to rule on.
-
Money moves on the signature.
Pass releases to the provider. Fail refunds the buyer. The signature covers the job, the spec, the evidence and the verdict, so it cannot be moved between jobs or outcomes.
When things go wrong
- The buyer disputes. An arbiter rules, and the arbiter is never the verifier. Nobody rules on a complaint about their own inspection.
- Nobody shows up. No evidence by the deadline refunds the buyer. A silent verifier releases to the provider, who already handed over the work. An absent arbiter cannot trap the money: disputes lapse.
- A machine cannot judge it. "Does the material match?" has no instrument. The server returns inconclusive instead of inventing a verdict.
It runs. A job settled end to end.
Every claim on this page can be checked. The program is deployed, the transactions are public, and the verdict below was printed by the same run.
One job, creation to settlement, narrated. 60 seconds.
| Step | State after | Transaction |
|---|---|---|
| create_job | Created | 2FScXRTz… |
| fund | Funded | 5gqyXVmc… |
| submit_evidence | Under review | 3DN6tqjY… |
| release | Released | 5kjR36gG… |
Passed 'dims': measured deviation 40um against a 200um tolerance
Passed 'on_time': delivered at 1784552408, deadline was 1784556002
assessment PassProgram 8YpCfYtC…CQfJ on devnet. 182 automated tests across the state machine, client, program and services, plus 9 formal proofs on the core.
The verifier network
veedor already ties a signature to exactly one job, one spec and one piece of evidence. The next layer puts that signature in the hands of whoever takes the measurement: a third-party verifier who signs the reading they took, or an instrument with its own key that signs the reading directly, so the provider never touches the number.
The first verifiers already exist. The marketplaces this is built for arbitrate deliveries by hand today; their reviewers are the verifier supply, and veedor is the settlement rail their signature moves money on. Provider, verifier and arbiter are held apart by separate signing domains, with tests that replay one as the other and require it to fail.