Protocol
How it works
The design axiom
The escrow accepts only four kinds of input: money, clock time,cryptographic proofs checked by a fixed on-chain verifier, andper-user choices whose effects are confined to the choosing user. No actor ever attests, approves, or decides anything on behalf of another actor. Where a decision cannot be forced into a proof or a clock, the protocol degrades to refunds rather than to a trusted party. A DAO vote violates this rule. A platform allowlist violates it. A founder deploying from their own wallet violates it. Drydock exists because everything on that list can be engineered out.
Who's involved, and what they can't do
| Actor | Does | Cannot |
|---|---|---|
| Founder | Commits the manifest and proof, remediates findings, withdraws proceeds after the timelock | Touch deposits, change the manifest, deploy the token, or move any deadline |
| Contributor | Deposits; claims tokens, excess, or refunds | Affect anyone else's position |
| Auditor | Reviews the exact committed bundle; signs a machine-readable report trailer | Hold funds, veto, rescue, or earn differently based on the verdict |
| Prover / courier | Submits journals and initcode bytes — anyone may | Anything; every byte is checked against prior commitments |
| Platform | Serves this website | Everything else; no guard references any platform key |
The launch sequence
- CP0
Commit
Manifest hash + proof a complete implementation exists. Bad parameters are unrepresentable.
- CP1
Deposit
Non-custodial escrow. Miss the goal, every deposit refunds in full.
- CP2
Finalize
Pure clock. The audit fee, fixed by proven code size, escrows for the named auditor.
- CP3
Attest
The auditor signs its report trailer. Launch conditions evaluate mechanically.
- CP4
Reprove
Post-remediation code re-proves the same manifest. Properties cannot drift.
- CP5
Float out
The escrow itself deploys by CREATE2. Anyone can supply the bytes; hashes do the checking.
- CP6
Distribute
Pro-rata claims from the escrow ledger. Founder proceeds unlock after a timelock.
Every failure path drains here. Goal missed, report late, conditions failed, deadline blown: the escrow enters an absorbing refund state with pull-based, non-expiring withdrawals. Nothing can strand funds and nobody can veto the drain.
Manifest continuity, the invariant
At CP0 the founder commits hM = keccak256(manifest): name, symbol, supply, the full allocation split, powers (no mint after the constructor, no upgradeability), tax bounds, build settings, constructor args. The creation journal proves code satisfying it existed before any deposit. After the audit and remediation, CP4 requires a second journal over theexact bundle the auditor signed off on, re-proving the same hM. Code changes during remediation; promises cannot. At CP5 the escrow deploys only bytes whose hash the CP4 journal committed, then verifies its own presale balance. What floats out is byte-identical to what was audited, with exactly the properties declared on day zero.
What failure looks like
Goal missed at the funding deadline: full refunds. No attested report by the deadman: refunds, keeping the undelivered fee tranche in the pot. Launch conditions fail: the auditor is still paid (independence), and the remainder refunds. Deployment deadline missed: refunds. In every case the escrow enters one absorbing state with pull-based withdrawals that never expire, and any address can trigger the transition. Liveness never depends on anyone showing up —Propositions 1–3 in the paper state this formally, and the reference implementation checks them as fuzzed invariants.
Hard floors: bad campaigns are unrepresentable
Creation reverts unless the audit fee is at most a third of the goal, the report deadline exceeds the rate card's review window plus a 21-day remediation buffer, the deploy deadline adds 14 days of proving slack, and the withdrawal timelock is at least 7 days. A founder cannot set a timeline shorter than the physics of auditing or a goal that merely launders an audit purchase — not "shouldn't": cannot, the transaction reverts.