Quick answer: Every detail you leave out of your security audit RFP gets replaced by a padded assumption, and you pay for it. A complete RFP gives firms eight things: GitHub repository and commit, size in nSLOC, scope boundaries, architecture and docs, external dependencies, novelty flags, timeline, and deliverables. It requires seven things back: named security auditors, auditor-days, methodology, comparable past work, exact dates, total cost including post-fix review, and what happens if they miss something. Get both halves right and quotes become genuinely comparable instead of five numbers you can't reconcile.
Why vague RFPs cost you money
When a firm receives "we need an audit, here's the repo, how much?", it has to price the worst plausible version of your engagement: messy code, missing tests, an unresponsive team, scope that expands mid-review. That risk premium is invisible on the invoice but it's there, and on a mid-size DeFi protocol it's routinely 20–40% of the quote.
The second cost is worse: you can't compare what comes back. One firm quotes two weeks of one senior researcher. Another quotes three weeks of two mid-level reviewers plus a retest. A third quotes the same number as the first but excludes the fix review. Without a structured RFP those are three unrelated documents, and buyers default to the cheapest, which is how teams end up with a purchased PDF instead of a security review.
A precise RFP fixes both. It also does something less obvious: writing it forces you to enumerate your own integrations, admin powers and upgrade paths, which is a security exercise in itself. Teams that can't describe their scope crisply usually find out why during the audit.
Part 1: How to prepare for a smart contract audit (what you give the firms)
1. The exact code
- Repository URL, and whether it's public or private
- Commit hash or tag to be audited, not "main". Main changes daily; a hash is a contract. Declare a code freeze on that commit for the duration of the review, or you'll be paying for findings against code you've already replaced
- Branch, if it isn't the default
- Access method for private repos: firms will supply GitHub usernames for read access. If you require an NDA before access, say so upfront and attach it
2. Size, stated in numbers
- nSLOC (normalised source lines, excluding comments and blank lines) of in-scope code. Run
cloc,solidity-code-metricsortokei; it takes five minutes - Number of contracts / modules / programs in scope
- Language and framework versions: Solidity 0.8.x, Anchor version, CosmWasm version, Cairo version. Firms scope very differently per runtime
- Test coverage percentage, honestly stated
Skipping nSLOC is the single most common omission, and it's the number most firms price from. Omitting it guarantees a hedged quote.
3. Scope boundaries: in and out
- In scope: list every file or directory to be reviewed
- Out of scope: mocks, tests, vendored libraries, previously audited dependencies, frontend, infrastructure. Say so explicitly
- Interfaces between them: where in-scope code calls out-of-scope code, note it. That boundary is where a lot of real vulnerabilities live, and firms need to know whether they're expected to reason about it
4. Architecture and documentation
- Whitepaper or technical spec, if one exists
- Architecture diagram: even a rough one materially speeds up onboarding
- Intended behaviour per contract: two lines each is enough
- Flow of funds: where value enters the system, where it's held, and every path by which it leaves. Reviewers build this map anyway; handing it to them buys you review hours instead of onboarding hours
- Roles and permissions: who can call what, which addresses are trusted, which components are untrusted
- Key invariants: what must always be true? "Total supply never exceeds cap", "no user can withdraw more than they deposited". This is the highest-value paragraph in your entire RFP, because it tells reviewers what to try to break
- NatSpec / inline docs coverage
5. External dependencies and integrations
Every protocol you touch is attack surface a reviewer has to understand:
- Oracles (Chainlink, Pyth, custom) and how you handle staleness or manipulation
- DEXs, lending markets, bridges, messaging layers (LayerZero, Wormhole, IBC)
- Token standards with non-standard behaviour: fee-on-transfer, rebasing, ERC-777
- Chains deployed to, and any cross-chain assumptions
6. Novelty and risk flags
State these plainly. Hiding them buys you a mispriced engagement and a shallow review:
- Custom mathematics, curve design, or economic mechanisms not seen elsewhere
- Assembly / low-level calls
- Upgradeability pattern (UUPS, transparent proxy, diamond) and who controls upgrades
- Admin powers, privileged roles, multisig configuration, timelocks
- Anything you already suspect is fragile. A good firm will thank you and price it accurately
Worth writing a short threat model alongside this, even three or four lines: who profits from breaking this system, what they'd target first, and where you're exposed to oracle manipulation or flash-loan attacks. Most teams never do it, and the ones that do get noticeably sharper reviews, because the firm starts from your adversary rather than inventing one.
7. Timeline
- Preferred start window and how flexible it is
- Hard deadlines and what drives them: mainnet launch, listing, TGE, grant milestone
- Your availability during the review. A responsive dev on Telegram or Slack is worth real money to reviewers
- Retest window: when will fixes be ready?
Flexible start dates earn discounts. Rush work carries 20–40% premiums. Be honest about which you are, because firms price scheduling friction either way.
8. Deliverables and commercial terms
- Report format, and whether you need a public report
- Whether a fix-review / retest round is required (it should be)
- Severity classification standard you expect
- Payment terms and currency
- Any compliance requirement: MiCA evidence pack, exchange due-diligence questionnaire, insurer documentation
A note on budget
Include it. A stated budget acts as a filter in both directions: it screens out premium firms whose rates your protocol can't accommodate, and it screens out smaller firms who can't realistically cover your scope. Both of those are wasted cycles for everyone, and firms appreciate knowing before they invest hours in scoping.
The alternative is deliberate: leave budget blank and you see the unfiltered market rate and the full spread across firms, which on identical scopes is routinely 3–5x apart. That's useful if you're early in planning and trying to understand what your audit should actually cost.
Part 2: Questions to ask every audit firm
This is the half most teams skip, and it's what makes quotes comparable. Ask every firm to answer the same questions in the same structure.
1. Who is actually doing the work?
Names, not the firm's logo wall. How many reviewers, at what seniority, and what has each of them published? A top firm's junior pairing can be weaker than a boutique's senior specialist. This is the single most predictive question you can ask.
2. How many auditor-days, and how are they distributed?
Total effort, split across reviewers, with a rough day-by-day or week-by-week shape. Two quotes at the same price can hide a 2x difference in effort.
3. What methodology will you apply to this codebase?
Not a generic list. Which tools (Slither, Echidna, Medusa, Foundry fuzzing, Certora), whether fuzzing or invariant testing is included, whether formal verification is in scope, and how manual review time is split against tooling.
Then add the follow-up that separates a real audit from a checkbox one: "what invariants did you write that we hadn't already identified?" Ask it of candidates about their past work, and ask it again of whoever you hire when the report lands. A firm that only tests the invariants you handed them has verified your assumptions. A firm that found properties you'd missed has actually modelled your system.
4. Show comparable engagements
Public reports from the last 18 months in your runtime and protocol category. Not "we've done DeFi", but a lending protocol on the same stack. If they can't produce relevant examples, that tells you something.
5. Exact timeline
Start date, review end date, draft report date, retest date, final report date. A quote without dates is not a quote.
6. Total cost, itemised
Base review, retest, any additional rounds, expenses. Explicitly ask: what is the all-in number including one fix-review round? Retests are the most common hidden 10–20%, and comparing quotes that include them against ones that don't is how buyers pick wrong.
7. What happens if you miss something?
Ask directly. Some firms offer a coverage pool or bounty-backed guarantee; most offer nothing. Neither answer is disqualifying, but you should know which you're buying, and the way a firm answers tells you a great deal about how it thinks about accountability.
Two more worth adding for higher-stakes engagements
Availability of the named team. Is the senior researcher you're being sold actually assigned, or aspirational? Ask for confirmation in writing.
Communication model. Shared channel, weekly sync, mid-review checkpoint? A firm that surfaces criticals as it finds them rather than at report delivery gives you days back on remediation.
The 60-second quality test
Before you send it, check your RFP answers these five questions without anyone having to ask:
- What exactly am I reviewing, at what commit, and how big is it?
- What must never happen in this system?
- What's unusual or risky about it?
- When do you need me, and how firm is that?
- What do I get at the end, and does it include the retest?
If any answer requires a follow-up email, expect that firm's quote to include the cost of the uncertainty.
Run it as a competition, not a negotiation
Send the identical RFP to 5–10 matched firms with the same response deadline. Simultaneous beats sequential: firms quote sharper when they know it's competitive, and you can compare like against like because you asked everyone the same questions.
That's precisely what Procur3 does. Post your scope once, select the right service category so the firms with relevant experience are notified, attach your NDA if you need one signed before repo access, and set your submission window. Five to seven working days is a good default. Quotes come back structured and comparable, alongside each firm's public track record.
If you'd rather not open your repository to every matching firm, shortlist two to five and run a private, invite-only RFP, the better choice for higher-stakes audits where the decision should turn on quality and deliverables rather than price.
FAQ
How long should a smart contract audit RFP be? One to two pages of structured detail beats ten pages of prose. Firms are looking for specific facts: commit, nSLOC, scope, integrations, invariants, dates. Give them those and nothing is wasted. Procur3's RFP templates are built on this structure, battle-tested across Layer 1s and DeFi protocols and facilitating over $1 million in security transactions.
Should I include my budget in the RFP? Yes, in most cases. A stated budget filters out premium firms whose rates don't accommodate your protocol, and smaller firms who can't realistically cover your scope, saving both sides wasted cycles. The alternative is to leave it blank and see the going market rate and the full spread across firms, which is the better choice if you're still working out what your audit should cost.
How long should I give firms to respond? Five to seven working days for a typical scope. For larger or more complex engagements, give at least ten working days, because strong firms have booked schedules and a rushed window either excludes them or produces a hedged quote. Set the window, then you're ready to post.
Do I need an NDA before sharing my repository? Only if the code isn't already public. Check first, since many teams request NDAs for repositories anyone can read. If it's genuinely private, attach a pre-signed NDA to the RFP so firms can sign and get access without a legal round-trip.
What if I don't know my nSLOC or invariants yet? Then you're not ready to send the RFP. Both take under an hour to produce, and both materially reduce your quote. Do them first.