A lot of teams write to an auditor while the code still changes every few days. The honest answer then is that nobody can give you a real scope yet. An audit reviews one commit, inside a scope, for a fixed number of days, and none of those three are stable while you're still building.
But that doesn't mean there's nothing to do until the freeze. Many of the serious findings in an audit aren't typos in the code. They're decisions: an admin key that can do more than anyone intended, a pause that also blocks withdrawals, an external call whose return value nobody thought about. Those get decided early, often in a few minutes, and by the time an auditor reads the code they're already in the storage layout and the tests.
This month I answered a few builders on public forums who were asking exactly these questions before shipping. Three of the threads show it well.
A chain deciding who it trusts, before there's a token
On the Polkadot forum, the builder of MADAR Network asked how to keep "one person, one vote" on their Polkadot SDK chain without collecting IDs. A 2-of-3 committee approves operators and runtime upgrades, and they were weighing a bond per operator.
Another forum member pointed out it's a Sybil and proof-of-personhood problem. I added that a bond can be slashed for equivocation, since double voting is provable onchain, but an operator who just stops voting has signed nothing you can slash. The unbonding delay also has to be longer than the window to report equivocation. And two of the three committee keys could admit their own operators and push an upgrade, so separate keys plus a delay on upgrades closes most of it.
Their answer: they're still on public testnet with no token, so this goes into the design before mainnet instead of being added later.
A private payments vault that changed its redeem function
On the Celo forum, a solo developer started building Envelope in public: tokens locked in a vault, a transferable NFT as the claim ticket, and a zero-knowledge redeem with a nullifier.
I asked who is really allowed to redeem, because a design that needs both the NFT and a secret lets the two drift apart once the NFT is sold, and whether the recipient and the relayer fee were bound into the proof, so nobody can copy a valid proof from the mempool. A wallet team asked what happens when a user loses the note data.
The planned contract changed. Redeem will burn the NFT in the same transaction as the proof, a holder's signature will let a relayer submit it so a fresh address needs no gas, and losing the note means losing the funds, so the app has to say that up front. Each of those touches a function signature or a storage layout. Cheap in month one of a four-month build.
An approval flow that couldn't say who approved
On the LangChain forum, a developer building an approval flow on LangGraph noticed that the record shows someone resumed the paused graph, not who.
Besides the identity part, I pointed at a second gap: the paused step runs again from the top on resume, so if the state changes in between, what executes can differ from what the approver saw. Put a hash of the proposed action in the pause and refuse to execute on a mismatch.
For any agent that can spend or call tools, "who approved what" is a design decision. It's much easier to make before the flow has users.
What to write down once the design settles
| Item | What it contains |
|---|---|
| System overview | One page: what it does, main flows, contracts or components |
| Assets and trust boundaries | What holds value, and every place your code trusts something it doesn't control |
| Privileged actions | Every role, what it can do, what it can't, who holds it, which delays apply |
| Assumptions and dependencies | External contracts with addresses and versions, compiler and library versions, evidence for each assumption |
| Test history | What's covered, which invariants are checked, what's known to be untested |
| Open questions | The ones you know are still open |
| Launch window | When, and what's fixed about that date |
| Frozen commit | Last, when the code stops moving |
Feedback is not an audit
A forum thread or a review call can change a design, and that's worth a lot. It doesn't read the code you deploy and it certifies nothing. Your tests prove what they test. Audit readiness means a reviewer can start on a fixed commit. An independent audit tells you what qualified people found in that commit, within that scope and time, and nothing about later commits.
One thing to do today
Pick the one assumption your protocol depends on most 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's the design question to settle while you're still building.
Adapted from a piece our team published on zealynx.io, which also has three hypothetical worked examples (a vault, an external integration and an agent that spends) and the forum links.
I wrote this with help from AI for drafting and editing. The opinions and the review experience are mine.
