Smart contract audit timeline: public ranges and a defensible launch plan

Method: separate the queue, review and remediation clocks

Plan a smart contract audit timeline from a defined release and explicit deliverables.

Public duration ranges can help frame a discussion, but they do not establish when a reviewer can start or when your team will finish the fixes. A launch date that combines those clocks without naming their owners is difficult to defend.

Our public-site census checked the fixed research roster of 23 DSA firms, including historical directory names.

It found qualifying service-duration language on sampled pages from 3 firms. The result is a disclosure finding, not a distribution of observed project delivery times. It cannot produce a market-wide median or a scope-normalized queue estimate.

Use distinct milestones in the working schedule.

Readiness ends when the reviewer can reproduce the candidate and understand its intended behavior. Queue time ends when the agreed review capacity starts. Initial review produces findings. Remediation and fix review then establish the final disposition, followed by release verification.

Some activities can overlap, but overlap needs a dependency decision.

Documentation can improve while scope discussions proceed. A final fix review cannot establish a revision that does not yet exist. Publishing a report before the deployment readback also does not establish that production matches the reviewed candidate.

Readiness

Preparing the source, build, tests, architecture and known-risk packet.

Queue or start lead time

Waiting for the agreed team to begin the scoped engagement.

Review duration

Time allocated to the initial assessment and its findings deliverable.

Remediation window

Time your engineers need to implement and explain changes.

Fix review

Reviewer work on the actual remediation revision and related regressions.

Release verification

Checking the deployed implementation and configuration against the reviewed packet.

Assign an owner to each clock.

The audit provider can estimate its allocated review work; your team owns the availability of a stable candidate and the implementation of fixes. Dependencies, unresolved design choices and external integrations can affect both parties.

The schedule should also define what completion means. An initial report, a final report and a deployment acceptance record are different deliverables. Decide which one the launch decision requires before comparing quoted turnaround times.

Our public-site census: three qualifying disclosures across 23 firms

The survey requested 55 pages across the member population: each homepage and up to 3 selected same-site audit or security service links. Five firms produced raw duration matches. Manual review excluded unrelated deployment claims, testimonials and client remediation windows from the service-duration count.

Method

Retrieved

September 5, 2026

Population

The fixed 23-member list reused from the directory research utilities.

Page selection

Homepage plus up to 3 discovered same-site audit or security-service candidates, prioritized by path and then lexical order.

Classification

Read each duration context. Distinguish service duration, quote preparation, remediation, one-client cases and unrelated services.

Unknown rule

Unavailable pages and absent qualifying wording remain unknown or not observed in the sample, never zero-day delivery.

Scope limitation

The crawl is bounded and does not inspect every page or obtain private quotes. The historical roster is not a verification of current alliance membership.

Results

The 20 firms without a qualifying sampled disclosure are not claimed to have no public timeline anywhere. The crawl may miss a relevant page, and some endpoints were unavailable. The result identifies which public evidence this method actually obtained.

Limits

• Published ranges are vendor statements, not observed delivery measurements.
• Calendar days, business days and weeks are retained as written rather than merged into a synthetic average.
• The sites do not provide a common scope-size variable or an equivalent start-availability measure.
• A one-client testimonial and a remediation allowance answer different questions from general audit duration.

Reproduction uses seo/research/member-audit-duration-survey.py; its dated output is seo/research/member-audit-duration-survey-2026-09-05.json. These files remain in the repository and are not published as downloads. The output preserves source responses, retrieval outcomes and the selection rules for later verification.

Lead-time distribution by scope size: what the public evidence supports

The qualifying pages do not support a distribution by comparable scope size.

Their descriptions refer to complexity, service type or package assumptions without a shared measurement of dependencies and review effort. Presenting a small, medium and large median would require information the census did not collect.

Preserve the original ranges and their context.

SolidProof describes a typical security-audit or testing duration that depends on contract size and complexity. 0xGuard discusses typical work and longer exceptions in its service explanation. Hacken gives a business-day range on the inspected chain-specific audit pages. None of these statements is a booked start date for your release.

Do not assign each range to a scope tier after the fact.

A small source tree with novel economic behavior can require more investigation than a larger familiar implementation. Contract count and lines of code can help describe the packet, but they do not establish equivalent reasoning effort.

The 0xGuard pages also contain package durations whose flattened text makes some plan associations ambiguous. We retain the clear general statement above instead of attaching a duration to a named tariff without reliable layout evidence. That choice avoids turning an extraction artifact into a procurement claim.

For an actual comparison, send each provider the same candidate revision, architecture and deliverables. Ask for start availability, allocated review effort, assumptions about your response time and the included fix-review work. Only then can the team compare the schedules as estimates for the same decision.

The audit RFP guide provides a common packet for that comparison. A public range is a conversation input; the scoped proposal is the planning artifact.

What drives duration

The first avoidable delay is an unreproducible candidate. If a reviewer cannot build the intended revision or locate the active contracts, paid review time is spent reconstructing the environment. A clean build, pinned dependencies and a clear scope inventory give the review a defined starting point.

Documentation affects the next stage. The reviewer needs to understand what the protocol is supposed to do before deciding whether a surprising behavior is a defect or an intentional constraint. Explain accounting units, permission boundaries and exceptional paths. A source comment that repeats a function name does little to answer those questions.

Novel dependencies can expand the analysis. An oracle adapter, bridge verifier or upgrade migration introduces assumptions that may not be apparent from the main contract count. Include them in the scope discussion. Otherwise the schedule may appear to slip when the actual problem is that the original estimate omitted a consequential boundary.

Code churn is another dependency. A reviewer can assess a defined candidate, but a moving implementation makes findings and tests harder to reconcile. Decide how changes enter the review and which changes require a revised scope. Calling every new feature a small fix does not preserve the original estimate.

The team can reduce waiting by assigning a knowledgeable point of contact. Questions about intent, deployment configuration or a suspected invariant should reach someone able to answer them with evidence. A long chain of internal approvals can delay both initial review and remediation even when the provider has capacity available.

1. Have someone outside the implementation team reproduce the candidate from the written instructions.
2. Provide the architecture, authority graph and accounting assumptions before scope is finalized.
3. Label incomplete features and known issues so the reviewer can distinguish them from unexplained behavior.
4. Agree on how new commits are admitted during review and what triggers a scope change.
5. Assign a response owner who can resolve technical questions and coordinate fixes.

Trail of Bits' audit preparation guidance emphasizes reducing avoidable investigation, while OpenZeppelin's readiness guide explains why auditability affects the review.

For a review that includes implementation and remediation planning, Pharos Production's smart contract audit scope and remediation page describes a code-freeze expectation, severity-ranked findings and re-verification. Those deliverables belong in separate schedule milestones so the final acceptance decision is tied to the reviewed fix, with enough time reserved for the team's changes.

Ask which assumptions are already priced into the estimate. A schedule that assumes complete documentation and rapid answers should say so. If those conditions are not yet true, record the readiness work and its owner rather than presenting the earliest possible completion as the committed launch date.

Fix rounds: reserve engineering and reviewer time

The first findings report begins another stage of work. Your engineers need to understand the issue, choose a correction and demonstrate the changed behavior. The reviewer then needs the actual remediation revision. Scheduling only the initial review leaves those dependencies unowned.

Quantstamp's readiness guide describes a period usually given to the project for remediation before fix review. The duration match in that page was excluded from our audit-duration count because it describes the client's work window. This illustrates why a number near the word audit cannot be assigned to the provider's review time without reading the surrounding process.

Define what a fix round includes. It may cover verification of the original findings, investigation of adjacent regressions or a broader reassessment after a substantial redesign. Those are different workloads. If the fix changes storage, economic assumptions or authority, ask whether the original review allocation still covers the new candidate.

Accepted risks also need a deadline and owner. A team may decide to retain a capability or limitation with a documented rationale. That decision should appear in the final disposition, including any operating controls it relies on. Silently dropping the issue from a launch checklist makes the schedule look complete while leaving the decision unresolved.

Reserve capacity for another iteration where the risk justifies it. The purpose is not to promise an arbitrary number of rounds but to avoid treating the first patch as final before it has been examined. A failed fix review should lead to an updated engineering task and schedule, not pressure to relabel the finding.

Keep an explicit distinction between report publication and release acceptance. Some teams publish findings before all remediations are complete. That can be transparent when the status is clear, but it does not mean the unresolved conditions have disappeared. A launch decision should reference the actual final dispositions it depends on.

The audit report guide explains finding status and scope. Use those fields to decide which milestone is complete rather than relying on the presence of a PDF.

Planning a launch date

Work backward from the acceptance evidence the release requires. Identify which tasks must happen in sequence, which can overlap and which have uncertain duration. A useful schedule shows a range and the condition that would move it, rather than a single date detached from readiness and fix work.

Treat the provider's start availability as a separate input. Even a short review allocation cannot begin before the agreed team is available. Conversely, a reserved slot can be wasted if the candidate is not ready. Confirm both conditions before promising a launch window to users.

Build the release decision around completed evidence. The final reviewed revision, accepted residual risks and deployment configuration should be available before the team claims that production is covered. A marketing deadline does not establish any of those facts.

Ready candidate

Reproducible scope.

Review and fixes

Final dispositions.

Launch acceptance

Deployment matches review.

If a new finding changes the design, revise the schedule around the new scope. Explain which dependency changed and what evidence remains to be produced. That is more useful to a release owner than calling all variance an auditor delay.

Use the audit scope builder and member directory to prepare the provider discussion. The Pharos Production member profile is one reference for that selection. Request a concrete scope, available start window and fix-review agreement from the chosen team.

The public census supports a restrained conclusion: qualifying durations were visible for a small part of the sampled directory, and the statements were not comparable queue measurements. A defensible launch plan therefore needs a scoped estimate and owned dependencies. The useful date is the one connected to a reproducible candidate and an explicit acceptance decision.

A useful launch review distinguishes a delay from a changed prerequisite. If the reviewer discovers that the candidate lacks an agreed specification, the team needs to resolve that design input before the assessment can establish conformity. If an external integration changes, the relevant tests may need another run. Record the changed dependency and its owner.

The team should also agree on the decision made when the launch window arrives with an unresolved finding. That can mean postponing the release, removing the affected feature or accepting a specifically documented constraint through the authorized process. The schedule should expose that decision point early, rather than treating the calendar date as permission to skip it.