Formal Verification in 2026: The Audit That Proves Your Code

In the first half of 2026, crypto projects lost roughly $1.31 billion across 344 separate incidents, according to CertiK’s Hack3d report; a competing count from Immunefi put the damage at $972 million spread over a record 207 attacks. The totals are alarming, but they are not the part that keeps builders awake. The part that does is how many of the drained protocols were carrying a clean audit at the moment they were emptied. Balancer had been reviewed something like eleven times by four different firms, and an attacker still walked away with $128.64 million in under thirty minutes on 3 November 2025.

That distance between “audited” and “safe” is why one particular style of audit has moved from an academic footnote to the center of the security conversation: formal verification. Rather than checking a contract against a handful of scenarios a human thought to write, a formal-verification engagement tries to prove, with mathematics, that the code cannot break a stated rule for any input at all. This review looks at that category as a category: what proof-based auditing actually buys, where the flagship firm Certora and its rivals sit, how much it costs, who (if anyone) regulates it, and the uncomfortable lesson the Balancer hack handed the very people whose job is to verify code.

The short version, which the rest of this piece unpacks, is that formal verification is the most rigorous instrument on the auditor’s bench and it still did not save Balancer, because a proof only ever covers what you remember to specify. Learning to tell those two things apart, the proof and the specification behind it, is the difference between reading an audit and reading the sticker on the front of it.

What Formal Verification Actually Is

Most security testing is a sampling exercise. A unit test checks that the code returns the right answer for the inputs a developer chose. A fuzzer such as Echidna, Medusa, or Foundry’s built-in engine is far more aggressive, mutating thousands of inputs to try to break an invariant the developer wrote down, but it is still sampling: it explores a large slice of the input space, not all of it. Formal verification is a different kind of claim. It aims to prove that a property holds across every possible execution, full stop.

Certora, the firm that has done the most to commercialize the approach, frames the distinction bluntly on its own site. Formal verification, it says, “produces a mathematical proof that the program behaves according to specification across all executions,” whereas testing and fuzzing “can only sometimes detect bugs based on predefined properties.” The payoff, in Certora’s words, is “complete path coverage for any given specification.”

Everything rides on the last four words: for any given specification. Formal verification does not discover what “correct” means; it demands that you state it, precisely, as a rule a machine can check. That moves the hard part of security from hunting for bugs to writing down, without ambiguity, the properties the system must never violate. The specification, not the proof, is the real deliverable, and it is also the place where the whole method can quietly fail. A proof of the wrong property is not a safety net; it is a false floor.

The intuition is a load test versus a guarantee. Testing asks whether a bridge held when three trucks drove across it. Formal verification asks whether any load within the stated limits could ever bring it down, and answers either with a proof that none can or with a concrete counterexample: this exact truck, at this exact spot, collapses it.

Why Testing and Fuzzing Leave a Gap

To see why the industry keeps paying for proofs, look at the shape of the bug that keeps draining automated market makers and lending pools. It is almost never a dramatic logic error a reviewer would spot on the first read. It is a rounding direction that is off by a few wei per operation, invisible and harmless in isolation, and devastating when an attacker chains dozens of tiny operations into a single transaction so the errors compound.

The Balancer exploit is the canonical example. Check Point’s post-mortem traced the drain to arithmetic precision loss in the pool’s upscaling function: individual rounding errors of eight or nine wei, negligible on their own, were accumulated across more than sixty micro-swaps inside one atomic transaction until the pool’s invariant could be manipulated wholesale. No hand-written test suite contains that exact sequence, because no developer imagines it. A fuzzer might stumble onto it given enough time and the right invariant, or it might run for a week and never try that precise ordering.

This is the gap formal verification is built to close. The same precision math that decides how an automated market maker prices your trade is where these errors live, which is exactly why AMMs, stableswap curves, and collateralized lending markets are the natural habitat of proof-based auditing. If you can state the rounding rule as a formal invariant, a verifier will check it against every ordering of every swap at once, not just the orderings someone thought to test.

Certora, the Flagship of Proof-Based Auditing

Certora was founded in November 2018 in Tel Aviv by Mooly Sagiv and Shelly Grossman, two researchers whose careers sit at the intersection of academic formal methods and shipped security software. Sagiv is a widely cited formal-verification researcher and an ACM fellow; Grossman spent five years at Check Point before helping turn the group’s academic work into a product. The company’s own telling is that its technology grew out of roughly two decades of research into formal verification and programming languages, which is an unusually long runway for a crypto-era startup.

The money followed the pedigree. In May 2022, Certora raised a $36 million Series B led by Jump Crypto, with Tiger Global, Galaxy Digital, Coinbase, Framework Ventures, and Electric Capital among the participants. The round was pitched as a way to port the firm’s flaw-detection engine to more chains, and it broadly worked: by 2026 Certora advertises coverage of Ethereum and the wider EVM, Solana, and Stellar.

There was also a leadership change worth noting, because it says something about where the field is heading. After seven years as chief executive, Sagiv handed the CEO role in July 2025 to Seth Hallem, co-founder of Coverity, the static-analysis company that became a fixture of enterprise software security. Sagiv moved to lead strategic research, and Grossman remains co-founder and chief technology officer, focused on product and R&D. Hiring the Coverity founder to run a formal-verification firm is a neat signal: the person now steering Certora built a career on finding bugs by pattern, and has chosen to bet the next one on proving they cannot exist.

By its own numbers, the reach is large. When Certora open-sourced its Prover on 24 February 2025, publishing it under a public repository, it said the tool had secured more than $100 billion in total value and that developers had written over 70,000 verification rules against it, across clients that include Aave, MakerDAO, Uniswap, Lido, EigenLayer, Morpho, Safe, and, yes, Balancer.

Inside the Certora Prover: CVL, Solvers, and Counterexamples

Under the hood, a Certora engagement looks less like a checklist and more like writing a second, mathematical description of the contract. Engineers author rules in CVL, the Certora Verification Language, which reads a lot like Solidity. A rule might say, in effect, that the sum of every user’s balance must always equal the recorded total supply, or that no sequence of swaps can leave a pool holding less than it owes.

The Prover then compiles the contract and the rule together into a set of logical constraints and hands them to automated theorem provers, the SMT solvers Z3 (from Microsoft Research) and CVC5. The solver does one of two things. It either proves that no input anywhere can violate the rule, or it returns a counterexample: a concrete, replayable sequence of calls that breaks the property, which developers can drop straight into a test to reproduce.

The honest limitation lives here too. Some properties are undecidable, or the search space explodes past what a solver can finish, and the Prover returns an indeterminate result: neither proved nor disproved. A trustworthy formal-verification report is scrupulous about that distinction, listing which rules were proved, which failed, and which came back indeterminate. A weak one blurs the three into a single reassuring word. If you take nothing else from this review, take the habit of asking which of the three you are actually being sold.

The Wins: The Bugs Proofs Caught

Formal verification is not a theoretical promise; it has a track record of catching bugs that survived every other layer. Certora’s most cited catch is in MakerDAO, the protocol behind the DAI stablecoin. Its verification surfaced a violation in one of the core accounting invariants underpinning DAI, an issue the firm says had gone unnoticed by conventional review and that put roughly $10 billion at risk had it ever been triggered. This is exactly the kind of deep, systemic arithmetic property that human reviewers and fuzzers tend to miss, because it only breaks under a combination of conditions nobody thinks to assemble.

There are others. Certora lists a pool-draining bug it found in SushiSwap’s Trident, a flaw that could have been used to empty the protocol, and, tellingly, an insolvency bug in Balancer V2 that its formal verification caught before it could be exploited. Hold that last one in mind, because it is the setup for the most instructive story in this whole category.

The pattern across the wins is consistent. Proofs earn their fee on invariants that are systemic rather than local: solvency, conservation of value, the impossibility of minting something from nothing. These are the properties where a single missed edge case is worth eight or nine figures, and where the difference between “we tested a lot of cases” and “we proved it holds for all of them” is the difference between a suppressed exploit and a headline.

Balancer, the Case That Proves the Thesis

On 3 November 2025, an attacker drained $128.64 million from Balancer across six blockchains in under thirty minutes. Check Point’s analysis pinned the mechanism on the upscaling function inside Balancer’s ComposableStablePool contracts, where integer division produced rounding errors of a few wei at the eight-to-nine-wei threshold. The attacker weaponized batched swap sequences that accumulated those tiny errors until the pool’s invariant could be manipulated. Certora’s own breakdown identified the root cause more simply still: the code rounded down where it should have rounded up, slightly understating the required payment on each swap.

Here is the uncomfortable part for the formal-verification thesis: Certora had verified Balancer. And in its post-mortem, the firm was strikingly candid about what that verification did and did not do. “While the verified properties guaranteed solvency at a high level,” it wrote, “they were not strong enough to detect the rounding error.” It went further: “the verified properties did not constrain the relationship between individual swaps or rounding behavior.” The solvency proof was genuine. It simply did not include the property the attacker exploited, because nobody specified it.

The wider audit history makes the point sting. As the developer-relations lead at TAC Blockchain, Suhail Kakar, put it after the hack, “Balancer went through 10+ audits,” and the vault at the center of it had been audited three separate times by different firms and still got drained. “This space needs to accept that ‘audited by X’ means almost nothing,” he said. “Code is hard, DeFi is harder.” Balancer V2 had in fact been audited eleven times by four firms, OpenZeppelin, Trail of Bits, Certora, and ABDK, and none of the eleven prevented the loss.

The counterweight is what Certora did in V3, and it is a genuinely reassuring demonstration of the method working when the specification is right. In V3, Certora says, every pool operation runs at 18-decimal precision, composable pools are replaced by ERC4626 buffers, and a new rule, swappingBackAndForth, formally proves that going from token A to B and back to A can never yield a gain. Certora verified that the underlying issue behind the V2 bug does not appear in V3, and V3 was untouched during the hack. The lesson is not that formal verification failed. It is that formal verification did precisely what it promised, proving the properties it was given, and the loss lived in a property no one had written down. Read the specification, not the badge.

The Limits Formal Verification Admits

To its credit, Certora is unusually willing to publish the boundaries of its own product. Alongside the wins, the firm states plainly that “if the specification does not cover some property,” a proof “cannot provide any guarantees that the system will not have bugs due to violation of that property.” It lists the other limits just as candidly: an inaccurate specification means the results cannot be trusted; external dependencies such as price feeds and third-party libraries sit outside the proof; and the verification tool itself can contain bugs.

Put simply, formal verification is garbage-in, garbage-out with unusually high stakes, because a proof of the wrong property does not just fail to help, it manufactures confidence. That is a more dangerous failure than an honest gap, and it is why the specification deserves at least as much scrutiny as the code.

There is also a category of risk that proofs structurally cannot touch. Economic and game-theoretic design flaws, oracle manipulation, maximal extractable value, private-key compromise, and infrastructure or bridge misconfiguration are not properties of the contract logic; they are properties of the world the contract lives in. Alexander Urbelis, chief information security officer at ENS Labs, framed the limit well: “The bugs that drain treasuries often turn on intent and adversarial incentives.” A proof can confirm that the code matches the specification. It cannot decide whether the specification matches what a rational, well-funded attacker will actually do. A proof says nothing, for instance, about a governance vote engineered to capture a timelock, because in that case the contract behaves exactly as written; the attack is in the intent, not the code.

What Proofs Can’t Catch: The 2026 Loss Map

The 2026 loss data makes the boundary concrete. CertiK’s Hack3d figures for the first half of the year show that code vulnerabilities were the most common category by a wide margin, 204 of 344 incidents, and also the cheapest, at about $152 million. The costliest category was wallet and private-key compromise: $444 million across just 33 incidents, an average north of $13 million each. Phishing sat in between, at $366 million over 63 incidents, as attackers traded broad campaigns for precise social engineering. The two single biggest events of the half, the Kelp DAO RPC compromise ($291 million) and the Drift Protocol breach ($285 million), both in April, were operational and infrastructure failures rather than contract bugs, and together they accounted for close to 44% of all first-half losses.

Read against the method, that table is humbling. Formal verification aims squarely at the vector that happens most often and costs the least. The real money is leaving through compromised keys, poisoned RPC endpoints, and social engineering, none of which a proof about contract logic so much as touches. That is not an argument against formal verification; it is an argument against believing it is a whole security program. The costliest failures now begin with a stolen key, which is why cold-storage hardware after the Coldcard hack remains a last line of defense that no audit, however rigorous, can substitute for.

The Formal-Verification Firms, Reviewed

Certora is the flagship, but it is not the whole field, and a serious buyer should know the alternatives. Runtime Verification, co-founded by the computer scientist Grigore Rosu, builds on the K framework and KEVM, a complete formal semantics of the Ethereum Virtual Machine, and ships Kontrol, which lets teams prove properties starting from the Foundry tests they already have. Veridise specializes in the corner of the market that scares everyone else, zero-knowledge circuits, where “underconstrained” bugs let a prover cheat; its Picus tool is built to detect exactly that class. Halmos, from a16z’s crypto team, is symbolic testing rather than full verification: it reuses existing Foundry test functions as specifications and explores them exhaustively up to a bounded loop depth, which makes it a free, low-friction on-ramp for teams not ready to write CVL. The Solidity compiler itself ships SMTChecker for simple properties at no cost, and ChainSecurity, an ETH Zurich spinout now inside PwC Switzerland, blends automated analysis with manual review.

The practical read of the landscape is that these tools are not substitutes so much as rungs on a ladder. Full verification from Certora or Runtime Verification is heavy, slow, and expensive, and it is the right call for the core invariants of a protocol that will custody billions. Bounded symbolic tools like Halmos and SMTChecker are cheap and partial, and they belong in continuous integration where they can catch regressions on every commit. Zero-knowledge teams need a specialist, and Veridise is the name most often on that shortlist. The protocols getting security right in 2026 are not choosing one of these; they are stacking formal verification on top of a manual audit and a fuzzing campaign, and treating each as coverage for the others’ blind spots.

When the Code Is Written by AI

The freshest pressure on this entire category is that a growing share of smart-contract code is now drafted by AI, and language-model Solidity has a specific failure mode: it is frequently syntactically clean and semantically wrong, which is the worst possible combination for a reviewer skimming for obvious errors. A contract that compiles and reads plausibly can still be quietly broken in a way that only surfaces under adversarial input.

Certora’s answer, launched on 21 November 2025, is Certora AI Composer, which the firm bills as the first safe AI coding platform for smart contracts. Instead of bolting a review onto the end, it embeds the Prover inside the code-generation loop, so AI-generated code is checked against mathematical safety rules before it ever ships. “Certora AI Composer proves that AI and formal verification can work together to make smart contract development trustworthy by default,” said founder Mooly Sagiv when the tool launched. The pitch is that a proof is one of the few artifacts capable of checking an AI’s output without another human in the loop, which is precisely what you want when AI is generating code faster than humans can read it.

The skeptics are not wrong to push back on the hype, though. David Schwed, chief operating officer at SVRN, put the counterpoint memorably: “‘Claude, audit my smart contract, make no mistakes’ is not a security program.” His point is not that AI cannot help; it is that AI output still needs someone able to evaluate what comes back, and formal verification only helps if the person writing the rules understands the system well enough to specify it correctly. It is the same trust problem that shadows inference you run on a GPU you do not own: output you cannot independently verify is output you are taking on faith, and faith is not a control.

What It Costs, and Who Pays

Formal verification is a premium layer, and the price is the main reason it is not universal. A manual audit from a top-tier firm already runs well into the six figures for a serious protocol, and formal verification typically sits on top of that as an add-on that can raise the engagement by tens of thousands of dollars, depending on how many properties need to be specified and proved. That is a rounding error for Aave or Lido and a non-starter for a two-person team shipping a weekend project, which is a large part of why the most-verified protocols are also the largest.

The industry has noticed the gap and started subsidizing it. On 14 April 2026, the Ethereum Foundation launched a $1 million audit subsidy program, routed through the Areta marketplace, that covers up to 30% of audit costs across more than twenty vetted firms including Certora, as part of its broader Trillion Dollar Security Initiative. The program will not put a formal-verification budget in every builder’s hands, but it lowers the floor for teams that would otherwise ship unaudited.

Open-sourcing the Prover in February 2025 was the other lever Certora pulled. In principle, any team can now run the verification engine themselves without a commercial contract. In practice, the bottleneck was never the solver; it is the specialist skill of writing correct CVL rules, and that skill remains scarce and expensive whether the tool is free or not.

Who Regulates the Auditors? Almost No One

For all the money riding on these reviews, there is no regulator standing behind them. There is no PCAOB for Solidity, no licensing board that certifies a smart-contract auditor, and no rule anywhere in the United States that requires a code review before a contract goes live. An audit firm can miss a $128 million bug and keep every client on its roster, because the only sanction is reputational, and reputation, in practice, is a forgiving court.

Nothing in the current regulatory agenda changes that. The Securities and Exchange Commission under Chair Paul Atkins has spent 2025 and 2026 on the question of when a token is a security and how a “Regulation Crypto” framework might be built, the substance of its “Project Crypto” agenda, not on how contracts are audited or what a verification report must contain. The result is that audit quality is policed entirely by market reputation, which sits outside the compliance perimeter regulators are still drawing around DeFi: that perimeter reaches intermediaries, disclosures, and registration, not the mathematical correctness of the code itself.

How to Read a Formal-Verification Report

Because no regulator will do it for you, reading the report is on you, and there is one habit that matters more than all the others: ask what was specified, not whether it “passed.” A green checkmark next to the word “verified” is close to meaningless without the list of rules that were actually proved. The Balancer post-mortem is the whole argument in one case study: the solvency property was proved and the rounding relationship was not, and only the list of rules would have told you which was which.

From there, a few concrete checks separate a strong report from a reassuring one. Distinguish proved results from indeterminate ones, and be suspicious of an all-green summary with no caveats, because real verification hits undecidable paths. Scope every claim to a specific commit hash, since the Balancer lesson is that code added after the review is code nobody verified. Look specifically for rounding and precision invariants written as formal claims rather than left as comments in the source. And treat any report that claims to cover “everything” as a red flag, because honest formal verification is precise about what it did not cover.

The Verdict: Necessary, Never Sufficient

Formal verification is the strongest audit money can buy for the properties you can name, and it is worth nothing for the ones you cannot. Both halves of that sentence are true at once, and the Balancer story is the proof: the same method that caught a $10 billion invariant in MakerDAO and an insolvency bug in Balancer V2 also verified Balancer and missed the rounding relationship that drained $128 million. Neither fact cancels the other. Together they are the entire case.

The mature posture in 2026 is to stop asking which single layer is the answer and start stacking them: formal verification for the core invariants, a manual audit for design and context, fuzzing for breadth, a bug bounty for the long tail, and continuous monitoring for everything that happens after deployment. No one layer is sufficient, and the marketing that implies otherwise is precisely the thing to distrust. The auditors who verify code for a living learned that lesson the hard way in November 2025. The rest of the market can learn it by reading the specification instead of the badge.

Frequently Asked Questions

What is formal verification in smart contract auditing?

Formal verification is a method that uses mathematical proof to show a smart contract cannot violate a stated rule under any possible input, rather than testing it against selected scenarios. A firm like Certora writes formal properties (for example, that total supply always equals the sum of balances), then a prover either proves the property holds across all executions or returns a concrete counterexample. Its strength is complete coverage of a given specification; its weakness is that it only covers properties someone thought to specify.

Is formal verification better than a regular audit?

It is more rigorous for the specific properties it checks, but it is not a replacement for a manual audit. A human audit is better at catching design flaws, economic attacks, and context that no one has formalized, while formal verification is better at proving deep arithmetic and accounting invariants hold in every case. Serious protocols in 2026 use both, plus fuzzing and a bug bounty, because each layer covers the others’ blind spots.

Why did Balancer get hacked if it was formally verified?

Because the proof covered solvency, not the specific rounding behavior the attacker exploited. Certora verified that Balancer V2 stayed solvent at a high level, but, in its own words, the verified properties “were not strong enough to detect the rounding error” and “did not constrain the relationship between individual swaps.” The $128.64 million loss on 3 November 2025 lived in a property no one specified, which is the central limitation of formal verification: it proves only what you write down.

How much does formal verification cost?

It is usually a premium layer on top of a manual audit. A top-tier manual audit already costs well into the six figures for a substantial protocol, and formal verification is typically an add-on that can raise the bill by tens of thousands of dollars depending on how many properties must be specified and proved. To lower the barrier, the Ethereum Foundation launched a $1 million subsidy in April 2026 that covers up to 30% of audit costs across more than twenty firms, including Certora.

Which firms do formal verification for crypto?

Certora is the market leader, with its Prover, the CVL language, and clients including Aave, Uniswap, and Lido. Other notable names are Runtime Verification (the K framework and the Kontrol tool), Veridise (a zero-knowledge specialist behind the Picus tool), and Halmos from a16z (bounded symbolic testing that reuses Foundry tests). The Solidity compiler also ships a free, lightweight verifier called SMTChecker for simple properties.

Nathan Reeves covers security and exploits for HOGE Wire.