Smart contract audit vs formal verification
Formal verification uses mathematical tools to prove that code satisfies specific properties for every possible input. An audit uses experienced reviewers to find vulnerabilities across the whole system, including ones nobody thought to write a property for. Formal verification is only as good as the properties you specify, so it complements an audit rather than replacing it.
Side by side
| Audit | Formal verification | |
|---|---|---|
| Method | Expert manual review supported by tools | Mathematical proof against a specification |
| Finds | Any class of flaw reviewers can identify | Violations of specified properties |
| Blind spot | Depends on reviewer skill and time | Properties nobody specified |
| Covers economics | Yes, by modelling attacker behaviour | Only if expressed as properties |
| Cost driver | Code complexity | Specification and proof effort |
Using both
The invariants you write down for an audit, such as “total shares never exceed total assets in value”, are the same properties formal verification proves. Writing them early helps both. For most projects, an audit plus fuzz and invariant testing is the practical baseline, with formal verification added for the most critical components.
Frequently asked questions
Is formally verified code guaranteed to be safe?
It is guaranteed to satisfy the properties that were proved, under the assumptions of the model. If an important property was never written, or the model differs from the real environment, bugs can remain.
Who should use formal verification?
Protocols with critical, stable, well-specified components, such as core accounting, AMM maths or bridges, where the cost of proving key invariants is justified by the value at risk.
Published Updated