- The paper shows that carefully authored runtime invariants blocked all 28 tested real-world exploits, covering attacks associated with approximately $1.07 billion in losses.
- The authors introduce PonDeReplay, a replay-based method that compares original, recompiled, and hardened contract traces while preserving 98.3% of 108,637 historical transactions.
- Automated tools performed poorly against the benchmark: FLAMES matched only 2 of 28 security-critical invariants, while InvCon and InvCon+ matched none, highlighting major gaps in automated synthesis.
Overview
This paper by Bobadilla, Afrin, Novelli, and Monperrus (KTH Royal Institute of Technology) addresses a deceptively simple question with direct financial consequences: would a well-placed program invariant have stopped real smart contract exploits, and can automated tools discover such invariants? The authors answer affirmatively to the first question with a perfect 28/28 result, and negatively to the second, showing that state-of-the-art invariant generation tools recover only 2 of 28 attack-stopping invariants. The methodological contribution is a replay-based verification protocol that grounds every claim in on-chain evidence rather than synthetic benchmarks.
Background and Motivation
Smart contract exploits have caused over one billion dollars in on-chain losses. The paper's central premise is that the classical notion of program invariant—preconditions, postconditions, and object invariants expressed as runtime require checks—is the most effective available defense, because the blockchain's transactional semantics guarantee that a violated invariant reverts the transaction atomically before any state change commits.
Prior evaluations of invariant tools (InvCon, Trace2Inv, SmartInv, FLAMES) measured accuracy against synthetic properties, templates, or mined patterns; none confronted generated or human-written invariants with actual multi-million dollar loss incidents. This paper fills that gap.
Methodology
The study is built on DeFiHackLabs, restricted to its 359 Ethereum exploits (July 2017–June 2026). From these, the authors construct InvariantEval, a benchmark of 28 real exploits each paired with a human-authored attack-stopping invariant. Two authors independently wrote hardened contracts (original source plus an inserted invariant), time-boxed to eight hours per case, consulting post-mortems, victim source code, and proof-of-concept exploits; a third author resolved disagreements.
Validation is performed by PonDeReplay, a novel replay framework addressing a tooling gap: existing mechanisms (eth_call state overrides, cast run, Foundry vm.etch) each cover only part of the counterfactual question "what would this real transaction have done against hardened bytecode?" PonDeReplay forks mainnet at block N−1, injects candidate bytecode at the target address, replays co-located prior transactions in block N when needed, and compares three traces per transaction:
- O: the literal on-chain record;
- R: a recompiled replay of the unmodified contract (reproduction sanity check);
- H: the hardened contract replay.
Fidelity is assessed on three axes—transaction status, subcall outcomes, and storage diffs under an ϵ-threshold via prestateTracer. The reproduction check (R≡O) validates infrastructure; failure renders a transaction inconclusive rather than attributable to the invariant. The preservation check (H≡R) isolates the invariant as the sole differing variable, yielding clean causal attribution. Notably, transaction status alone is insufficient because Solidity swallows subcall reverts—a subtlety the design explicitly handles.
Results
Invariant effectiveness (RQ1)
All 28 ground-truth invariants block both the DeFiHackLabs proof-of-concept and the actual malicious on-chain transaction, reverting at the expected vulnerable step with the invariant's revert message. The incidents span losses from roughly $1K to ~$900M (BeautyChain's ERC-20 overflow), totaling $1.07B. A representative case study walks through BEC: the invariant require(_value <= uint256(-1) / cnt) prevents the overflow that let an attacker mint tokens via batchTransfer(2 receivers, 2^255).
The authors are candid that this perfect result is partly a consequence of the ground-truth protocol itself: they failed to write securing invariants for 25 additional attacks due to protocol-specific expertise limits and the time budget. The claim should therefore be read as "invariants we successfully authored all work," not as a statement about universal writability.
A unified eight-family taxonomy shows no single guard class dominates: price/oracle/slippage leads with 8 cases, ledger/supply/conservation has 6, access control and interaction safety (including three reentrancy locks) have 4 each, with business logic, arithmetic, input validation, and initialization covering the remainder.
Behavioral preservation (RQ2)
Replaying 108,637 pre-attack historical transactions through the hardened functions:
| Outcome |
Count |
Share |
| Preserved |
106,815 |
98.3% |
| Not preserved |
1,526 |
1.4% |
| Inconclusive |
296 |
0.3% |
Every divergence is causally attributed to the invariant. Manual analysis classifies the 1,526 non-preserved transactions into five behavioral reasons: past exploits (correctly reverted, e.g., APEMAGA), whitehat rescue operations (technically identical to attacks, e.g., Anyswap), misusage of accounting rules left open by the vulnerable code (e.g., Nimbus, where 449 ordinary swaps violate the constant-product rule), over-restrictive invariants (Yearn yDAI, where all 88 reverts hit a legitimate keeper bot excluded by an overly narrow governance check), and "tight numerical envelope" failures where numeric bounds such as price bands reject legitimate traffic during volatility (Inverse Finance, HoppyFrog). The latter two categories are genuine usability costs: honest users' transactions would fail under the hardened contracts, and the paper notes wider or volatility-aware bounds would be needed.
Replay limitations (RQ3)
Of the 296 inconclusive replays, 173 stem from original out-of-gas mismatches (PonDeReplay deliberately does not cap gas at the original limit, since exact gas accounting across forks is unreliable), 12 from subcall-level OOG divergence, and 111 from accumulated state drift caused by co-located same-block transactions behaving differently under recompiled bytecode—the high-traffic grok DEX router accounts for most of these. Critically, for 291 of 296 inconclusive transactions (98%), the hardened trace still matches the recompiled trace, confirming that inconclusiveness stems from replay infrastructure rather than the invariant.
Automated invariant generation (RQ4)
Against this validated ground truth, only three tools were executable end-to-end: InvCon, InvCon+, and FLAMES. FLAMES produced candidates for all 28 contracts but exactly matched the ground truth in only 2 cases (APEMAGA and Inverse Finance); InvCon and InvCon+ matched none, despite generating candidates for 13 and 24 contracts respectively. The paper concludes that current tools produce many plausible-looking candidates but almost never capture the security-critical property that blocks a real exploit—an important negative result, given that prior tool evaluations used only synthetic properties or held-out contracts.
Limitations and Open Questions
Several limitations are stated plainly in the paper. First, the 28-case benchmark covers only 28 of 359 Ethereum exploits; the authors could not author invariants for 25 attempted cases, so dataset coverage reflects author expertise and time constraints. Second, the 28/28 security result is partially circular: invariants were written knowing the attack and iterated until they blocked it, so effectiveness measures feasibility of hand-crafted guards, not a priori protective power. Third, historical replay cannot fully reproduce on-chain gas semantics, leaving 296 transactions inconclusive, and accumulated drift from co-located transactions bounds scalability of the approach to high-traffic contracts. Fourth, RQ4 compares tool output textually against ground truth rather than re-running the full replay protocol, because the tools do not emit sufficiently specific hardening instructions—a weaker form of evaluation. Fifth, inference-based tools by construction cannot protect newly deployed protocols lacking trace history. Finally, the over-restrictive-invariant and tight-numerical-envelope findings show that even correct security properties require calibration to preserve legitimate behavior; how to derive volatility-aware or role-aware bounds automatically remains open.
Conclusion
This paper establishes, with an unusually rigorous on-chain grounding, that a single correctly placed runtime invariant suffices to abort real exploits representing over a billion dollars in theft, while preserving behavior on 98.3% of historical transactions with full causal attribution of divergences. It simultaneously demonstrates that automated invariant synthesis is far from solving the problem, recovering only 2 of 28 attack-stopping properties. The combination of InvariantEval and PonDeReplay provides the field with a concrete, replay-validated yardstick: future invariant generation work should be evaluated not against templates but against whether it stops actual attacks without breaking legitimate usage.
