Still building? What to settle before you scope an audit

TL;DR

An audit reviews one fixed commit, inside a scope, for a fixed number of days. While your code still changes every week, a scope is a guess and the findings can land on code you have already replaced.
The design questions don't have to wait for a frozen commit. Who holds the keys, what each role can and can't do, what an external contract returns, what an agent is allowed to sign: these decide your interfaces, and they are cheaper to change now than after an audit.
Three public threads from October 2026 show builders doing exactly this in the open: a Polkadot SDK chain deciding its trust boundary before mainnet, a private payments vault on Celo reshaping its redeem function, and a LangGraph approval flow working out what an approval record actually proves.
When the design settles, write it down: a one-page system overview, assets and trust boundaries, privileged actions, assumptions and dependency versions, test history, open questions, a launch window and, last, a frozen commit. That is what makes an audit proposal mean something.
Design feedback, your own implementation work, audit readiness and an independent audit are different things. A good forum thread or review call can change a design. It doesn't check the code that ships and it doesn't replace an audit.

A scope needs code that stopped moving

Every audit proposal rests on three numbers: which files, which commit and how many reviewer days. When a team writes to us with code that is still changing every few days, our answer is that none of the three is stable yet. The estimate is a guess, the commit we would review is not the one you will deploy, and the parts that carry the most risk are often the ones nobody has written yet.

That doesn't mean there is nothing to do until the freeze. Many of the serious findings in an audit are not typos in the code. They are decisions: an admin key that could do more than anyone intended, a pause that also blocked withdrawals, an external call whose return value nobody had thought about. Those decisions get made early, usually in a few minutes, and by the time an auditor reads the code they are baked into storage layouts, interfaces and tests.

So there are two clocks. The audit clock starts when the code stops moving. The design clock is running now. Our audit timeline guide covers the first one. This article is about the second.

Diagram of five stages, design, building, ready to scope, independent audit, and fix review then launch, split by a frozen commit into a design clock that runs now and an audit clock that starts at the freeze, with what each stage can and can't establish

Three public threads where builders settled design early

These are three threads from public forums in October 2026. We picked them because each one shows a builder asking a design question before shipping, and getting an answer that changed the design. Three threads are examples, not evidence of a trend. We replied in all three, alongside other people, so our own comments are part of what follows; we mark which points came from whom.

A chain deciding who it trusts, before there is a token

On 20 October 2026 the builder of MADAR Network, an independent chain on the Polkadot SDK, asked the Polkadot forum for feedback. The idea: one approved operator, one validator, one vote in finality, no staking. A 2-of-3 committee approves operators and runtime upgrades. Their question was how to keep "one person, one vote" without collecting IDs.

Another forum member answered that this is a Sybil and proof-of-personhood problem, and that unique identities alone give no economic security: nothing makes misbehaving expensive. The builder proposed a fixed bond per operator. In our reply we split that in two. A bond can be slashed for equivocation, because double voting is provable on chain, but an operator who simply stops voting has signed nothing you can slash, so stalling finality stays free unless there is an offline penalty. The unbonding delay also has to be longer than the window for reporting equivocation. And the committee's two keys could admit their own operators and push runtime upgrades, so separate keys for admission and upgrades, plus a timelock on upgrades, closes most of that. The first respondent then added that a fixed bond weakens as the chain holds more value, and suggested capping what the chain accepts at what the total bond covers.

The builder's last reply is the point of this article: "We're still on public testnet with no token on chain, so this can go into the design before mainnet instead of being added later."

Our reading: none of this needed audited code. It needed someone to write down who the trust anchor is and what each key can do.

A private payments vault that changed its redeem function

On 17 October 2026 a solo developer started a build-in-public thread on the Celo forum for Envelope: the sender locks tokens in a vault, a transferable NFT acts as the claim ticket, and the holder redeems with a zero-knowledge proof and a nullifier, so a claim can't be spent twice. The plan was four months of building in the open.

The questions came from three directions. Another forum member asked whether the ticket could go to a fresh address and whether release could wait for a milestone. We asked who is actually allowed to redeem, since a design that needs both the NFT and a secret lets the two drift apart when the NFT is sold, and whether the recipient and the relayer fee were bound into the proof so nobody watching the mempool could copy a valid proof and redeem to themselves. A wallet team asked what happens when a user loses the note data, and how a wallet would tell a real claim ticket from a spam NFT.

The developer's replies changed the planned contract interface. Redeem will burn the NFT in the same transaction as the proof, so a copied secret is worthless without the token. A permit-style signature from the holder will let a relayer submit the redeem, so a fresh address never needs gas. The recipient stays a redeem-time input rather than something fixed at mint. And losing the note means losing the funds, by design, so the app will tell users to back it up like a seed phrase.

Our reading: each of those changes touched a function signature or a storage layout. They are cheap during month one of a four-month build, and expensive in a fix review.

An approval flow that couldn't say who approved

On 28 October 2026 a developer building an approval flow on LangGraph asked the LangChain forum whether there was an idiom they had missed. The graph pauses for a human and resumes with a value, but the record shows that someone resumed it, not who. A run where an engineer read the arguments and approved looks the same as one where a script resumed everything.

In our reply we pointed to the authenticated user that a server deployment with a custom auth handler can attach to the resume run, and suggested testing it before relying on it. We also raised a second gap: the paused step runs again from the top on resume, so if anything changes the state in between, what executes can differ from what the approver saw. Putting a hash of the proposed action in the pause, and refusing to execute on a mismatch, binds the approval to the exact action.

Our reading: for any agent that can spend or call tools, "who approved what" is a design decision. It is much easier to make before the approval flow has users and a history you need to keep.

Three worked examples (hypothetical)

These examples are made up to show the kind of question worth settling while building. They are not anyone's real design.

Hypothetical 1: a vault whose withdrawal flow is still changing

A team building a yield vault adds a guardian role in week six, so someone can pause the vault if a strategy misbehaves. Two weeks later they add an emergency withdrawal for users.

Questions to settle now, before an auditor reads it:

Does pausing also stop the emergency withdrawal? If it does, the pause traps users in exactly the situation it was built for.
Can the guardian only stop things, or can it also move funds? Write both columns: what the role can do and what it must never be able to do.
What happens to a withdrawal that is halfway through when the pause lands, for example a request waiting for a strategy to unwind?
Who can change the guardian, and is there a delay on it?

Write the answers as a role table next to the code. Late-added roles are where access control gaps tend to sit, because the tests were written before the role existed.

Hypothetical 2: an integration with something you don't control

A protocol deposits idle funds into an external lending market and reads a price from an oracle.

Questions to settle now:

What does the external contract return, in which units and decimals, and can it return zero?
Can it pause, change its interest model or be upgraded by someone else? If yes, what does your contract do when that happens?
What happens to a very small deposit that rounds down to zero shares on the other side?
Which address and which version are you integrating with, and where is that pinned?

Write these down as assumptions with the evidence for each: a link to the external docs, the deployed address, the version you tested against. An assumption with no evidence is the first thing an auditor will ask about, and the first thing to break after launch. Our scoping guide covers how to document dependencies and the fork tests auditors look for.

Hypothetical 3: an agent that can call tools and spend

A team builds an agent that pays invoices through a payment tool, with a human approving anything above a threshold.

Questions to settle now:

Where does the spending limit live? A limit in the prompt is a suggestion. A limit in the code that signs is a limit.
Does the approval bind the exact transaction the human saw, or only "approved: true"?
Where is the key, and can any package the agent loads read it?
What gets recorded, and could you show later who approved which payment?

We covered the attacks behind these questions in five ways an AI agent's wallet gets emptied.

What to write down once the design settles

When the answers stop changing, put them in one place. This is the material that turns "can you audit us?" into a proposal with a real scope.

Item	What it contains
System overview	One page: what the system does, its main flows and its contracts or components.
Assets and trust boundaries	What holds value, and every place where your code trusts something it doesn't control. See threat modeling.
Privileged actions	Every role, what it can do, what it can't, who holds it and which delays apply.
Assumptions and dependencies	External contracts and services with addresses and versions, compiler and library versions, and the evidence for each assumption.
Test history	What the tests cover, which invariants are checked, any fuzzing, and what is known to be untested.
Open questions	The design questions you know are still open. Saying so is useful; hiding them wastes review time.
Launch window	When you want to deploy, and what is fixed about that date.
Frozen commit	Last, when the code stops moving: the exact commit and the files in scope.

The pre-audit checklist covers the final preparation in more detail, once you are close to a freeze.

Design feedback is not an audit

These four often get the same name, a security review, but they establish different things. Keeping them apart helps you pay for the right one and trust each for what it is.

Stage	What it can establish	What it can't
Design feedback (a forum thread, a peer, a review call)	That a design question was asked and answered; that a trust boundary or role was thought through	Anything about the code that ships. It certifies nothing.
Implementation work (your team)	That the code does what your tests check	What your tests don't check
Audit readiness	That a reviewer can start on a fixed commit with the context they need	Whether the code is safe
Independent audit	What qualified reviewers found in that commit, within that scope and time	That nothing else is wrong, or anything about later commits

An audit report describes one commit. If you change the code after it, the report no longer describes what you run; our post-audit security article covers what to do about that.

One thing to do today

Pick the one assumption your protocol most depends on that no test checks today. "The committee will never collude." "The lending market never pauses withdrawals." "The agent can't sign above the cap." Write it down, and next to it write what evidence would show it holds.

If you can't think of the evidence, that is the design question to settle while you are still building.

FAQ

1. When should we talk to auditors if our code is still changing?

Early enough to learn their lead times, late enough that the code has stopped moving when the review starts. You can ask for a rough estimate while building, but treat it as a range: the real scope comes from a frozen commit. Use the time before that to settle the design questions above, so the audit reviews decisions you have already made.

2. Can design feedback replace an audit?

No. Feedback on a design, from a forum thread or a review call, can change decisions before they are coded, and that is valuable. It does not read the code you deploy, it has no scope or coverage, and it says nothing about bugs in the implementation. An independent audit of a fixed commit is a separate step.

3. What should a one-page system overview include?

What the system does, its main user flows, the contracts or components involved, where value is held, which roles exist and what they can do, and which external contracts or services it depends on. If a new engineer could explain the system after reading it, it is enough to start with.

4. What is a frozen commit, and why does an auditor need one?

It is the exact version of the code that will be reviewed, identified by its commit hash, with no changes planned to the files in scope during the review. Auditors need it because findings refer to specific lines. If the code keeps changing, findings go stale and reviewer days go to code that will be replaced.

5. How do we know we are ready to scope an audit?

When the features in scope are complete, tests pass, the design questions are answered and written down, and you don't plan to change the in-scope code before launch except to fix findings. Our scoping guide lists what auditors ask for at that point.

Glossary

Term	Definition
Trust Boundary	A point where your system starts relying on something it doesn't control, such as a key holder, an external contract or user input.
Threat Modeling	Writing down what an attacker could want, where they could act and which assumptions protect the system.
Code Freeze	The point where the code to be reviewed stops changing, usually marked by a specific commit.
Audit Scope	The files, commit and assumptions an audit covers, and by extension what it does not cover.
Audit Readiness	Having the frozen code, documentation and context a reviewer needs to start without losing days to questions.
Timelock	A delay between scheduling a privileged action and executing it, so users can see it coming and react.

View complete glossary →