What Smart Contract Auditing and Formal Verification Do

This article has three layers:

1. Layer 1: The Intuition: Physical exams, stress tests, and mathematical proofs
2. Layer 2: Real-World Use: Mainstream tools, why "audited" projects are still hacked, and how to read audit reports
3. Layer 3: Invariants, formal verification boundaries, and engineering details

Layer 1: The Intuition

1.1 Four Methods of Inspection

1.2 "What is correct" is the hardest part

All methods require answering one question: what properties should this contract satisfy? For example:

• "The sum of all user deposits must never exceed the actual tokens held by the contract";
• "Only the owner can call the upgrade function";
• "The amount of money any person withdraws cannot exceed their deposit plus earned interest."

Defining these properties clearly is often more valuable than finding bugs themselves.

Layer 2: Real-World Use

2.1 Mainstream Tools

2.2 Why "Audited" Projects are Still Hacked

2.3 How to Read an Audit Report

• Check the Scope: Which files and which commit hash were audited? Does it match the bytecode deployed on-chain?
• Check the Findings: How many High and Medium severity issues were found? Is the remediation status "Fixed", "Acknowledged but not fixed", or "Disputed"?
• Check the Auditor: Are they independent? Are there multiple audits for the same project? Is there a bug bounty program (see "Responsible Disclosure and Bug Bounties")?
• Check the Timing: How long ago was the audit? Has the code been upgraded since then?

Layer 3: Principles and Engineering

3.1 Invariant Testing

An invariant is a property that "must always hold true, regardless of how users call the contract or in what order they call it." A testing framework will randomly generate a large number of call sequences and check the invariant after every step:

// Invariant: actual tokens held by contract ≥ sum of all recorded user balances
function invariant_solvent() public {
    assertGe(token.balanceOf(address(vault)), vault.totalDeposits());
}

Good invariants come from an understanding of the business logic:

3.2 Formal Verification

The contract code and properties are translated into mathematical logic, and a solver is used to prove that "for all possible inputs and states, the property holds"; if it does not hold, the solver provides a specific counter-example.

It is stronger than testing because it is exhaustive: testing can only try a finite number of cases, while proof covers everything. However, it has clear boundaries:

• Only proves what you write: If you miss an important property, the proof will still "pass";
• Model assumptions: For example, assuming external contracts behave normally, whereas in the real world, an external contract might be written by an attacker;
• High cost: Requires specialized talent, and complex contracts may fail to prove (timeout).

3.3 A Recommended Workflow

1. Clearly write the specification: what the contract should and should not do, and what its invariants are;
2. Run continuous static analysis and unit tests during development;
3. Write invariant tests and run fuzzing for a long duration;
4. Perform formal verification on core logic (if conditions allow);
5. Multiple independent audits;
6. Post-deployment: Bug bounties, real-time monitoring, pause switches, and limits (see "Fail-closed").

Each step can only reduce risk, not eliminate it. "Defense in depth" means: problems missed by the earlier layers have a chance to be caught or their losses limited by the later layers.

Summary