Smart contract security audit: what does it cover?

It is a structured attempt to find code vulnerabilities, broken assumptions, and dangerous design choices before immutable logic starts moving real money.

That distinction matters because the most expensive failures are rarely caused by one obviously bad line of Solidity. They usually sit at the intersection of permissions, upgrade paths, oracle design, liquidity flows, and edge cases the original team never modeled. In 2025, access control failures were linked to 53% of Web3 losses, representing $2.12 billion of a reported $4.0 billion total. Smart contract vulnerabilities accounted for another $512 million, or 12.8%.

The headline from the hallway track is simple: an audit lowers risk, but it does not bless a protocol forever. Code changes. Governance changes. Oracles move. Attackers keep reading.

What a professional smart contract security audit actually includes

A serious audit follows a five-stage process. The order is not decorative. Each stage answers a different question, and skipping one usually creates a blind spot that the next stage cannot fully repair.

1. Scoping and commit-pinning

The audit starts with a precise definition of what is being reviewed.

The auditor and project team agree on:

• Which contracts are in scope.
• Which deployed addresses, libraries, interfaces, and dependencies matter.
• Which compiler version and optimization settings are being used.
• What commit, branch, or release candidate represents the audited code.
• Which functions are upgradeable, externally callable, privileged, or economically sensitive.
• What assumptions the protocol makes about tokens, oracles, bridges, keepers, and administrators.

Commit-pinning is one of those details that sounds operational until it saves everyone from arguing over whether the reviewed code was the code that eventually reached mainnet. If the project changes a pricing function, adds a pause role, or adjusts a liquidation threshold after the audit, the security status of the system has changed—even if the change looks minor in a Git diff.

This is also where the auditor should understand the product’s intended behavior. A lending protocol, NFT marketplace, cross-chain bridge, and liquid staking system can all be written in Solidity, but their threat models are not interchangeable.

A token contract may have a relatively small codebase but still require careful review of minting privileges, blacklist logic, transfer hooks, and upgrade controls. A DeFi protocol may involve pools, shares, debt accounting, price feeds, liquidations, flash loans, and multiple external integrations. The line count is not the risk model.

2. Architecture and threat-model review

Before reading every function, auditors need to understand the system as a machine.

That means asking:

• Where does value enter and leave?
• Which contracts hold funds?
• Who can change parameters?
• What happens if an oracle stops updating?
• Can a user call a function twice in the same transaction?
• What happens when liquidity is thin?
• Which assumptions depend on a trusted relayer, multisig, bridge, or off-chain service?
• Can governance upgrade the implementation without a timelock?
• What happens during an emergency pause or partial failure?

This phase catches design flaws that automated scanners often cannot interpret. A tool may correctly report that a function is externally callable. It cannot always tell whether that is the intended user flow, an exploitable privilege boundary, or a harmless callback.

The threat model should cover both malicious users and compromised privileged actors. A protocol may be safe against an ordinary wallet but dangerously exposed if an owner key is lost, a governance proposal is rushed through, or an upgrade administrator can replace the implementation instantly.

For a DeFi smart contract audit, economic behavior belongs in this stage as much as technical behavior. A contract can execute exactly as programmed and still allow a profitable manipulation because its assumptions about price, liquidity, or collateral are unrealistic.

3. Deep code review: manual analysis plus automated tools

This is the part most teams imagine when they hear “audit,” but it is only the third stage.

Auditors combine line-by-line manual review with automated analysis, testing, fuzzing, and, where appropriate, formal methods. They inspect how functions interact across contracts rather than treating each function as an isolated unit.

The review usually examines:

• State changes before and after external calls.
• Authentication and authorization.
• Token accounting.
• Rounding and precision.
• Reentrancy protections.
• Upgradeability and initialization.
• Oracle freshness and price bounds.
• Emergency controls.
• DoS and gas-related failure modes.
• Cross-contract assumptions.
• Administrative actions and governance execution.
• Unusual ERC-20, ERC-721, ERC-777, or ERC-1155 behavior.

A professional review also traces the “happy path” and the ugly paths. What happens when a transfer returns false instead of reverting? What happens when a token charges a fee? What happens when a callback re-enters before balances are updated? What happens when a position is liquidated at the exact boundary of a collateral ratio?

Those are not theoretical flourishes. They are where protocols discover that their internal model of a token or user was too tidy for the real chain.

4. Reporting and severity classification

The report should turn technical findings into decisions.

A useful audit report normally classifies findings by severity, explains the affected code path, describes the impact, and provides a recommended remediation. The exact labels vary between firms, but the practical distinction is usually between issues that can directly cause loss or takeover, issues that can disrupt protocol behavior, and lower-severity weaknesses that increase operational or maintenance risk.

A strong finding answers five questions:

1. What is wrong?

2. Under what conditions can it be triggered?

3. What can an attacker or privileged user gain?

4. Which contracts, functions, or assumptions are affected?

5. What change would reduce or remove the risk?

“Improve access control” is not a useful finding by itself. “The emergency withdrawal function can be called by any address because the role check is applied to the pause function but not the withdrawal branch” is actionable. The project team can reproduce it, fix it, and test the fix.

Severity is not the same as drama. A small-looking permission issue can be critical if it reaches a vault holding user funds. A complicated denial-of-service edge case may be serious for a bridge but low priority for a test deployment. Context does the work.

5. Fix verification and re-audit

The original audit is not the end of the process. It is the beginning of the remediation loop.

After the team addresses findings, auditors should verify the fixes against the original issue and check whether the change created a new problem elsewhere. This is why commit-pinning matters again: the auditor needs to know exactly what changed between the reviewed version and the release candidate.

Re-audits are often billed separately. A remediation pass typically adds between $5,000 and $20,000, depending on the number of findings, the size of the changed code, and whether the fix touched core architecture.

The cheapest way to make this stage painful is to wait until the final day before launch. When fixes are made under deadline pressure, teams tend to patch the symptom, modify adjacent logic, and introduce a second vulnerability while trying to close the first one.

An audit is a review of a specific code state, not a permanent insurance policy for a protocol.

The vulnerability classes auditors care about most

The exact checklist changes with the protocol, but several vulnerability families appear repeatedly across smart contract security reviews.

Access control: the quiet route to catastrophic loss

Access control failures remain one of the most consequential categories because they allow the wrong actor to perform the right action.

A contract may expose functions that can:

• Mint or burn tokens.
• Withdraw funds.
• Change an oracle.
• Modify collateral factors.
• Upgrade an implementation.
• Set fees.
• Pause or unpause transfers.
• Add a trusted signer.
• Change bridge validation rules.
• Sweep stranded assets.

The common mistake is checking whether a function has a modifier without checking whether the role itself is configured correctly. A contract can contain a perfectly written onlyOwner restriction while the owner is an externally owned account with no operational safeguards, an incorrectly initialized proxy, or a compromised key.

Auditors inspect role assignment, role revocation, initialization, proxy admin controls, multisig thresholds, timelocks, and the relationship between governance and emergency powers. They also check whether a privileged function can be reached through another public function that lacks the expected restriction.

The 2025 loss figures make the point without much help from marketing: permission boundaries deserve more attention than many teams give them.

Reentrancy: not just the old withdrawal example

Reentrancy happens when a contract makes an external call before completing its internal state updates, allowing the called contract to invoke the original contract again in an unexpected state.

The classic example involves withdrawing funds before reducing a user’s balance. But modern reentrancy analysis is wider than that pattern. Auditors look at:

• ERC-721 and ERC-1155 receiver callbacks.
• ERC-777 token hooks.
• Flash-loan callbacks.
• Cross-contract reentry.
• Read-only reentrancy.
• Reentry through routers and vaults.
• Reentry during liquidation or settlement.
• Reentry that changes pricing or share calculations.

A nonreentrant modifier can be useful, but it is not a universal answer. It may protect one function while leaving an economically connected function exposed. It may also block a legitimate composability path without fixing the underlying accounting sequence.

The better question is: what state must be finalized before control leaves the contract, and what assumptions remain valid if the external call invokes the system again?

Oracle manipulation and flash-loan attacks

DeFi protocols often rely on external prices to determine how much a user can borrow, how many assets they receive, or whether a position should be liquidated.

If the protocol uses a thin liquidity pool, a manipulable spot price, or an oracle with weak freshness checks, an attacker may temporarily distort the market and extract value. Flash loans make this more efficient because the attacker can access substantial capital within one transaction, provided the transaction ends profitably.

An audit examines:

• The source of the price.
• The time window used for the price.
• Liquidity and volume assumptions.
• Deviation limits.
• Staleness checks.
• Sequencer or network outage behavior.
• Decimal conversions.
• Fallback oracle behavior.
• The response to extreme price movements.

The vulnerability is not always “the oracle is wrong.” Sometimes the oracle is functioning exactly as designed, while the protocol consumes it in a way that creates an exploitable mismatch between market conditions and accounting.

For example, a system may value collateral using one asset price while allowing borrowing against another with a different update cadence. Each input can be individually reasonable. The combination can still produce an opening for manipulation.

Integer overflow, underflow, rounding, and precision

Solidity versions from 0.8.0 onward include built-in checks for many arithmetic overflows and underflows. Older versions do not, which makes arithmetic review especially important in contracts compiled with Solidity below 0.8.0.

That does not mean newer Solidity code is automatically safe. Auditors still examine:

• Division order.
• Rounding direction.
• Share-price calculations.
• Decimal mismatches between tokens.
• Signed and unsigned conversions.
• Cumulative interest.
• Fee accounting.
• Values that are truncated to zero.
• Extreme input values.
• Repeated small operations that accumulate error.

Rounding can become an economic vulnerability when a user can repeat a favorable operation many times, or when a protocol consistently rounds in one direction. In a vault, a tiny share-price discrepancy may look harmless in a unit test and become meaningful after thousands of deposits, withdrawals, or donations.

Front-running and sandwich attacks

Public blockchains expose pending transactions to participants who can react before execution. That creates risks for swaps, mints, liquidations, governance actions, and any transaction whose outcome depends on the order in which it lands.

Auditors look for:

• Missing slippage limits.
• Unprotected price-sensitive functions.
• Predictable order parameters.
• Weak commit-reveal schemes.
• Public liquidation opportunities.
• Transactions that can be profitably sandwiched.
• Governance actions that can be observed and pre-positioned around.

Not every front-running exposure is a code defect. Some are inherent to the application’s execution environment. The audit should distinguish between unavoidable market behavior and a preventable design choice, such as failing to include a minimum output amount.

Upgradeability and initialization errors

Upgradeable contracts introduce another control plane. The implementation may be reviewed, but the proxy, initializer, admin, storage layout, and upgrade process also need attention.

Typical issues include:

• An initializer that can be called by an unauthorized address.
• An implementation contract left uninitialized.
• Storage collisions between versions.
• An upgrade admin with excessive power.
• Missing timelocks or notification periods.
• A new implementation that breaks inherited assumptions.
• A proxy pointing to the wrong implementation.
• An emergency upgrade path that bypasses governance.

The launch conversation often focuses on whether the contract is “audited.” The more useful question is which upgrade authority exists after launch and what stops that authority from changing the audited behavior tomorrow.

Automated tools are valuable—but they do not replace judgment

Automated analysis is now standard in a serious blockchain security audit. Tools such as Slither, Mythril, MythX, Echidna, and Manticore can identify patterns, generate test cases, explore unusual inputs, and surface suspicious behavior early.

They are particularly useful for:

• Static analysis.
• Detecting common Solidity anti-patterns.
• Fuzzing arithmetic and state transitions.
• Testing invariants.
• Exploring revert conditions.
• Finding unreachable or inconsistent code.
• Checking certain reentrancy and access-control patterns.
• Stress-testing functions with unexpected inputs.

Fuzzing is especially powerful when the team can state a property that should always remain true. For example: total shares should not increase without a corresponding asset inflow; a user should not withdraw more than their recorded balance; debt should not become negative; or an unauthorized account should never change a risk parameter.

But automated tools work within the properties and patterns they can observe. They do not automatically understand that a protocol’s liquidation threshold is economically unsafe, that a bridge’s validator set is too concentrated, or that governance can approve a malicious upgrade through a technically valid but poorly constrained path.

Manual review contributes context. The auditor reads the architecture, follows value flows, challenges assumptions, and tries to break the protocol as a system.

The scanner catches the loose wire. The human reviewer asks why the whole building is wired that way.

How much does a smart contract audit cost in 2026?

The smart contract audit cost depends on complexity, chain, scope, timeline, documentation quality, and the maturity of the codebase. There is no credible universal price per line of code.

A simple token contract may cost around $5,000. Enterprise-grade, multi-chain systems can exceed $250,000. Mid-complexity DeFi protocols commonly fall in the $40,000 to $100,000 range.

Those numbers become more understandable when you look at what the auditor is actually pricing. The engagement may involve architecture review, threat modeling, manual analysis, automated testing, test-suite repair, deployment validation, report writing, meetings with developers, and remediation review. A small contract with unusual mechanics can require more expertise than a larger but conventional codebase.

Non-EVM systems also carry a premium. Audits for Solana programs written in Rust, Cairo-based systems, and ZK-focused stacks can cost 20% to 120% more than an equivalent EVM review because the pool of specialized auditors is smaller and the tooling and failure modes differ.

A rough comparison looks like this:

The timeline matters too. A team that wants an audit in a compressed launch window may pay more for priority work while receiving less room for iterative fixes. That is a poor trade if the protocol is still changing materially during the engagement.

A useful scoping conversation should cover:

• The exact commit being reviewed.
• Whether tests and deployment scripts are included.
• Whether external dependencies are in scope.
• Whether economic simulations are required.
• Whether the audit includes a re-audit.
• How many remediation passes are expected.
• Whether the report covers only code or also architecture and operational controls.
• Which chains and compiler configurations are included.

The cheapest quote is not necessarily the cheapest security outcome. A narrow review that excludes the oracle adapter, proxy admin, or bridge message validation may produce a polished report while leaving the main attack surface untouched.

Why an audit is necessary—but never a guarantee

A smart contract security audit reduces uncertainty. It does not eliminate it.

Auditors review the code and assumptions available at a particular point in time. After deployment, the protocol may add a new token, connect to a new bridge, change an oracle, transfer ownership, modify governance, or upgrade the implementation. Each change can create a new risk profile.

There are also limits that no audit can remove:

• Auditors can miss unknown vulnerabilities.
• Economic attacks can depend on market conditions that did not exist during testing.
• External protocols may behave differently after an upgrade.
• Privileged keys can be compromised.
• Governance can approve dangerous parameters.
• Users can interact with contracts in combinations the team did not anticipate.
• A secure contract can become exposed through an insecure integration.
• A formally correct function can still implement the wrong business rule.

This is why mature teams treat the audit as one layer in a broader security program. That program may include internal review, independent audits, bug bounties, monitoring, circuit breakers, rate limits, multisig controls, timelocks, incident response procedures, and carefully limited upgrade authority.

The order matters. Security monitoring cannot undo a withdrawal that already drained a vault. A pause mechanism is useful only if it is correctly permissioned and operationally ready. A bug bounty helps after launch, but it should not be the substitute for basic review before launch.

The difference between code risk and protocol risk

The words “smart contract security” often point too narrowly at source code. Protocol risk is broader.

A cross-chain bridge, for example, may have contracts that pass a conventional review while the validator architecture remains too centralized. A lending market may have clean arithmetic but rely on an oracle whose liquidity is too shallow. A DAO may have well-tested proposal execution but no delay between approval and implementation. An NFT infrastructure layer may protect minting logic while leaving signature replay or royalty accounting inconsistent across marketplaces.

The audit should expose these boundaries rather than hide them. If an assumption is out of scope, the report should make that clear. If the protocol depends on another system, that dependency belongs in the threat model even if its source code is not being audited.

What teams should do before handing over the code

The quality of the engagement depends heavily on the state of the project before auditors arrive. Sending unfinished code with incomplete tests and changing requirements is not a shortcut. It is a way to spend audit budget on orientation instead of security analysis.

Before the review begins, the team should have:

1. A frozen scope. The auditor needs a stable commit and a clear list of included contracts, libraries, proxies, and integrations.

2. Architecture documentation. Explain how value moves, who can call privileged functions, how upgrades work, and which external systems the protocol trusts.

3. A threat model. List the assets at risk, attacker capabilities, privileged actors, oracle assumptions, and emergency procedures.

4. A meaningful test suite. Include unit tests, integration tests, failure cases, and invariant tests where possible. Auditors should not have to reverse-engineer intended behavior from implementation alone.

5. A deployment plan. Testnet addresses, chain configurations, compiler settings, proxy arrangements, and initialization steps can all affect the final risk picture.

6. A list of known limitations. If the team knows that a function depends on a trusted keeper or that a parameter is temporary, say so. Hidden assumptions tend to become expensive findings.

7. A change-control rule. Once the audit starts, new features should not quietly enter the reviewed commit. If they do, the scope and budget need to change with them.

That preparation is not bureaucracy. It gives the auditor more time to analyze the actual attack surface.

The dominant narrative: security has moved from badge to process

The crypto industry still likes the visual shorthand of an audit badge, a firm logo, and a launch announcement. The more serious teams now understand that the badge is the least interesting part.

The real signal is whether the project can explain what was reviewed, when it was reviewed, which findings were fixed, whether the fixes were verified, who controls upgrades, and what happens when the system behaves outside its normal assumptions.

The current vibe shift is from “we have an audit” to “we have a security process.” That process includes code review, economic analysis, permissions, operational controls, monitoring, and disciplined change management. It is less photogenic than a conference-stage launch and far more useful when the market gets noisy.

A smart contract security audit is best understood as a high-resolution risk review of a specific release. It can find reentrancy, access-control failures, oracle manipulation paths, arithmetic bugs, frontrunning exposure, and design flaws. It can force a team to articulate assumptions it had been carrying implicitly. It can prevent the kind of mistake that turns a promising launch into a post-mortem thread.

But the final responsibility remains with the protocol team. The audit is a serious checkpoint, not a force field. The teams that treat it that way are the ones most likely to survive the next exploit cycle—and keep building after the conference banners come down.