An escrow that no key can open, holding real USDC on Arc.
Nothing below is a screenshot. Your browser is reading Arc testnet directly as this page loads — the same public RPC anyone can call — and checking what it finds against the source in the repository.
Want the story rather than the receipts? One dispute, judged two ways — an opinion model approves a seller's claim, re-execution replays the work and returns Failed, and the money goes back to the buyer. This page is the evidence; that one is the mechanism.
1. The code holding the money
… reading the deployed bytecode…
RecknZkEscrow has no constructor, so the same source always
produces the same deployment. That makes this comparison meaningful: the contract
that holds money on Arc is byte-for-byte the file you can read in this repository.
2. Four settlements, each decided by a proof
Two of them were decided by proofs about work performed on Solana — one escrow, two virtual machines, and no bridge, no light client and no resolver anywhere on the path that chose who got paid.
| the proof said | about work on | the money went | block | gas | receipt |
|---|
Each row is an eth_getTransactionReceipt call
made from your browser. The verdict and the recipient are decoded out of the
SettledByProof log in the receipt, not read from this page.
3. What crosses, and what does not
The common misreading is that Arc verifies Solana, or that something is bridged. Neither is true, and the difference is the design.
Solana — where the work happened
a committed transaction and the account set it touched
→
SP1 zkVM — where the judging happens
signatures verified,
bank_hash recomputed, transfer re-executed →
outcome · traceHash · dealBindinga proof.
nothing else →
nothing else →
Arc — where the money always was
the verifier checks a Groth16 proof, the escrow pays or refunds in USDC
No bridge is needed because no asset moves. The USDC is on Arc at the start and on Arc at the end; only a proof travels, and Arc never runs a Solana VM. No light client is needed because Arc is not asked what Solana’s state is — it is asked whether a computation over a committed state is valid.
| What this does | Settles USDC on Arc conditionally on the re-executed result of work performed on Solana, with no bridge, no light client and no adjudicator on the path that decides the payout. |
| What it does not | Prove the committed inputs came from Solana mainnet. The guest recomputes a
bank_hash over the account set the deal named — internal
consistency, not provenance. A fabricated account set hashes just as well,
and a test asserts exactly that. Closing it needs a light client, or an oracle
with its trust model written down. |
Both rows or neither. Without them a reader cannot tell this apart from a bridge, a light client, or an oracle — and the boundary is the interesting part.
4. What it removes is not a fee — it is the person
A large delivery held in escrow is normally released when a person approves it. That person is a serialisation point: agents run continuously and in parallel, and every release queues behind somebody reading something.
… computing what these settlements cost…
Read from the receipts in this browser — gasUsed times
effectiveGasPrice, in the USDC Arc uses as its gas. It does not grow with the
size of the dispute.
| The normal way | A human approves the release. Platforms charge 10–20% for standing behind that judgement (Upwork, Fiverr), a decided dispute costs a merchant $110–128 all-in, and the release waits on someone's attention. Cited, not measured here. |
| Here | Nobody approves anything. The release condition is fixed before the
work begins — it is the dealBinding in section 2 — and
evaluated by a computation either party can run. There is no queue behind a
person. |
The scale of the thing being removed. x402 has processed 165 million payments across 69,000 agents. At the dispute rate card payments actually run at (~0.5%) that is 825,000 decisions — 14 to 34 person-years of reading, at two to five minutes each. Derived, not measured: the counts and the rate are cited, the minutes are an assumption. Halve it and the shape holds, because transaction count grows and human attention does not.
5. Try to change the verdict with words
The seller's story is the one thing an observer can write freely. Type anything you like below — argue, insist, threaten, paste an instruction telling the system to approve. Your text is hashed in this browser, and that hash is what a dispute transcript would carry. Everything the money depends on is read from Arc and is sitting to the right of it.
claimHash — changes as you type
…
dealBinding — read from the escrow on Arc
…
the proof's traceHash — from the settlement receipt
…
what the money did
…
Why this is not a trick. The claim is not an input to the
re-execution — the function that produces the record cannot take it, which is
checked by a test that mutates the code to pass it in and requires the check to fail
(scripts/004-negative-controls.sh, NC-1). The right-hand values are not
stored in this page: they are fetched from Arc, and the deal they belong to was settled
by a Groth16 proof whose public values commit to that binding. What you type is real
and it is recorded. It is simply not something the verdict is a function of.
6. The deal that cannot settle, and is not lost
… reading the frozen deal…
Circle's USDC blacklists well-known compromised keys, and the first
deal named one as its seller. settleWithProof reverts with
Blocked address, and the seller is fixed at funding — so this deal can never
release. It is not lost either: refundAfterDeadline returns it to the
buyer, permissionless, and whoever calls it gets nothing. We did not plan this
demonstration; Circle's blacklist provided it, and it is recorded rather than hidden.
7. What no button here can do
Move a funded deal without a proof that carries its binding, or before the deadline.
There is no address with that power — not the buyer's, not the seller's, not the
deployer's, because there is no deployer role and no constructor. That is enforced as a
build condition, scripts/no-keys.sh, not promised in a README.
Two things this page does not claim. The buyer names the
adjudicating program when funding, so a buyer who names one that always returns
Failed makes the seller work for nothing — on-chain that is
indistinguishable from an honest failure, and sellers read the deal first. And
“settled by a Solana proof” is a statement about the adjudication path, not about
anchoring: the guest recomputes a bank_hash over the account set the deal
committed to, which proves internal consistency and not provenance.
Check it without this page
…
Reckn — an escrow for agent-to-agent payments whose dispute adjudicator is deterministic re-execution. Source, specifications, every review verdict including the failed ones, and the acceptance gates: github.com/psyto/reckn.