When we ship a smart contract system, the third-party audit isn’t the finish line. It’s a stress test of how well the development phase was run.
We work with auditors like Hacken and CertiK on most production deployments. Over time, you start to notice a pattern: the projects that come back with short reports and quick remediation cycles look completely different at the code level from the ones that come back with 40 page reports and three weeks of rework.
The difference isn’t talent. It’s discipline during development. Here are five things we deliberately get right before we hand a codebase over, because we’ve watched what happens when teams skip them.
1. The ownership graph is on paper before any contract is deployed
Every contract has owners. Multisigs, proxies, role admins, pausers, upgraders. By the time a system has more than three contracts, the ownership relationships start to look like family tree diagrams.
We’ve seen audit reports where the first finding is essentially: “It is unclear who controls the upgrade path.” That’s a finding the dev team should never have allowed to reach the auditor because they didn’t know either.
Before we write deployment scripts, we draw the ownership graph. Every contract, every role, every multisig threshold. One diagram, version controlled, reviewed by whoever holds the keys.
When the auditor opens the repo, that diagram is the first thing in the README. Half their access control questions answer themselves.
2. Oracle reads are wrapped, never raw
If a contract pulls a price from anywhere — Chainlink, Pyth, a custom feed, a TWAP (Time-Weighted Average Price) that read goes through a wrapper. Not the raw oracle call inline.
Why: the wrapper is where you put the staleness check, the deviation check, the fallback logic. It’s the chokepoint where you can say “this is what we do if the price is stale, wrong, or zero.” Without it, those checks get scattered across the codebase or, more commonly, forgotten entirely.
Auditors love wrappers because they collapse the audit surface for oracle-dependent logic. One function to verify instead of forty inline reads.
We’ve had reports where the entire oracle-handling section was two paragraphs because there was nothing else to say.
3. State changes happen before external calls. Always.
Checks-Effects-Interactions is a pattern from 2016. It still catches bugs in 2026.
Reentrancy hasn’t disappeared — it’s gotten subtler. ERC-777 callbacks, ERC-721 receivers, custom hooks in token routers — all of them give external code a chance to re-enter your contract mid-execution. The defense isn’t really nonReentrant modifiers. Those help, but they’re a backstop.
The real defense is that any state variable controlling a balance or an authorization gets written before any external call. Period. We grep for this pattern in code review.
If a function calls out before it finishes updating state, that function gets rewritten. It’s not a stylistic preference it’s the difference between a clean audit and a critical finding.
4. Every event tells the truth
Events look like a logging concern. They aren’t. They’re the contract’s API surface for every off-chain system that reads it — indexers, subgraphs, monitoring dashboards, compliance tools.
We’ve seen contracts that emit Transfer(from, to, amount) from functions that don’t always actually transfer. Or events fired before revertable external calls, so the event lies when the state change rolls back.
By the time the subgraph diverges from on-chain reality, you have a very expensive reconciliation problem.
Before we hand a codebase to an auditor, we do an events pass: every emit must be after the state change it describes, and the parameters must reflect what actually happened, not what the function was supposed to do.
5. The upgrade has been rehearsed against forked mainnet
This is the one we get asked about least and matters most.
If your contracts are upgradeable, the upgrade is part of the system. It needs to be tested with the same rigor as the contracts themselves.
Storage layout collisions, initializer reentrancy, proxy selector clashes — none of these appear in unit tests. They appear the first time you push a real upgrade against real state.
So before the auditor gets the code, we’ve already done at least one full upgrade dry run on a mainnet fork. The forked-state test, the upgrade transaction, the post-upgrade invariant checks.
If it works there, it’ll work on mainnet. If it doesn’t, we’d rather find out before the audit clock starts ticking.
Why this matters for the audit phase
Third-party audits aren’t expensive because the auditors are expensive. They’re expensive because the second round is. The first review finds issues; you fix them; they re-review. That cycle is where budgets blow up and launch dates slip.
Everything above is designed to make round one short.
When the ownership graph is clear, the oracles are wrapped, the state changes are ordered correctly, the events are honest, and the upgrade has been rehearsed — the auditor’s job gets a lot smaller.
The report comes back faster. Remediation is two days, not two weeks. The launch holds.
We don’t replace the audit. Hacken and CertiK do work we can’t do independent verification, formal methods, adversarial testing at a level that only a dedicated audit firm can offer.
Our job is to hand them code that’s already been built to survive their review.
That’s the dev team’s contribution to a clean launch. The audit is downstream of it.
Bitronix Technologies builds enterprise smart contract systems for regulated industries engineered to ship through audit and into production. If you’re scoping a contract system that has to hold up under third-party review, book a 30-minute call.
Five things we fix before the audit firm sees the code was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.