What Is a Smart Contract Audit?

The Short Answer

A smart contract audit is an independent security review of a contract's code, design and assumptions before it goes live. Auditors read the code by hand, run static analysis, fuzzing and invariant tests, and deliver a report that ranks each finding by severity. An audit lowers risk but cannot prove a contract is safe, and it does not cover the keys, servers and admin processes around it.

That last point matters more in 2026 than most buyers realize. This guide explains what auditors check, where money is actually being lost this year, what the common bugs look like in code, how fuzzing and formal verification fit in, and how to prepare so the audit finds real problems instead of formatting issues. If you are earlier in the process, our guide to deciding whether you need blockchain at all comes first, and our blockchain development services page shows how audit sits inside delivery.

What the 2026 Hack Data Says About Where Money Is Lost

The headline numbers for the first half of 2026 depend on who counts. TRM Labs recorded 207 incidents and about $972 million in losses, the highest incident count it has ever logged. CertiK, which counts a broader set of Web3 security events including scams, put H1 losses at $1.32 billion and warned that the year-on-year drop is misleading because the prior year was dominated by the Bybit theft of roughly $1.4 to $1.5 billion.

The more useful finding is the split. Smart contract exploits were the most common attack type, 125 of the 207 incidents or about 60 percent, but TRM found they accounted for only about 17 percent of stolen value. CertiK found that infrastructure and operational compromises were about 15 percent of incidents and roughly 76 percent of losses. TRM's reading is similar: about three quarters of stolen value came from compromised keys, custody systems and signing infrastructure rather than bugs in contract code. CertiK attributed more than 70 percent of Q2 losses to two incidents, the KelpDAO and Drift Protocol hacks, which it links to North Korean state-sponsored actors.

Immunefi's 2026 report tells the other side of the story: its platform paid researchers about $13.45 million to report 837 valid bugs before attackers could use them. Pre-launch review and bug bounties work. They just do not address the largest losses by themselves.

The practical lesson is that a code audit is necessary and not sufficient. A contract that passes review can still be drained if one admin key is stolen. Budget for both: contract review, and a security design for keys, upgrades and monitoring.

What an Audit Covers and What It Leaves Out

A typical engagement reviews a fixed commit of the code, checks it against a written specification, and produces a report with findings graded critical, high, medium, low and informational. The team then fixes issues and the auditors verify the fixes in a re-review. The final report is tied to specific commit hashes, which is why you must freeze the code before the audit starts.

What it usually does not cover: your front end, your backend, your cloud accounts, your key ceremony, your multisig signers' laptops, the third-party contracts you call, or behavior after you change the code. Those are separate reviews. Ask every auditor for a written scope and a list of explicit exclusions, and read the exclusions first.

The Bugs Auditors Find Most, With Code

These are the patterns that show up repeatedly. The examples are simplified on purpose.

Reentrancy. The contract sends funds before it updates its own records, so a malicious recipient can call back in and withdraw again.

// Vulnerable: state is updated after the external call
function withdraw() external {
    uint256 amount = balances[msg.sender];
    require(amount > 0, "nothing to withdraw");
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "transfer failed");
    balances[msg.sender] = 0;
}

// Safer: checks-effects-interactions plus a reentrancy guard
function withdraw() external nonReentrant {
    uint256 amount = balances[msg.sender];
    require(amount > 0, "nothing to withdraw");
    balances[msg.sender] = 0;
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "transfer failed");
}

Access control gaps. A sensitive function has no restriction, or an upgradeable contract's initializer can be called by anyone.

// Vulnerable: anyone can redirect funds
function setTreasury(address newTreasury) external {
    treasury = newTreasury;
}

// Safer: restrict the caller and use a two-step ownership transfer
function setTreasury(address newTreasury) external onlyOwner {
    treasury = newTreasury;
}

Arithmetic and rounding errors. Since Solidity 0.8, arithmetic reverts on overflow by default, so classic overflow bugs now mostly appear inside unchecked blocks. The expensive modern version is precision loss: rounding that favors the wrong side in share or reward math. The well-known example is the ERC-4626 first-depositor inflation attack, where an attacker donates assets to a near-empty vault to skew the share price and steal from later depositors. Defenses include virtual shares and offsets, and minimum initial deposits.

Oracle and price manipulation. Reading a spot price from a single liquidity pool lets an attacker move that price inside one transaction. Use time-weighted prices or a decentralized oracle network, and check for staleness and bounds.

Front-running and ordering. Anything involving trades, auctions or mints can be exploited by someone who sees your pending transaction and jumps ahead. Slippage limits, commit-reveal schemes and private transaction relays reduce the exposure.

Upgradeability mistakes. Proxy storage layout collisions, uninitialized implementation contracts and over-powerful upgrade admins appear in a large share of reports. An upgrade key is a master key, so treat it that way.

Signature replay. Signed messages without a nonce, chain ID and contract address can be reused. Use EIP-712 typed data with nonces and expiry.

Denial of service. Unbounded loops over user-controlled arrays, or logic that depends on a transfer to a specific address succeeding, can lock a contract permanently. Gas problems also matter commercially, since a contract that is too expensive to call is a failed product.

How Auditors Actually Work

Good audits combine several methods because each one misses things the others catch.

• Manual review. Two or more reviewers read every line against the specification and a threat model. This is where logic errors and economic flaws are found.

• Static analysis. Tools such as Slither scan for known bad patterns quickly. They produce false positives and cannot judge business logic.

• Fuzzing and invariant testing. Foundry and Echidna throw large numbers of randomized call sequences at the contract and check that stated properties always hold.

• Symbolic execution. Tools such as Halmos explore execution paths mathematically for bounded cases.

• Formal verification. Tools such as the Certora Prover check a formal specification against all possible inputs, rather than a sample.

Here is what an invariant looks like in Foundry. The point is that you state a rule that must never break, and the fuzzer tries to break it.

contract VaultInvariantTest is Test {
    SafeVault vault;
    VaultHandler handler;

    function setUp() public {
        vault = new SafeVault();
        handler = new VaultHandler(vault);
        targetContract(address(handler));
    }

    // The vault must always hold at least what it owes depositors
    function invariant_solvency() public view {
        assertGe(address(vault).balance, handler.totalOwed());
    }
}

Writing invariants is the most valuable thing your own team can do before an audit. It forces you to define what "correct" means, and the auditors can then attack that definition.

When Formal Verification Is Worth It

A standard audit samples behavior: a smart reviewer and a good fuzzer will find most issues but cannot examine every possible state. Formal verification proves that specific properties hold for all inputs, so it fits contracts that hold large value or that many other contracts depend on, such as lending protocols, vaults, bridges and token standards. It costs more and needs well-written specifications, because a proof is only as good as the property it proves. For a simple token or a single-purpose escrow, a strong manual audit plus invariant testing is usually the right level. For anything holding significant funds, ask for formal verification of the core accounting rules.

Why the Auditor Should Not Be the Developer

The person who wrote the code is the worst-positioned person to find its flaws, because they read what they meant instead of what they wrote. This is the same reason code review is standard in ordinary software, with higher stakes here because deployed contracts are hard to patch and exploits happen publicly, often within hours. We keep audit as a separate review from development on every engagement. For high-value launches, add a second independent firm or a public audit contest, and then a bug bounty after launch.

How to Prepare So the Audit Finds Real Problems

• Freeze the code at a specific commit and stop merging features.

• Write a specification in plain language: what each function should do, who can call it, and what must never happen.

• Document your threat model, including trusted roles and external dependencies.

• Reach strong test coverage, including failure cases, before auditors start.

• Run static analysis yourself and fix the noise first, so reviewers spend their time on logic.

• List every external contract and oracle you depend on, and the assumptions you make about them.

• Plan time for fixes and a re-review. Fixes introduce new bugs.

On timing, our own delivery range for a single, well-defined smart contract use case is roughly four to eight weeks including the audit, and we will not shorten the audit to meet a launch date. Audit cost depends on code size, complexity and depth, so we scope it on a call rather than quote a range.

After the Audit: Keys, Upgrades and Monitoring

Given where 2026's biggest losses came from, this section is where many teams under-invest. Hold admin and treasury keys in multi-signature wallets, with signers on separate devices and separate networks. Use hardware security modules or MPC for high-value keys. Put a timelock on upgrades so users can see changes before they take effect. Add a pause mechanism with a narrow, well-protected trigger. Monitor on-chain activity for unusual withdrawals and set up an incident plan before launch, including who can pause, who talks to users and who contacts exchanges. Our cloud and DevOps practice builds the monitoring and infrastructure side that surrounds the contracts.

AI-Generated Solidity Needs More Review, Not Less

AI coding tools now draft contracts quickly, and they tend to produce code that looks right, compiles and passes the happy path. That is not the same as safe. Treat generated contract code as an untrusted draft, require tests that encode the invariants, and send it through the same independent audit. Our guide to whether vibe coding is safe for production covers the review tiers we recommend, and contract code that moves money belongs in the highest one. If you need senior Solidity reviewers or engineers added to your team, see our staff augmentation options.

Red Flags When Choosing an Audit Provider

• A fixed price and date quoted before anyone has seen the code.

• No named reviewers, or an automated scan sold as an audit.

• No explicit scope and exclusions in writing.

• A promise that the contract will be "fully secure" or "hack-proof."

• The same people who wrote the code reviewing it.

• No re-review step after fixes.

• Reports that are not tied to a commit hash.

Frequently Asked Questions

What does a smart contract audit check?

Auditors check for reentrancy, access control gaps, arithmetic and rounding errors, oracle manipulation, front-running exposure, upgradeability flaws, signature replay, denial-of-service conditions and logic errors in financial calculations, using manual review, static analysis, fuzzing and invariant testing.

How long does a smart contract audit take?

It depends on code size and complexity. For a single, well-defined use case, development including audit typically runs four to eight weeks in our experience, and you should leave time for fixes and a re-review.

Does an audit guarantee a contract is secure?

No. An audit reduces risk by finding issues in a fixed version of the code. It does not cover compromised keys, front-end attacks, third-party dependencies or code changed after the review.

Are smart contract bugs the main cause of crypto losses?

Not by value. In H1 2026, smart contract exploits made up about 60 percent of incidents but roughly 17 percent of stolen value, according to TRM Labs. Key and infrastructure compromises caused most of the dollar losses.

Do I need formal verification?

For contracts holding significant value or that other protocols depend on, it is increasingly the expected standard. For simple tokens or escrows, a strong manual audit with invariant testing is usually enough.

Should I run a bug bounty as well?

Yes, after launch. Bounties find issues that survive audits. Immunefi reported paying researchers about $13.45 million for 837 valid bugs in H1 2026.

Can the team that built my contract also audit it?

They should not. An independent review is the point. We run audit as a separate process from development on every engagement.

Next Step: Build the Audit Into the Plan From Day One

Akoode has offices in Gurugram, India and Jenks, Oklahoma, and serves clients in India, the UK and the USA. We hold a 4.9 rating on Google from 126 reviews and 5.0 out of 5 on GoodFirms, and have delivered 180+ projects across 15+ industries. If you are planning a contract or a Web3 product and want the security design done properly, book a call with Akhil Verma or read about our approach on the blockchain development company page. The next article to read is our guide to real-world asset tokenization, where audit and compliance design meet.