When the parties to an escrow disagree, a staked panel decides — and the escrow pays itself.
VerdictMesh is a dispute court for Solana, built once and shared. An escrow program integrates it by reading one account: a panel of staked jurors votes, a model-written fact-finding report tells them what the chain confirms, and the escrow executes the verdict on its own. Nobody, including us, holds a key over the money.
Marked text on this page is on-chain. Every marked line links to the transaction that proves it.
Case 35DPG3…enERa · devnet · 20 USDC in dispute
captured 2 Oct 2026- T+0 s Dispute opened; policy snapshotted; panel of three drawn 4SFyK8…
- T+2–4 s Three sealed votes committed — the third from a browser walletThe seats in this run are scripted and vote at once. A juror has the whole 60 s commit window to read the report. 2HRS2Y…2MeJ4M…C5Rp9F…
- T+30 s Fact-finding report fingerprint written on-chain 769bdc…8e40 2o9Dc8…
- T+63–65 s Three votes revealed: claimant 3, respondent 0 7vcV7Z…5RGQds…3bdG5a…
- T+122 s Tallied: verdict for the claimant 2TF1aK…
- T+214 s Appeal window closed; the escrow read the verdict and paid out 3LvaRk…
- T+216 s Juror stakes settled 25oLno…
The windows in this demo policy are 60 s to commit, 60 s to reveal and 90 s to appeal, so no case closes faster than 210 s.
One court, any escrow
¶1 The escrow asks, the court answers. Your program flags a dispute and later reads one account. VerdictMesh never holds your funds and has no instruction that could move them.
Tested, not promised: tests/authority.rs tries every instruction in the program's interface with every key.
¶2 Jurors see facts, not raw transactions. A watcher collects the deal's on-chain history and a model writes a report that marks what the chain confirms, what a party only claims, and what could not be established. Its fingerprint goes on-chain; the key that writes it can do nothing else.
The report's author is a role we operate — see Not in this build.
¶3 Losing costs, silence costs more. Jurors stake to sit. Voting with the losing side costs 10 % of the stake; not revealing costs 20 %. The losing party pays for the hearing, once.
Demo policy: panel of 3, quorum 2, review deposit 5 USDC.
Five steps, all on-chain
- 1Open. A party opens a dispute over locked funds. The integrator's policy is copied into the dispute, and a panel is drawn from the staked registry in the same transaction.
- 2Report. The fact-finding report is written and its fingerprint recorded. If the model is down, the hearing goes on without one.
- 3Commit. Each juror seals a fingerprint of their vote, from their own wallet. Nobody can copy a vote they cannot read.
- 4Reveal. Jurors open their votes; the tally fixes the verdict and the appeal window starts.
- 5Execute. The escrow reads the verdict from the dispute account and pays out under its own rules.
What we measured, and where
| Figure | What | Where |
|---|---|---|
| 218 s | Dispute opened → escrow paid, the slowest of 20 consecutive cycles (214–218 s). Budget 5 min. | devnet, release v0.1.0 |
| $0.017 | Network fees for a whole cycle, all participants together (85 000 lamports). Budget $0.10. | devnet |
| 0 of 20 | Cycles that needed a manual step. | devnet |
| 6 of 6 | Attempts to execute an already executed verdict rejected; no balance moved. | devnet |
| 24.9 s | Report ready for the juror, p95 over 20 disputes, 20 of 20 delivered. Budget 30 s.1 | local service + devnet |
| 0.55–1.13 s | Juror panel's first screen with real hearings. Budget 2 s.2 | GitHub Pages + Render |
| 1.36 s | One vote from a browser wallet: commit, and reveal, each. | devnet, the case above |
| not yet | Report accuracy: no false “confirmed” fact across 20 modelled disputes with known answers. | next |
| not yet | A developer new to the project integrates in 30 minutes and 40 lines, timed by someone who did not write the SDK. | next milestone |
1 Measured with the service running locally, not on the hosted one. A dispute opened while the hosted service sleeps gets its report after it wakes.
2 The free host sleeps when idle; a health check every 5 minutes keeps it awake. Without it, the first visit after sleep took 43.8 s.
Not in this build
- Devnet only. Not audited. No real money: the stake economics are shown, not protecting anyone's capital.
- The jurors in the registry are keys we control. The panel's independence is arithmetic, not social.
- Money and votes are real; what the disputes are about is modelled from prepared fixtures.
- The report is written by a role we operate. It cannot vote or move funds, but it could be biased, and jurors would read that report.
- Evidence is on-chain facts plus the parties' written claims. No files, images or screenshots, so “was the work good” disputes are not fully covered.
- A verdict is code executing rules both parties agreed to, not a judgment any court recognises.
- The panel is drawn from a slot hash, which a slot leader could in theory influence. Fine for a devnet demo, not for mainnet money.
- Not built yet: the integrator SDK, a second escrow, appeals and the optimistic track. Today every dispute goes to a full panel, which costs more than the design intends.
Questions
Can VerdictMesh move my users' funds?
No. It has no instruction that touches an integrator's funds. Your escrow reads the verdict and pays out under its own rules.
Who pays for a hearing?
The losing side, once. The opener pays a deposit; if the opener wins, it is reimbursed from a bond the other side posted when the deal was signed.
What if the model is down?
Voting goes on. Jurors see the raw claims and signatures, and the panel says no report is available. A live dispute was paid out in 216.1 s with no model at all.
Can I integrate today?
Only by reading the reference escrow. The SDK and a second, differently built escrow come next.