Governance & Audit

The audit lifecycle

For a new DEX core release, the lifecycle typically runs 6-12 months:

1. Internal review (2-4 weeks). Security engineers + protocol team. Adversarial models. Test gaps found here are cheap.
2. External audit #1 (4-6 weeks). One of the top firms. Findings logged.
3. Fix + diff review (2-3 weeks).
4. External audit #2 (4-6 weeks), parallel to #1 or sequential. Different firm.
5. Audit contest (1-2 weeks) on Code4rena, Sherlock, Cantina, or similar. Crowd-sources finding the long-tail bugs.
6. Bounty ongoing (Immunefi). Often $1M-$15M for critical bugs.
7. Testnet deployment. Real users on Sepolia / Holesky / Base testnet.
8. Mainnet deployment with caps. Initial TVL ceiling enforced via the periphery.
9. Cap removal. After some weeks-to-months of clean operation.

You will be on the engineer side of all of this. Interviews probe for fluency.

Pre-audit checklist

Before opening the audit kickoff call, you want to walk in clean. The minimum:

• 100% line coverage on the core. ~90% branch coverage.
• Foundry invariant tests green for >1M runs.
• Echidna / Halmos passing on the core math.
• Mainnet fork tests against real tokens, real pools.
• NatSpec on every external function — auditors read this to understand intent.
• Architecture doc — diagrams, invariants enumerated, threat model documented.
• Known issues list — things you've decided not to fix and why.
• Gas profile — auditors will check that you haven't optimized into incorrectness.
• Diff against prior version if it's a v2-of-something.
• Slither / Aderyn / Wake reports — clean static analysis at the level your team accepts.

Walking auditors through this in week 1 sets the tone for the rest of the engagement.

Multiple-auditor strategy

For high-TVL launches, the industry standard is at least two independent firms, often in parallel for cost (two ~6-week audits running concurrently take ~6 weeks elapsed, vs ~12 sequentially).

Top firms by reputation in 2025-2026:

Pick two for diversity of approach. If one does FV, pair with one that does adversarial mechanism review.

Contests & bounties

After private audits, public contests catch the bugs that survived private review. The structure: contest organizers post the codebase publicly, auditors submit findings within a 1-2 week window, payout pool of $200k-$2M is distributed by severity.

For the engineer:

• Volume of findings is overwhelming. Expect 100+ submissions, most duplicates, most informational.
• Triage by severity — H/M/L/I. Only H and M usually require code changes.
• Disclosure discipline — issues are confidential until contest ends.

Bounties (Immunefi, Hats Finance) are the always-on equivalent. A $10M bounty on a $1B TVL system is industry-standard.

Mainnet rollout

Even after all audits, you don't open the floodgates. The rollout pattern:

1. Deploy contracts to mainnet. They are inert until activated.
2. Verify source on Etherscan (and Sourcify, and L2 explorers).
3. Activate on a single low-volume pool. Watch.
4. Roll to a TVL cap (e.g. $10M aggregate). Watch for a week.
5. Raise cap. Repeat.
6. Remove cap.

Caps are typically enforced at the periphery, not the core (since core is immutable). The router refuses to route into pools that have exceeded the cap.

Governance over fees

What governance actually controls in a typical large DEX:

• Protocol fee toggle. Most pools have a per-pool fraction-of-fee that can be turned on, sending a slice to the protocol treasury.
• Fee tier curation. Adding new fee tiers (e.g. v3's 0.01%, 0.05%, 0.30%, 1.00%). Adding a tier is a governance action.
• Hook approvals. For v4-style systems with sanctioned hook lists.
• Periphery upgrades. New routers, new position managers.
• Treasury operations. Where collected fees go.
• L2 deployments. Authorizing the contracts on a new chain to canonically belong to the protocol.

What governance does not control:

• Core pool logic. Immutable.
• Per-pool swap fees (set at pool creation by the LP, not governance).
• User positions.
• Token approvals.

Treasury management

Protocol fees accumulate. Treasury choices:

• Hold — keep as the collected token. Simplest. Subject to price risk.
• Swap to a base asset (ETH, USDC) periodically. Adds operational surface.
• Distribute to token holders via voting escrow / fee switch.
• Reinvest as protocol-owned liquidity.

You may be asked to design the fee-collection contract. Key points:

• Permissionless collection (anyone can trigger) with a hard target address — no governance bottleneck for collection itself.
• Fee withdrawal events for indexers.
• Gas budget — collecting from 10,000 pools should be batchable.

Immutable by design

The defining philosophical choice of high-end DEX engineering: core code is immutable. There is no upgrade path. There is no admin function to disable a pool. There is no "owner can withdraw" backdoor.

The implications:

• You ship a new version when you need to change the core. v1 → v2 → v3 → v4. Old versions keep running.
• The audit budget is asymmetric. You pay 5-10× more for core than for periphery.
• Trust model is the simplest possible — code is the only thing users have to verify.
• You can't apologize. The bug that ships is the bug forever.

In an interview, "would you make this core upgradeable?" is a values question as much as a technical one. The honest senior answer:

Periphery upgrades

Periphery contracts evolve constantly. Patterns:

• Hot-swap by deploying a new router and pointing the front-end at it. Old router stays alive for already-pending UX.
• Proxy upgrades only when the contract holds state worth preserving (e.g. an NFT position manager — you can't redeploy the NFTs).
• Per-feature kill switch — guarded by a timelock, lets you disable a feature without nuking the contract.

The proxy choice for upgradeable peripherals (when needed): typically UUPS via ERC-1967 + ERC-7201 storage namespaces + timelock-controlled admin. Multi-step queue + execute, no instant pushes.