Smart Contract Security: Seven Layers Beyond One Audit

By the Guardian team Updated November 2026 5 min read

Quick answer. Secure a protocol in layers that catch what the others miss: design, tests, invariant fuzzing, formal verification, audits and bounties, deployment checks, and update review with monitoring. One audit covers one commit, not a system that keeps changing.

Watch: Smart Contract Security: Seven Layers Beyond One Audit 1:44

Video transcript

One audit covers one commit, not a system that keeps changing. Security takes layers that catch what the others miss.

Of the 20 largest DeFi hacks since January 2024, 13 had a published audit. Most of those lost funds through keys, infrastructure, or code the audit never covered.

Independent research agrees. In ack3's first half 2026 dataset, 46 of 68 incidents with a known audit history had attack paths outside every audit scope.

Cetus lost 223 million dollars in May 2025. Zellic, its auditor, said the library holding the bug was outside scope.

Before the audit, design catches unsafe trust and excess admin power. Tests check expected behavior. Invariant fuzzing catches accounting and solvency breaks. Formal verification proves properties for every input, but only those you specify.

Audits find logic and economic flaws in scope. Get the scope in writing, review the fixes, and add a bounty. At launch, match bytecode to the audited commit, then monitor every block.

Upgrades need review too. 27 of 48 Guardian update reports found at least one Critical or High.

Vanguard, Guardian's highest tier audit, puts two independent teams on one scope, one using Helix, our AI auditor. You keep the invariants. A Defender contest, a bug bounty, six months of update review and Managed Security follow.

Read the full guide for a checklist by stage, or talk to Guardian about Vanguard.

Smart contract security is the work of keeping a protocol's code, and everything that controls it, from losing users' funds.

Most teams treat it as one event: the audit. But an audit reviews a fixed scope at one commit, and losses tend to arrive through what sits outside it.

This guide is the map. It sets out seven layers, what each one catches, and the Resource Hub guide to read for each.

Why Audited Protocols Get Hacked

We checked the 20 largest DeFi protocol hacks from January 2024 to November 2, 2026 by hand. Of those, 13 had a published audit before the hack.

Six of those 13 lost funds through keys, signers and infrastructure. Three lost funds through code outside the audit or changed after it.

Independent research agrees. In ack3's H1 2026 dataset, 46 of 68 incidents with a known audit history had attack paths outside every identified audit scope.

Those 46 carried 94.4% of the subset's reported loss, or 72.1% without its two largest incidents.

Cetus shows the pattern. It lost $223M in May 2025, and Zellic told Rekt the library holding the bug "was not included in the scope of our audit."

So the question is not whether to audit, but what covers everything else. Our audited vs unaudited exploits analysis has the full table.

The Seven Layers

Each layer catches a different class of failure. None catches everything.

Layer	What it catches	What it misses	Go deeper
1. Secure design	Unsafe trust assumptions, excess admin power, needless complexity	Implementation bugs	Best practices
2. Tests	Broken expected behavior, and blind spots in the suite	States nobody thought to test	Mutation testing
3. Fuzzing and invariants	Accounting, rounding and solvency breaks across call sequences	Properties nobody wrote down	Layer 3 below
4. Formal verification	Proof that a stated property holds for every input	Wrong or missing specifications	Formal verification
5. Audits, contests and bounties	Logic, economic and integration flaws in scope	Code outside scope or changed later	How to audit
6. Deployment verification	Wrong bytecode, owners, parameters or peers	Bugs in the reviewed code	Pre-mainnet checklist
7. Update review and monitoring	Unreviewed changes, role changes, live attacks	Attacks faster than your response	Onchain monitoring

Before the Audit

1. Secure design

The costliest bugs are often design decisions: who can upgrade, which oracle is trusted, what one key can do.

Write the trust model down before the code. List every privileged role, every external dependency and every assumption about prices.

Keep the system small. Our Solidity security best practices start with writing less code and designing before you build.

2. Tests

Unit tests show the code does what you expect, on the inputs you chose.

Mutation testing checks the tests themselves. It plants small bugs in copies of the contract and shows which ones your suite misses.

3. Fuzzing and invariants

An invariant is a property that must always hold, such as a vault never owing more than it holds.

Foundry's invariant tests run random sequences of function calls and check the invariants after each call.

Write them for accounting, rounding and solvency. The suite then guards every later change.

Invariants do break. Guardian's public portfolio lists the invariants for 52 reports, and 186 of those 1,626 did not hold during the review.

4. Formal verification

Fuzzing samples states. Formal verification proves a property for every possible input.

Solidity's built-in SMTChecker tries to prove that assert conditions always hold, and checks for overflow and division by zero.

It proves only what you specify. As the Solidity docs put it, "You still need to check whether the specification is what you wanted."

Independent Review

5. Audits, contests and bounties

An audit puts experienced reviewers on a frozen commit to find logic, economic and integration flaws.

Get the scope in writing: which contracts, libraries and commit were reviewed, and what was left out.

Then review the fixes, because fixes are new code. In Guardian's Dolomite review, the fix review caught a newly introduced Critical.

Contests and bounties add reviewers after the audit. A bounty keeps paying for findings once the code is live.

For method, read how to audit a smart contract and our 22 vulnerabilities to check first.

Launch and After

6. Deployment verification

An audited contract can still be deployed wrong: the wrong bytecode, owner, parameter or peer.

Check the deployed bytecode against the audited commit. A Sourcify exact match means the bytecode and metadata match the published source.

Then check every owner, role, parameter and pause against a reviewed spec. Our pre-mainnet security checklist lists each one.

7. Update review and monitoring

Every upgrade ships into a system that already holds deposits.

Guardian's public portfolio has 48 reports titled as updates or upgrades, such as "Oracle Updates". 27 of them found at least one Critical or High.

Monitoring watches roles, upgrades, multisig queues and fund flows as each block lands.

Detection only helps if someone can act. Decide who can pause, and with which key, before an incident.

Our guide to onchain monitoring covers what to watch.

A Checklist by Stage

Design: write the trust model, every privileged role and every external dependency.
Build: unit tests, mutation tests, and invariants for accounting, rounding and solvency.
Prove: formally verify the few properties a loss would break.
Review: a written audit scope, a fix review, then a contest or bounty.
Launch: bytecode matched to the audited commit; owners and parameters checked.
Operate: review every change that touches value, and rerun the invariant suite.
Respond: monitoring live before deposits, and a pause someone has tested.

How Guardian Covers the Layers

Vanguard, Guardian's highest-tier audit, puts two independent teams on one scope.

Team A runs expert manual review and the fuzzing suite. Team B runs Helix, Guardian's AI auditor, and only human-verified findings reach the report.

Guardian writes the protocol's core safety properties as executable invariants. The suite stays with you as a regression harness.

A $100,000 Defender contest and a hosted bug bounty with $50,000 in Critical matching follow the audit.

For six months after production, Guardian reviews changes to the same scope, up to 2,500 smart contract SLOC.

After launch, Managed Security monitors contracts on every block and reviews every multisig transaction before it is signed.

Frequently Asked Questions

What is smart contract security?

The practice of keeping a protocol's contracts from losing or locking funds, across design, testing, review, deployment and operation. It covers the code and the keys, settings and upgrades that control it.

Is one smart contract audit enough?

Rarely. An audit covers a fixed scope at one commit. In ack3's H1 2026 dataset, 46 of 68 incidents with a known audit history had attack paths outside every identified audit scope.

What is the difference between fuzzing and formal verification?

Fuzzing runs large numbers of random inputs and call sequences against your invariants. Formal verification proves a property holds for every input. Both check only the properties you write down.

When does a protocol need another audit?

Whenever a change touches funds, permissions, pricing, liquidation, storage or upgrade logic, whatever its size. Fixes count too, because a fix is new code.

Sources

Cover every layer with one audit

Vanguard pairs two audit teams and an invariant suite with a contest, a bounty and six months of update review.

Talk to Guardian Explore Vanguard