Security & audits
Unstable runs the engine proven by its predecessor desk — 1,809 settled trades, ~240 ETH of volume, zero fund-safety incidents— ported to USDC and re-audited from scratch. The full audit lineage lives in the repository's git history.
Audit record
- Pre-deploy: a line-by-line external audit plus an adversarial multi-agent panel (reentrancy, accounting/conservation, blacklist paths, premium math, settlement atomicity, access control) — both returned GO with zero must-fix findings, with a delta re-audit of every applied hardening fix.
- Post-deploy: the deployed runtime bytecode of all four contracts was matched byte-for-byte against the audited source, every constructor parameter verified on-chain, and real-USDC drills exercised fill, settle, refund, self-refund, cancel and recovery paths to the exact cent.
- Continuously: 65 contract tests including conservation invariants (thousands of randomized operations with blacklist chaos), plus keeper and interface suites, run in CI on every change. No contract change ships without a fresh GO.
The invariants, in plain words
- A pending payment can only ever reach the committed maker + fee wallet, or come back to you. There is no third destination in the code.
- The escrow's balance always equals what it owes: open offers + live reservations + pull balances. To the unit.
- No state exists from which funds are unrecoverable by someone's unilateral action — yours (self-refund, withdraw) or the operator's recovery backstop.
Contracts (verified on-chain)
| Contract | Chain | Address |
|---|---|---|
| Buy · payment escrow | Ethereum | 0xC2338e30eD76070490e650DDAf93c6829b34970c |
| Buy · liquidity escrow | Arc | 0xC2338e30eD76070490e650DDAf93c6829b34970c |
| Sell · payment escrow | Arc | 0x0D952280F3f694D473Db5f1d1397990B1f0aBc62 |
| Sell · liquidity escrow | Ethereum | 0x0D952280F3f694D473Db5f1d1397990B1f0aBc62 |
| USDC (Ethereum) | Ethereum | 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 |
| USDC (Arc) | Arc | 0x3600000000000000000000000000000000000000 |
Per-market addresses are identical on both chains (fresh deployers at nonce 0); every id is salted with the chain id and contract address, so the legs can never be confused.
Key discipline
- The owner key is cold — separate from the settlement keys since the moment of deployment, never on a server. It has never signed a transaction.
- Settlement (keeper) keys can't steal: they can only move escrow along the committed path, and they are rotatable by the cold owner on suspicion.
- All money movement is ERC-20 USDC — no native-value paths exist in the contracts.
The USDC caveat
USDC is centrally issued: Circle can blacklist addresses. Escrow payouts survive that (they park in a pull balance — see the refund guarantee). The one risk no USDC-holding contract can engineer away is Circle blacklisting an escrow address itself; we monitor for it operationally, and it has no precedent against neutral settlement infrastructure.