A formal verification engagement for a smart contract costs $75,000 to $200,000. You hire a firm that specializes in K Framework or Certora. You give them your contract code. They spend 2-4 weeks writing properties (formal specifications of what the contract should do) and running a constraint solver to prove that the contract either satisfies those properties or doesn't.
If the solver finds an input that violates a property, you have a bug. You fix it and they re-run the verification.
If the solver proves that all properties hold for all possible inputs, you have mathematical proof that the contract behaves correctly under those specifications.
This is powerful. But it's also expensive. And the decision of whether to do it requires honest analysis of what you're protecting and what you're risking.
Most smart contract projects skip formal verification. They do a traditional security audit, which is code review by humans looking for known vulnerabilities, and call it done. This costs $5,000 to $30,000. They save money and move faster. Most of the time, this is sufficient.
But some contracts are worth verifying. The question is which ones.
What Verification Actually Proves
Formal verification mathematically proves that a contract satisfies specific properties under the assumption that the Solidity compiler and the Ethereum Virtual Machine (EVM) are correct.
That's a loaded assumption. The Solidity compiler has bugs. The EVM has edge cases. But assuming those are correct, formal verification catches bugs that human auditors miss.
A typical property might be written as follows. "If a user calls transfer(to, amount), the user's balance decreases by exactly amount and the recipient's balance increases by exactly amount, and no balance is created or destroyed." This is an invariant. It should hold for all possible sequences of transfers.
A human auditor reading the contract code might miss a subtle bug where rounding errors in a Uniswap-style liquidity pool cause 1 wei of value to vanish per swap. The bug happens when you chain 100,000 swaps together. Formal verification would find it.
But formal verification doesn't prove that the contract does what the business wants. It proves that it does what the properties say it does. If you wrote a property wrong, the verification is worthless.
Example scenario involves building an escrow contract where you write the property "The contract always releases funds after the deadline." But you forgot to write the property "The contract rejects requests to release funds before the deadline from anyone except the authorized arbitrator."
The contract might have a bug where anyone can release funds early. Formal verification would pass because you didn't specify that it shouldn't happen.
This is the false sense of security problem. Formal verification gives you confidence, but only in the properties you chose to verify. If you omitted a critical property, you have a bug you don't know about.
The measurement is property coverage. How many security-critical invariants did you formalize? For a payment contract, you should verify at least the following
1. Balance conservation (no value is created or destroyed).
2. Authorization (only authorized callers can trigger sensitive functions).
3. State machine integrity (the contract only moves between valid states).
4. Reentrancy safety (recursive calls can't break invariants).
5. Boundary conditions (edge cases like zero amounts or maximum integers don't break the contract).
If you formalize all five, you have high confidence. If you formalize one or two, you have a false sense of security.
When To Formally Verify
The decision has three inputs including contract criticality, contract complexity, and bug cost.
Contract criticality means asking whether this contract holds funds. Is it on the critical path for payment settlement. Or is it a peripheral contract that just emits events?
Contract complexity means asking how many functions the contract has. How many state variables. Does it use external calls, loops, or conditional logic?
Bug cost means asking what's at risk if there's a bug. Is it a $1M annual savings contract or a $100M payment vault?
The decision matrix breaks down as follows
High criticality combined with high complexity and high bug cost requires verification. The cost of a bug ($100M loss) is much higher than the cost of verification ($150K).
High criticality combined with low complexity and high bug cost requires audit and fuzz testing. The contract is simple enough that human auditors can be confident.
Medium criticality with any complexity and medium bug cost requires audit plus targeted formal verification of specific properties. You don't need a full formal verification engagement, but you should formally verify the most critical properties including balance conservation and authorization.
Low criticality with any complexity and low bug cost requires audit and moving on. The downside of a bug is low enough that verification cost isn't justified.
In practice, a critical escrow holding $50M should be verified. A medium-criticality governance token needs audit plus targeted verification. A low-criticality rewards contract needs audit only.
Cost And Gaps
Total cost is usually $150K-$300K including audit, verification, rework, and integration. Audits catch known bug patterns; verification catches novel bugs by exhaustively checking all possible inputs and transaction sequences. For example, formal verification would find rounding errors that cause 1 wei to vanish per swap—something human auditors often miss.
For established patterns (ERC-20 tokens, standard escrow), audit is usually sufficient. For novel contracts (cross-chain payment routing, custom liquidity models), verification is worth the cost.
Verification is not perfect. Properties might be incomplete, the EVM or Solidity compiler might have bugs, integration with your application might be wrong, or operational security might be weak. Verification is a tool, not a guarantee. The best approach is verification plus continuous auditing and production monitoring.
For $100M annual volume, a 0.1% bug loss ($100K) doesn't justify $150K verification on pure ROI. For $10B annual volume, a 0.1% loss ($10M) justifies verification easily. There's also perception value. Customers and regulators trust formally verified contracts more, which can justify verification for market opportunities or reduced insurance premiums.
Most projects don't need verification. They need competent auditors and good discipline. Verification is for contracts that are novel enough that pattern-matching audits miss bugs, or valuable enough that cost is trivial relative to risk. For payment infrastructure, verify settlement and escrow contracts; audit everything else.