Invariant Testing & Fuzzing Services
We write the invariant tests that catch the bugs your manual audit missed — then hand you a test suite you can run forever.
What Is Invariant Testing?
Invariant testing (also called property-based testing or fuzzing) defines properties that must always hold true in your smart contract — like "total assets must equal sum of all deposits minus withdrawals" or "no user can withdraw more than they deposited." A fuzzer then generates millions of random transaction sequences trying to break these properties. If it finds a violation, you have a concrete exploit path to fix.
Recon vs Other Approaches
Here's how Recon's invariant testing compares to alternative security approaches.
| Approach | Bug Classes Found | Ongoing Value | Setup Time | Maintenance |
|---|---|---|---|---|
| Recon Invariant Testing | Logic, economic, state machine, arithmetic | Reusable test suite + CI integration | 1-3 weeks | Low — extend as you ship |
| Manual Audit Only | Depends on reviewer expertise | Point-in-time report | 2-4 weeks | Re-audit for changes |
| Static Analysis | Known patterns only | Fast but shallow | Minutes | High false-positive rate |
| Formal Verification | Mathematically proven properties | Breaks when code changes | Months | Very high — re-prove everything |
How It Works
- We analyze your codebase and define the critical invariants with your team. 2. We scaffold the test suite using the Recon framework — Echidna, Medusa, Halmos, or Foundry depending on your needs. 3. We apply coverage-guided fuzzing to maximize branch and path coverage, combined with symbolic execution via Halmos for mathematical guarantees on arithmetic properties. 4. We run the suite in the cloud using Recon Pro, iterating until we reach full coverage. 5. We deliver the test suite with documentation so your team can maintain and extend it. 6. You run it in CI on every commit, catching regressions before they ship.
Cloud-Powered with Recon Pro
Recon Pro lets you run invariant tests in the cloud with no infrastructure management. Queue runs, view results, share with your team — all from the browser. During engagements, unlimited cloud runs are included so we can iterate rapidly.
Frequently Asked Questions
What is invariant testing for smart contracts?
Invariant testing defines properties (invariants) that must always be true in your contract, then uses a fuzzer to generate millions of random transaction sequences trying to violate them. It's a form of property-based testing and the most effective way to find logic bugs, economic exploits, and edge cases that manual review misses.
How long does an invariant testing engagement take?
Typically 1-3 weeks for a focused scope. Complex protocols may take longer. The deliverable is a full test suite you own — not just a report.
What fuzzing tools do you use?
We use Echidna, Medusa, Halmos, and Foundry fuzz testing depending on the project's needs. Our Recon framework scaffolds test suites across all of these tools from a single property definition.
Can I run the invariant tests after the engagement ends?
Yes. You own the test suite. Run it locally, in CI, or in the cloud with Recon Pro. Extend it as you add features.
How does invariant testing compare to unit testing?
Unit tests verify specific scenarios you think of. Invariant tests verify properties across millions of random scenarios the fuzzer generates — including ones you'd never think to write. They're complementary: unit tests for known cases, invariant tests for unknown unknowns.
How do I write my first invariant test?
Start by identifying a property that should always hold — like 'total shares times price per share equals total assets.' Then scaffold a test harness using Chimera, define the property as a boolean function, and run it with a fuzzer. Our step-by-step tutorial walks you through writing three properties for a Solidity vault in under 30 minutes.
Get Invariant Testing for Your Protocol
Talk to our fuzzing engineers about building a test suite for your codebase.
Related Services
Smart Contract Security Audit Services
Thorough manual review combined with invariant testing — the most rigorous approach to smart contract security available today.
DeFi Protocol Security Audit
DeFi-native security researchers who understand composability risks, economic attacks, and protocol-specific vulnerability patterns.
Solidity Audit — Smart Contract Security for Every EVM Chain
Deep Solidity audit expertise combined with automated invariant testing — covering every EVM chain from Ethereum to L2s.
Smart Contract Fuzzing Services
Cloud-powered fuzzing infrastructure that runs Echidna, Medusa, Halmos, and Foundry — 12,500+ campaigns and counting.
Related Articles
Mutation testing for smart contracts: measure your test suite quality
Your tests pass. But are they actually good? Mutation testing injects faults into your code and checks if your tests catch them. Here's how to measure and improve.
14 minPostmortem: The Lending Protocol Reentrancy That Fuzzing Missed — And Invariants Didn't
The dev team ran Echidna for 24 hours: zero findings. The same vulnerability was found by invariant testing in 90 seconds. Here's the exact reentrancy path, why mock ERC20s hide it, and the accounting properties that catch it.
14 min5 Properties Every Smart Contract Auditor Forgets to Test
After 40+ DeFi audits, the same five invariant gaps come up every time. Not the obvious ones — accountants check totalSupply. The ones that require stateful sequences, adversarial tokens, and cross-function composition.
13 minRelated Topics
Invariant Testing
Invariant testing is a smart contract testing methodology that verifies properties (invariants) that must always hold true, regardless of the sequence of transactions or state changes applied to the system.
Property-Based Testing
Property-based testing is a software testing methodology where developers define general properties that should always hold, and a test generator automatically creates inputs to verify those properties.
Mutation Testing
Mutation testing evaluates test suite quality by introducing small code changes (mutations) and checking whether existing tests detect them.