Audit Timeline

Audit Timeline describes the full sequence of security activities a Web3 protocol schedules across its development lifecycle — not a single audit at the end of development, but a series of touchpoints that begins at architecture and continues indefinitely after mainnet.

Why a timeline, not a milestone

A single audit attests to one commit hash under one set of assumptions. The moment code, dependencies, governance, or the underlying EVM change, that audit's coverage narrows — the audit decay problem. Mature protocols treat security as a continuous discipline distributed across time, with each activity placed at the lifecycle stage where it is dramatically more cost-effective than at any other stage. NIST puts post-production fixes at roughly 30x the cost of development-time fixes; in immutable smart contract environments the multiplier is sharper still, because production exposes bearer assets to attackers who are paid in cash within minutes of a successful exploit.

The five canonical touchpoints

A serious DeFi protocol typically schedules five external touchpoints:

1. Architecture review — a senior researcher reads the whitepaper and contract layout, produces trust-boundary diagrams, an invariant catalog, and an attack-tree sketch. One to two engineer-weeks. Before substantial code is written.
2. Mid-development checkpoint — a partial review when 60-70% of code exists and interfaces are stable, catching design drift early. One to three engineer-weeks.
3. Pre-launch audit — the headline engagement on frozen code. Two to eight weeks depending on scope. Manual review by an external firm, often layered with a competitive contest.
4. Fix-review or re-audit — three to seven days within one to four weeks of remediation. Skipping this is how Nomad's confirmAt[0x00] = 1 change slipped through in May 2022 and enabled a $190M drain in August 2022.
5. Post-deploy audit — a review of the actually-deployed bytecode and configuration. Often the cheapest audit and the one most teams skip.

Lead time and buffer rules

Top-tier private firms (OpenZeppelin, Trail of Bits, Spearbit, Cantina, Zellic, ChainSecurity, Halborn, Sigma Prime, Certora, Runtime Verification) quote booking queues of four to twelve weeks from inquiry to kickoff. Reach out three months before target audit start; hold the slot six to eight weeks before code freeze. Plan four to eight weeks between audit start and mainnet for a standard DeFi protocol, eight to sixteen weeks for bridge-grade or financially complex systems. The single most expensive scheduling mistake is ending the audit on launch day with no buffer for findings.

Continuous coverage post-launch

The timeline does not end at T-0. Recurring audits trigger on every code change touching value-bearing contracts. Continuous monitoring (Forta, OpenZeppelin Defender, Hypernative, Hexagate) runs from day one of mainnet. A bug bounty scales with TVL — Immunefi's framework recommends critical payouts up to 10% of TVL-at-risk so the bounty beats the black-market price. Red-team exercises run every six to twelve months. Governance review applies to any proposal that changes parameters, oracles, or treasury. This is the structure SAMM's Verification practice and the SSDF's "Produce Well-Secured Software" group both prescribe.

Common timeline failure modes

• Auditing too early — significant churn during the engagement, auditors flag code you've already deleted, 30-60% of the fee is wasted on stale assurance.
• Auditing too late — critical findings land days before launch, founders pressure the team to ship anyway, remediation is rushed.
• One-and-done — protocol audits at launch, ships new collateral and new chains for 18 months without further review, eventually exploited. Euler ($197M, March 2023) is the canonical case.
• Audit theater — cheapest possible engagement, narrow scope, no remediation visible. False confidence is worse than no audit.