Sudo Escrow v3 is live on mainnet today. It is the third full rewrite of our escrow contract suite in 18 months — and the one that finally feels finished. This post is the engineering story.
If you have used Sudo Escrow before, you will not notice anything dramatic in the UI. The escrow card still slides into your chat. You still tap Release, Dispute or Extend. The funds still settle on whatever chain you and the counterparty agreed on. What changed lives entirely under the hood.
Three numbers up front
Compared to v2, v3 ships with:
- 42% smaller bytecode. The core
EscrowVaultcontract now compiles to 14,892 bytes — well under the 24,576-byte EIP-170 limit, with room for a half-dozen new features before we run out of headroom again. - 61% lower gas to settle on Base. A two-party, three-milestone escrow that used to cost roughly 280k gas to fund + release now costs around 109k.
- Sub-minute disputes. The full commit-reveal of a 5-validator panel — from Dispute tap to funds released to the winning side — now averages 48 seconds on mainnet, down from a v2 average of just over 4 minutes.
These are not marketing numbers. We benchmark every release on a public dashboard at status. The numbers above were measured across the first 500 escrows opened on v3 after launch.
What we cut
Most of the size and gas wins come from things we deleted from v2, not from new cleverness.
A bespoke reentrancy guard. v2 inherited a custom reentrancy modifier we wrote in 2024 for a different threat model. v3 uses OpenZeppelin's ReentrancyGuard directly. Same protection, ~340 bytes smaller, and we don't carry the burden of auditing our own variant.
A custom permit flow for ERC-20 deposits. v2 implemented its own EIP-2612 wrapper to support permit + transferFrom in a single call. ERC-20 tokens that we cared about have caught up, so v3 just calls the token's native permit and falls back to transferFrom with a separate approval. Less code, fewer edge cases, identical UX.
Multi-token batching in the vault. v2 supported funding an escrow with up to five different tokens in a single transaction. In nine months of production data we found 0.06% of escrows used the feature. Removing it killed an entire 1.8k-byte code path and three medium-severity audit findings.
Storage packing of milestone state. v2 stored each milestone in its own 256-bit slot. v3 packs three milestones per slot (status, deadline, amount in u80) and saves a SSTORE per release. This alone shaved 18% of the post-fund gas cost.
What we added
We did add a small handful of features. The bar was high: anything new had to either remove a class of disputes or unlock a recurring user request.
Streaming releases
You can now fund an escrow that releases continuously over a window — say, 200 USDC streamed to a contractor over 30 days — without a separate Sablier or Superfluid integration. Internally this is just a release-per-second rate stored alongside the milestone and computed on claim. Adds 410 bytes, removes the most common feature request we've had since v1.
Partial disputes
In v2, Dispute froze the entire escrow and forced the validator panel to choose between full release and full refund. v3 lets either party specify the slice of remaining funds they're disputing. The other slice keeps releasing on schedule. This dramatically reduces the all-or-nothing pressure that made some disputes drag on for days in v2 as the parties negotiated around the contract.
Witness mode
Optional, opt-in: a third wallet you both trust can co-sign release and dispute decisions without holding any funds. Useful for community DAOs and for couples — yes, we have real users settling rent escrows on Sudo. The witness can never unilaterally release, only co-sign or refuse to sign.
How we shrank disputes from 4 minutes to 48 seconds
The dispute pipeline was the most-watched performance number going into v3, because dispute latency is a UX issue (people are watching the funds), a fairness issue (slow disputes favour the party that wins by attrition), and a cost issue (validators charge for time-on-task).
We attacked it from three angles.
Panel formation. v2 selected validators using on-chain VRF in a single transaction, which was clean but added two L1 confirmations of latency before the panel could even start voting. v3 uses a precomputed nextPanelSeed that gets refreshed by validators in the background, so panel selection at dispute-open time is a hash, not an RPC round trip. Trade-off: the seed is committed up to 5 minutes ahead of time, so a malicious operator who can observe the seed could rush a dispute to align with their target panel. We added rate-limiting and per-wallet cooldowns to make this attack uneconomic.
Vote commit-reveal compression. v2 ran commit and reveal in two separate transactions per validator (so 10 txs for a 5-member panel). v3 batches commits into one transaction and reveals into another — total 2 txs regardless of panel size. The validator client signs in one place, posts once; the panel finishes in two L1 confirmations instead of ten.
Hot path optimisation. We profiled the dispute opcode-by-opcode and discovered we were paying for two SLOADs in the happy-path settlement that we could fold into the existing milestone load. That's a small 1.4k gas win, but it pushed the median dispute below the 50-second mark.
Three audits in three weeks
v3's contract was small enough that we could ship it through a tighter audit cycle than v2:
- Spearbit — 12 days, focus on storage layout and the dispute pipeline. 1 medium, 3 low, all fixed and re-reviewed.
- Trail of Bits — 9 days, focus on the streaming-release math and reentrancy at the storage-packing layer. 1 high (a sign-extension corner in u80 streaming for tokens with 0 decimals — fixed by saturating at
type(uint80).max), 2 medium, 4 low. - OtterSec — 8 days, focus on the SUI bridge adapter and the cross-chain settlement happy path. 2 medium, 1 low, all fixed.
Reports are public on our audits page. All fixes were re-reviewed before we deployed to mainnet — no medium or above is open at launch.
Migration
If you have an open v2 escrow, nothing changes. v2 stays alive and addressable forever — we did not migrate state, only the entrypoint that the client uses for new escrows. Your in-flight escrow runs to completion on v2 and the funds release exactly as the original contract promised.
New escrows opened from v3.0.1 of the client (rolling out across iOS, Android, web and desktop this week) will use v3. The chat surface looks the same. The escrow card has a small v3 tag in the corner for transparency.
If you're a builder and you've integrated against the v2 ABI, the migration is one find-replace plus an added streaming flag on the fund() call. Drop-in. See the developer changelog for the full diff.
What's next
Two features are queued for v3.1 — neither big enough for a full major:
- Cross-chain dispute panels. Today, a dispute on a Base escrow is resolved by validators staked on Base. v3.1 lets the panel be drawn from validators staked on any chain, with the result settled back to the original chain via a light-client proof. Important for situations where a dispute touches information that only lives on one network.
- Recurring escrows. Set up a subscription-style escrow that re-funds itself from a designated wallet on a schedule. Same contract, just a thin wrapper.
Both shipping mid-Q3 if testing stays on schedule. The full multi-year design lives in the whitepaper.
One last note
Sudo Escrow v1 was 4,200 bytes of contract code, no validators, and could not settle a dispute. v3 is a full commit-reveal pipeline, three deployed chains, a $7.2M total-value-secured, and still fits inside the same byte ceiling. That progression — more capability for less code — is the only kind of engineering progress we trust. Anything else is just feature accretion in fancy clothes.
Read the contracts on GitHub. Try an escrow on web.sudochat.app. And, as always, every bug we get reported is paid out of our public bug bounty programme.
— The Sudo Escrow team · v3.0.1 · April 2026