Smart Contract Audit RFP: Scope and Comparable Deliverables

What firms need to quote

A smart contract audit RFP, or request for proposal, makes reviewers price the same work and state their assumptions in a comparable form. Its most useful output is a resolved scope boundary. Without one, a low quote may cover a smaller system and a longer schedule may include more remediation work than its apparent competitor.

Give each firm the same repository revision, deployment model and description of the assets at risk.

Include the components that can change system behavior, such as governance and upgrade administration. A source directory alone does not explain how a protocol operates or which failures its users cannot tolerate.

The OpenZeppelin readiness guide emphasizes documentation and preparation before review. Trail of Bits' preparation guidance similarly asks for a reproducible environment and explicit dependencies. These are useful inputs because they reduce time spent reconstructing the system before investigation can begin.

Separate facts from estimates.

If code is still changing, say which parts are stable and when a candidate revision will exist. A firm can quote a preparation phase or explain the effect of a moving target. Calling unfinished code frozen only pushes the disagreement into the engagement.

Use the audit scope builder to assemble the initial packet and the member directory to identify firms. Send the same packet to each candidate. A shared clarification log then keeps later answers from silently creating different scopes.

Our report census: separate fix files are a packaging choice

We examined the Trail of Bits publication tree for exact securityreview and fixreview filename pairs.

Among 286 matching security-review paths, 9 have a separate fix-review file with the same stem. The other 277 do not have that exact pair. This does not tell us whether their main reports contain remediation updates.

Method

Source

trailofbits/publications at the measured revision

Retrieved

September 5, 2026

Population and selection

All immediate reviews/*-securityreview.pdf files. A separate fix artifact exists only for an exact same-stem *-fixreview.pdf path in the same tree. This does not inspect inline fix status or count engagements, projects or remediation success.

All repository files

953

Not matching security review pattern

667

Included review paths

286

Revision

5c04ba235d84bbda140fa2d8be95c630bcd0b4ea

Results

Limits

• Selection uses the exact immediate reviews/*-securityreview.pdf naming pattern. Other report names are excluded, so the result is not a census of every engagement.
• A separate file is a distribution format. Reports can contain inline fix reviews, appendices or differently named follow-ups that this method does not inspect.
• No PDF text was analyzed for this measurement. Inline remediation status is unknown for all 286 selected paths.
• These are archive paths, not unique clients or verified fixes. Do not turn the 277 absent pairs into an unremediated-issue count.

The reproducible script is seo/research/audit-fix-pair-survey.py; the fixed evidence is seo/research/audit-fix-pair-survey-2026-09-05.json.

Both are kept in the repository and are not published as downloads. The output retains request statuses and raw evidence so a later review can distinguish a source change from a counting error.

Scope statement template

The template below is an editorial starting point, not a contract.

Replace every placeholder with a value or an explicit unknown. An empty field should not become an implied promise by either party. Keep one version-controlled copy and attach its identifier to every proposal comparison.

Project and decision

State what is being launched or changed and which release decision the review will inform.

Candidate revision

List each repository with its immutable commit and any generated files needed to reproduce the build.

Included paths

Name the contracts, deployment scripts and supporting components reviewers should assess.

Excluded components

List omitted integrations or infrastructure and explain which assumptions about them remain necessary.

Deployment model

Identify target chains, proxies and expected initial configuration without sharing production secrets.

Critical properties

Describe the conditions that must hold for assets and permissions, including exceptional states.

Known issues

Provide previous findings and unresolved design concerns with their current status.

Deliverables

Specify report fields, evidence expectations and the format of fix verification.

Change procedure

Define how a new revision changes scope, schedule and price.

A scope statement should survive being read without the sales call.

Instead of saying review the vault, identify the vault implementation, its authorization dependencies and the deployment sequence that establishes those permissions. A reviewer should be able to tell whether a proposed issue belongs inside or outside the agreed boundary.

Describe excluded dependencies positively: the external price feed is assumed to meet the documented behavior, but validation of the consuming contract's handling of stale data remains included. That sentence makes a more useful boundary than oracles out of scope. The exact wording will depend on the design; the point is to preserve the integration question instead of deleting it with a broad exclusion.

Include source revisions for copied or modified library code. A recognized package name does not establish that the imported implementation is unchanged. When a dependency is intentionally treated as trusted, ask reviewers to state the assumption and identify behavior that would invalidate it.

1. Build the scope list from the deployment and call graph, then compare it with the repository paths.
2. Assign each external assumption an owner who can answer questions and supply evidence.
3. Ask each bidder to mark included, excluded or clarification required beside every scope item.
4. Resolve differences in the shared packet before comparing totals. Preserve the previous version so the change can be traced.

The strongest improvement may be a smaller coherent scope. A complete review of a defined release can be more useful than a broad promise about a system whose final design is unavailable. Record which later release or component will need separate assessment.

Make exclusions testable by giving an example at each difficult boundary. If custody operations are excluded, state whether the audit still checks contract permissions that authorize those operations. If front-end code is excluded, state whether the contract review assumes callers can bypass that interface. These examples help expose a scope statement that accidentally assumes away adversarial behavior.

A bidder should be able to identify information it needs before committing to effort. Keep these requests visible in the comparison rather than rewarding the bidder that asks the fewest questions. Relevant questions about accounting or deployment state can indicate unresolved work in the packet. Answer them once for all candidates and record which revision of the packet contains the answer.

After the proposals arrive, ask a technical reviewer to trace a high-consequence operation through the accepted scope. Every component on that path should either be included or have a justified trust assumption. The exercise does not replace an audit; it checks that procurement has not omitted the very question the audit is intended to investigate.

Deliverables and status fields to require

Ask for findings that connect behavior to impact. A title and severity are insufficient if the reader cannot identify the affected revision, preconditions or recommended change. Reproduction material should be appropriate to the issue: a local test, a transaction trace from a safe environment or a clear source-level argument.

Require definitions for status labels. Acknowledged can mean a team accepts a risk; it should not be interpreted as fixed. Likewise, a client saying a patch was merged is different from the reviewer confirming it addresses the finding. Our audit report explanation shows why this vocabulary changes how a public report should be read.

A proposal should state which contracts and upgrade paths are covered, how findings are ranked and how fixes are rechecked. Pharos Production's page on smart contract audit scope and remediation review describes severity-ranked findings, remediation guidance and re-verification. Use those deliverable categories to make the proposal concrete, then ask for the exact scope and acceptance terms for your engagement.

Agree on the publication format before work begins. Fixes may appear in an updated report, a separate document or a status appendix. The archive census above explains why a separate filename is not a reliable proxy for whether remediation was reviewed. Ask for the final revision and the meaning of each status, regardless of packaging.

For private reports, specify who will receive the document and whether a public summary can identify its scope accurately. A summary that omits unresolved material risks should not be used to imply broader assurance. Distribution terms are part of the requested deliverable, not a formatting detail to settle at launch.

Timeline and fix rounds

Separate review effort from elapsed calendar time. A calendar window can include waiting for answers, client remediation and a later verification slot. Comparing it directly with another firm's hands-on review allocation creates a false price-per-day calculation. Ask bidders to state the quantities in their own units and explain what each includes.

Preparation

Time needed to make the environment reproducible and resolve scope questions.

Initial review

The work allocated to investigating the agreed candidate revision.

Client remediation

The team's time to implement changes and produce evidence.

Fix verification

The review of those changes, including how regressions or expanded scope are handled.

Publication

The step that binds final findings and statuses to the release artifact.

A fix round needs a boundary. Clarify whether it covers only reported issues, nearby regressions or new functionality introduced by the patch. If the team redesigns an accounting component, the reviewer may reasonably need to revise the scope. That is easier to manage when the proposal has a change procedure rather than an unlimited-fixes slogan.

Ask what happens if a critical finding arrives near the planned launch. The relevant commitment is a communication and remediation process, not a promise to produce a clean report by a marketing deadline. Leave enough room for the team to change the release decision based on the evidence.

Candidate frozen

The initial scope binds work to a candidate revision.

Findings delivered

Reviewers communicate findings with their preconditions and impact.

Changes proposed

The client submits a new revision and responses for examination.

Fixes rechecked

Reviewers state which changes were checked and which risks remain.

Specify a contact who can answer design questions and a backup for absences. Delayed answers can interrupt investigation even when the source is frozen. Keep material answers in the issue tracker or shared clarification log so later reviewers can see which assumptions changed.

Do not treat a delay as a security benefit by itself. Extra time matters only if it funds useful work or resolves a dependency. A proposal should explain why its schedule fits the scope and how progress will be communicated.

Comparing quotes on equal terms

Normalize scope before normalizing price. A quote excluding the upgrade path cannot be compared directly with a quote that includes it. Request a revised option or keep the exclusion visible as a difference that affects the decision. Do not quietly assign an assumed cost to work the bidder has not priced.

Use examples of prior work to assess fit. A firm may have a strong reputation while lacking evidence for the architecture under review. Ask for a relevant report and read its scope, not only its client logo. The Halborn company analysis and other directory reports can guide the shortlist, while the bidder must confirm the people and work proposed for this engagement.

Keep any numerical scoring model transparent. If experience with a particular runtime is a requirement, state it as a requirement instead of burying it in a weighted score. A total score cannot repair a missing capability or an unresolved conflict over publication rights.

The audit contest comparison is useful when another proposal is actually a different delivery model. A contest, a private firm review and a formal verification engagement may all contribute evidence, but their outputs and follow-up arrangements need explicit comparison. Similar headlines do not make their quotes interchangeable.

Red flags in proposals

An unsupported guarantee deserves more scrutiny than an honest limitation. A proposal claiming complete security without a defined revision or assumptions provides no usable acceptance boundary. Ask the bidder to replace the promise with specific work and evidence. If it cannot, the uncertainty remains part of the procurement decision.

1. Flag a price that cannot be traced to included scope. Ask which components and deliverables the total covers.
2. Challenge ambiguous staffing language. Distinguish the people doing the review from those available for escalation or sales support.
3. Resolve vague fix terms before signing. Request the status definitions and the evidence that will identify the final reviewed revision.
4. Inspect a sample deliverable for unsupported severity labels or missing preconditions. A polished report still needs an argument the team can reproduce.
5. Check whether launch timing is being used to avoid unresolved findings. Keep the release decision separate from the requirement to complete the agreed work.

A small firm can provide a clear and useful proposal. A large firm can leave important terms unresolved. Evaluate the proposal's evidence and fit rather than using company size as a shortcut. The completed comparison should explain why the selected scope meets the project's needs and what security questions remain outside it.

Keep the final RFP beside the accepted proposal and report. When a later upgrade changes the system, those documents provide the baseline for deciding whether the new work is a fix review or a new engagement. That record is more durable than the summary of a sales call.