What breaks without a smart contract audit at the launch stage
A contract deployed on the network is immutable: code cannot be edited, and a fix requires migration — a new address, transfer of balances, reconnection of exchanges and partner integrations.
That is why an error in withdrawal logic discovered after deployment costs not hours of work but a restart of the entire circuit. Its cost has to be measured not in lines of code but in transfers of funds bypassing checks that can no longer be stopped retroactively.
There are few classes of failures, and all of them are predictable. Lack of access control on administrative functions — the call is open to any address, and the owner loses the treasury in a single transaction.
An error in withdrawal logic in the order of operations: an external call goes out before the internal balance is zeroed, and reentrancy allows the deposit to be withdrawn several times.
Bypassing checks in wrappers stands apart — the contract looks correct, but the price source or fee amount is substituted from outside.
Unit tests almost never detect such vulnerabilities: they check the happy path, not attacker behavior. You need to look at edge states — zero addresses, counter underflow on subtraction, the order of debits and credits, rights to pause and to complete the contract.
A working practice is running scenarios with hostile calls and comparing actual rights with the declared role model.
We break down how this is closed before deployment: exactly where the rights check is placed, how the order of operations in withdrawal is structured, and what is recorded in the report so the revision can be verified again.
What contract code review before and after launch provides
Vulnerability classes with the most expensive consequences are eliminated
The review follows the registry of known failure classes SWC Registry, not a general checklist: reentrancy, arithmetic overflow, uncontrolled external calls, errors in share distribution.
On a medium-complexity contract, this is 3–7 findings of "critical" and "high" severity removed before deployment to the network. Each comes with a reproducible test that failed before the fix and passes after: the result can be verified independently.
Owner access control stops being based on trust
We check what is actually available to the owner: token issuance, rate changes, withdrawal of funds, logic substitution through a proxy. We turn unlimited privileges into explicit roles with a delay for critical operations and a confirmation threshold.
The owner retains control but cannot single-handedly withdraw user funds: one compromised account no longer wipes out the project.
Emergency stop reduces incident response time
The contract gets a pause mode for key operations. With a ready procedure, the on-call shift handles an incident in minutes, not hours: stop, capture state, analyze transactions, update.
Without a prepared stop, the first hour goes into approvals while the vulnerability is already being exploited.
The vulnerability window shrinks
The vulnerability window is the time between code deployment and closing the hole. Pre-launch review removes it for found classes, post-launch review shortens it for new ones: updates and integrations go through the same review. Repeat reviews provide statistics — how many findings per release and which of them are closed.
Contract review methods and when each is appropriate
Contract review is not one procedure but a set of modes that answer different questions.
Automated analyzers filter out known error classes, manual contract review looks for logic and access control defects, formal verification proves declared properties, and a public bug bounty program brings in external researchers. No single mode replaces the others, so the set is selected for the task and project stage.
Comparison of review modes
| Mode | When appropriate | Limitations |
|---|---|---|
| Manual code reading | Protocol economics logic, roles and permissions, external calls, contract upgrades | Depends on reviewer experience and depth of immersion in the task; does not prove absence of a defect |
| Automated code analyzers | Every code change in the build pipeline, fast screening of typical errors | Produce false positives and do not see design errors |
| Formal verification | Computation core, balance invariants, limits, edge-state checking | Proves only the formulated properties; preparing the model takes more time than the review itself |
| Public bug bounty program | Contract is already on the network and under load, a constant flow of external findings is needed | Results come in waves; requires readiness for urgent fixes and code updates |
In practice, modes are combined: analyzers run on every code change, manual contract review — before release to mainnet, formal verification — for the computation core, public program — after launch.
Each mode covers its own class of failures, and together they cover the path from typical templates to protocol economics errors. We select the set based on project stage and contract criticality, without procedures that add nothing.
How the work proceeds: from code review to report handover
An audit is not a one-off analyzer run but a sequence with checkpoints: the result of each step determines what we check next. Below are the contract review stages and what is recorded as the output of each.
-
Context gathering and access preparation. We clarify the protocol economics, roles (owner, operator, treasury), external dependencies, and deployment order.
We agree on a repository at a pinned revision and a test environment with a copy of network state; changes after the start are recorded in writing, otherwise the report loses validity.
-
Threat model. We determine what we protect: user funds, issuance rights, liquidity, access to upgrades. For each asset, we describe scenarios — price manipulation, reentrancy, withdrawal through service functions, rounding errors. The model sets priorities: without it, we find many minor issues and miss one expensive one.
-
Code review. We go through critical paths, measure branch coverage, write out invariants, and break them on a local copy of the network. We confirm every finding with a reproducible scenario — we do not assign severity without proof.
-
Fix verification. We compare versions and answer two questions: does the fix close the original problem and does it not open a new one. A fix often reveals related defects in neighboring functions — we take them into the same cycle.
-
Re-run. We run the full set of scenarios on the final revision, not just the changed areas. We mark what is closed, what is accepted as residual risk, and what is rejected with justification.
-
Report handover. We deliver a document with findings by severity level, reproduction scenarios, and the status of each, plus a walkthrough with the team. On request, we prepare a public summary for users.
Set of documents and fixes based on review results
An audit ends not with a verdict "the code is safe" but with a set of artifacts that go into the repository alongside the contracts and are versioned with them.
Below is what remains with your team and works without the reviewers: during the next update, change of contractor, or release of a new contract to mainnet.
- Findings report — each issue is tied to a specific place in the contract and accompanied by an exploitation scenario. Severity levels (blocking, high, medium, informational) determine whether the contract can be released in its current form.
- Fix pack — changes are formatted as separate sets with an explanation of reasons and tests reproducing the original problem: the test passes — the fix is closed, not masked.
- Contract diagram — architecture description: roles and permissions, links between contracts, external calls, fund flow route. A new engineer uses it to enter the project without reading all the code.
- Access policies — separation of administrator and operator rights, multisig requirements, key rotation procedure, prohibition of unilateral actions with reserves.
- Incident response procedure — who and within what timeframes stops the contract, how parameters are updated, whom to notify about an anomaly; roles are assigned by name, not "the team will figure it out."
- Residual risk matrix — what is accepted consciously and under what conditions the decision is revisited.
- Closure mark — re-review of changed areas: what is closed and what remains an accepted risk.
Such a set turns a one-off review into a working document: the next revision starts from the changes, not from scratch.
Case study: findings before launch and what changed after fixes
A project with its own tokenomics was approaching deployment to mainnet, and two weeks before launch the team ordered a contract review.
The input was distribution, vesting, and an administrative layer for changing parameters; before that, the code had only undergone manual review by the developers themselves.
What was found before deployment
Static analysis via Slither together with manual path review produced 3 critical findings. Owner rights transfer went through a single call without confirmation — an error in the address handed over the entire contract. The role responsible for token issuance had no upper limit.
In the withdrawal function, funds were debited before the new balance was recorded, which opened reentrancy.
Everything was closed before deployment: rights transfer was moved to a two-step scheme with confirmation and a cancellation window, issuance was limited by a cap and multisig, and the order of operations in withdrawal was rewritten so that state is updated before the external call.
Metrics before and after
- Critical findings: 3 of 3 closed before deployment, high — 7 of 7.
- Failures of administrative calls due to access rights: 11% → 0.
- Response time to rights change: 6-8 hours of manual approvals → about 20 minutes per procedure.
- Test coverage of access control paths: 24% → 91%.
The difference is visible not in the report but in system behavior: critical defects were fixed at a stage where the cost of an error is one release, not a contract migration with loss of holder trust.
How smart contract audit differs from infrastructure review
A smart contract audit answers the question of what happens when code executes on the network: which states are reachable, who and when can withdraw funds, how the logic behaves at boundary values.
Infrastructure review answers a different question — who and how deploys this logic, where keys are stored, how access to nodes and the build pipeline is arranged. These are two different sets of risks, and one report does not replace the other.
The scope of the contract audit itself includes the logic of roles and permissions, the order of external calls, failure handling, state handling, and arithmetic.
A separate layer is external data sources: the contract is checked for its reaction to a stale, zero, or contradictory response, but the reliability of the source itself remains with its owner.
Static analyzers like Slither cover template defects, but the boundaries of authority and economics are still reviewed manually by an engineer — they cannot be formally described by a single rule.
Outside the boundary remains everything that lives outside the execution environment: administrator key management, multisig schemes, hardware wallets, team access, node configuration, and network perimeter.
The supply chain also belongs there — how code is built and updated, who has the right to change it, and whether there is a delay before it takes effect. These areas are covered by a separate review circuit, with its own tools and scenarios.
The point of separation is practical: the contract may be clean, and funds leave because of a stolen administrator key or a substituted data source.
Therefore, in the report these are two independent sections with different executors and different acceptance criteria, not one common list of findings. Understanding the boundaries in advance saves review time and removes unnecessary questions during incident analysis.
Concerns about access, timelines, and fixes after the review
Access to source code does not require publication: the review is conducted in a private repository with read-only rights, and after report handover access is revoked.
If the contract is already deployed, we work with its address and compiled code: a discrepancy between the source and what actually executes on the network itself becomes a finding.
Review timelines depend on the volume and interconnectedness of the code: a single token contract and a system of several modules are different scopes of work, so we provide an estimate after reviewing the code.
Fixes after the review are part of the process: we compare the fixes with the findings and confirm that each is closed or consciously accepted as a risk.
Can I provide only the contracts, not the entire repository?
Yes. For the review, the contracts themselves, tests, and deployment settings are sufficient. Code outside the perimeter is not needed, and we do not request access to infrastructure or keys.
What should be done if the contract is already deployed and fixes are impossible?
Then the report becomes the basis for a plan: what is closed by a new contract, what — by restricting rights, what — by stopping operations. For each item, we indicate whether the finding is being exploited now and under what conditions.
Who is responsible for the vulnerability after report handover?
Responsibility for the vulnerability remains with the contract owner: we find and describe the problem, and the project team decides on the fix. Disputed findings are reviewed again — if the scenario is not confirmed by the code, we remove the item.
Let's discuss the task: what to send for an estimate and work plan
So that the work estimate is based on the scope of tasks, not general wording, we need project inputs.
The more precisely the contract logic and its environment are described, the more specific the review plan will be — with a list of modules to be checked, the order of stages, and the points where we will come back to you with questions.
- Logic description: which methods are called, by whom and when, which states change, and which invariants must hold under any scenario.
- Address of the deployed contract and, if available, a link to the source code in the repository — we compare what runs on the network with what is in the branch.
- Role and access diagram: administrator, operator, multisig, who has the right to change parameters, stop the contract, and withdraw funds.
- Usage scenarios with edge cases: deposit, withdrawal, pause, update, migration, emergency stop.
- External dependencies: oracles, liquidity pools, bridges, calls to third-party contracts, and how unavailability of these services is handled.
- Materials from previous reviews: reports, comments, disputed decisions, and places where you consciously made a compromise.
- Your expectations for timelines and the acceptance procedure for the result.
Based on this set, we assemble a review plan: what is included in the scope, where static analysis applies, where scenarios with substituted values apply, where manual review of access rights and economics applies.
Then we send the scope of work, duration of stages, and allocation of responsibility — and discuss substantively. Describe the task, forward access and materials — we will return with an estimate and work plan.