Audit preparation
Ready for review. Before the clock starts.
We get a Solidity codebase to the state an audit firm asks for: frozen commit and scope, green suite, coverage at the bar, written specification, documented invariants, threat model, static analysis already triaged. We do not perform the audit — an independent firm does, and the split is deliberate.
N° 01The economics
Anything undocumented gets paid for twice
An audit firm quotes against a frozen commit and bills review hours for whatever is missing at it. A reviewer who has to reconstruct your intent from the code is writing your specification at review rates, which is the most expensive way to produce that document.
Then the same gap is charged again. The trust assumption you never wrote down gets argued about mid-review and lands in the report as a finding, because from the outside an undocumented assumption and a bug look identical.
Contest platforms make the arithmetic explicit. An issue you disclosed in writing before the contest opens is out of scope and pays nothing. The identical issue, undisclosed, is a valid finding that pays a warden and appears in your public report. The code is the same in both cases. Only the paperwork differs.
N° 02The bar
What a firm wants before it will quote
01
A frozen commit
A hash and a scope list, submitted before the window opens rather than on the morning it starts. Review platforms publish their own lead times and they are measured in days, not hours. A repository still moving on day one gets re-scoped, and re-scoping is billable.
02
A suite that passes
Green on the commit you froze, with line coverage at or above 90%, which is roughly where published readiness guidance sits. The stricter versions of it ask for branch coverage and mutation testing rather than executed lines. Coverage is a floor, not a result.
03
A written specification
What each contract is meant to do, including the state machine: which states exist, which transitions are legal, and what is supposed to be impossible. Without it, correctness has no referent and the reviewer is guessing at intent.
04
An actors and privileges map
Every role, what it can reach, and what happens if its key is lost or turns hostile. Reviewers reconstruct this first whatever you hand them, so handing it over converts a day of their time into a day of yours.
05
Static analysis, already triaged
Slither run and every finding either fixed or dismissed in writing with a reason. An untriaged tool dump means the reviewer re-triages it, and you pay for the same false positives at review rates.
06
Invariants and known issues
The properties that must hold for the system to be sound, written down and tested rather than implied. Alongside them, the list of things you already know are wrong or have deliberately accepted, so that whatever the report contains is genuinely news.
N° 03The freeze
One hash, and everything at it
Freezing is not tagging a commit on the morning the review starts. It means the reviewed code and the documents describing it sit at the same hash: specification, role matrix, invariant list, known issues, deployment scripts, and the CI run that produced the coverage number. A specification describing last month's state machine is worse than none, because the reviewer trusts it and the mismatch comes back as a finding you paid to receive.
The scope document then has to say what is not being reviewed. Which contracts are in, which dependencies are pinned and at what version, which library is inherited unmodified, which issues are already disclosed. Anything left undeclared is in scope by default, and scope you did not mean to buy is still scope you pay for.
The discipline costs something. From the freeze to the report, ordinary feature work happens on a branch nobody is reading, and the pull to slip one small fix into the reviewed tree is constant. A commit landed inside the window either invalidates the reviewer's context or is excluded from the report, and both are worse than waiting.
N° 04The deliverable
We wrote this set for our own code first
REChain is our reference build, a tokenized real-estate system deployed to Base Sepolia. It carries the package this page describes: a specification with the state machine written out, a role and trust matrix, twenty-five documented invariants each mapped to where it is enforced, a threat model, sixteen known issues, an audit scope document and deployment runbooks. Behind it, 131 tests at 98.3% line coverage, seven of those invariants driven as stateful campaigns at 256 random sequences each, zero Slither findings at medium severity or above, with Solhint and Slither gating CI.
It has not been audited, and we say so wherever it comes up. What it demonstrates is the shape of the handover, readable in full before you commission anything. Producing it also found eleven defects in our own contracts, two of them introduced by the fix for another. That is the part most teams underestimate: preparation surfaces bugs, and surfacing one before the quote is cheaper than surfacing it inside the review window.
On your codebase the work is the same list. Specification and state machine, role and trust matrix with the blast radius of each key stated, invariants written down and mapped to the tests that exercise them, threat model, known-issues document, static analysis triaged with inline justifications so anything new is genuinely new, coverage raised to the bar, and a stateful invariant suite where the repository has only unit tests.
N° 05The keys
The finding that is not about the code
Trail of Bits rates access control Weak on "single address controls entire system", and that rating is printed in the report whatever the contracts do. It is the most common serious finding in a first audit and the one least likely to be fixed by reading the Solidity, because it is a deployment fact rather than a code fact.
Preparation therefore covers where the keys end up. Powers that are not comparable get separate roles: a key that can print supply should not also be the key that can move somebody else's holding, and a contract that needs to mint should not inherit the ability to freeze wallets and halt the market. Parameter changes that can switch off every restriction at once go behind a timelock, so they are visible before they bind. The emergency pause deliberately does not — a control that needs three signatures at 3am is not a control.
Then the handover is made checkable. A script reads the whole role map back off the chain and fails if it disagrees with what was intended, and it is run twice: once during the announced wait while the deploying key can still correct a mistake, and once after the multisig accepts. We test that script by deliberately granting one key both issuance and seizure and confirming it refuses. A verifier that has never failed is one nobody has tested.
N° 06The calendar
The review window is the short part
A codebase in the region of a thousand lines occupies a firm for about a working week. What follows it is where schedules actually break: judging, your fixes, re-review of the fix diff, then the final report. Every fix is a new commit that has to be read as carefully as the code it repairs, so a report with a dozen findings is a fortnight of tail rather than an afternoon of patching.
Quotes for the same scope vary more than most teams expect, because firms price the calendar as much as the code. Treat an unusually cheap quote on a system that holds custody as a scoping error rather than a discount: escrowed funds plus a distribution contract is not the same review as a plain token, and a firm that priced it as one did not read the scope.
Preparation itself runs two to four weeks, driven mostly by how far coverage has to move and whether a stateful invariant suite exists at all. A repository with a green suite and coverage near the bar is a different job from one with a handful of unit tests and no written specification, and we say which you have, in writing, before quoting rather than after. Book the review slot before preparation finishes rather than after it: the queue is the part you cannot compress.
N° 07The boundary
We prepare it. Someone else signs it off
We are not an audit firm and we do not sell audits. The distinction is not modesty. The party that wrote the code is the worst party to certify it, because the assumption that produced the bug is the same assumption that would be used to look for it. If a studio offers to build and audit the same contracts, ask who reviews the reviewer.
So the engagement ends at the handover. You commission the firm directly and hold that contract yourself, we give you a shortlist and take no referral fee from anyone on it, and we do not argue severity on your behalf, because a studio negotiating findings down is negotiating about its own work. When the report lands we fix what it contains, each fix with a regression test, and the firm re-reviews the diff.
We also do not decide your legal structure. Which exemption you file under, what the offering documents say, whether the token is a security in a given jurisdiction: counsel's call, and we build to their answer rather than around it.
Investment
Fixed scope. No drift.
From $12,000 — the documents, invariants and coverage a firm asks for before it will quote.
- Written specification with state machine documentation
- Role and trust matrix, blast radius stated per key
- Invariants documented and mapped to the tests that prove them
- Stateful invariant suite where only unit tests exist
- Coverage raised to the bar the firm publishes
- Slither and Solhint gating CI, findings triaged in writing
- Threat model and known-issues document
- Audit scope document against a frozen commit
- Role architecture split by blast radius, timelock where it earns one
- Handover runbook and a script that verifies the role map on-chain
- Shortlist of independent firms, no referral fee taken
- Fix-and-regression pass on the findings that come back
Questions
The answers we give most often.
- Do you audit the contracts yourselves?
- No. We prepare a codebase for review and an independent firm performs the review. They are separate jobs, and doing both is a conflict of interest — the party that wrote the code carries the assumption that produced the bug into any check it runs on itself. We give you a shortlist of firms to quote from, we take no referral fee from any of them, and we are not a party to the engagement you sign.
- Which firms do you prepare for?
- We prepare to published requirements rather than to one firm's house style, because the requirements converge: a frozen commit and scope list, a green suite, coverage at or above 90%, a written specification, an actors-and-privileges map, triaged static analysis, tested invariants, and a known-issues document. Firms and contest platforms word it differently and ask for the same things. Where one publishes something specific — a coverage floor, a submission lead time, a scope template — we prepare to that document and check it is current rather than working from what it said last year.
- We already have a specification. Does that change the scope?
- Usually it shrinks it, and the first thing we do is check the specification against the code. That is where they normally fail: written at design time, then the code moved and the document did not. A specification that describes a state machine the contracts no longer implement is worse than none, because the reviewer trusts it and the mismatch becomes a finding. We scope down to what is genuinely missing and say so in writing.
- Does preparation make the audit cheaper?
- Sometimes in the quote, more often in what the quote buys. Firms price against scope and calendar, so a clean repository does not always come back with a smaller number — what changes is where the hours go. Time that would have been spent reconstructing your intent goes into looking for bugs, and the report comes back as defects rather than requests for documents you should have written. Where it does move the price is scope: a known-issues document takes things out of the report before the window opens, and on a contest platform a disclosed issue pays nothing.
- What if the audit finds something anyway, and can you fix it?
- It probably will, and that is what you are buying. What preparation changes is the character of the findings. Fixing is the normal end of the engagement: every fix ships with a regression test and is reviewed as adversarially as the code it repairs — in our own reference build two defects were introduced by the repair for another — and the firm then re-reviews the diff. A clean first report on a system holding custody is unusual enough that we would want to know why.
- Is this worth doing for a small codebase?
- Sometimes not. If you have forked an audited contract and changed a constant, the honest answer is a short diff review rather than a preparation engagement, and we will tell you that. Where it does pay is anything holding other people's money, because attackers do not price by line count. Be aware the saving from being small is less than you would expect: a specification, a role matrix and a threat model take similar work at four hundred lines as at nine hundred. What actually shrinks is the testing.
Next step
A reviewer reconstructing your intent is billing you to write your own specification.
Send us the repository, the commit you would freeze, and whether a firm is already booked.