Whitepaper · Formal methods
Onchain, a failure is permanent. Security has to mean knowing that specific properties hold under every reachable execution, and being able to show it. Formal methods are how every other mission-critical industry reached that standard, and by hand they were never fast or broad enough for how software ships. Deductive Interception automates them across the whole codebase, continuously.

Hacks happen on audited codebases. 88% of stolen funds came from audited codebases by the end of 2025. Testing has to shift left. The problem is the tooling.
AI is shallow pattern matching. High false positives, and it misses true positives and novel vulnerabilities, because it relies on heuristics that are black-box, non-deterministic, and only as good as the data it was trained on.
Fuzzing is random. It explores by sampling the input space, so its reach is bounded by what it happened to generate.
Static analysis encodes known vulnerability patterns into detectors. Its depth is bounded by the detector set, so cross-function and state-dependent issues fall outside its reach.
Teams need something that isn’t limited in scope, that runs on the entire codebase, continuously during development, without delays. Not a best guess. Mathematical, deterministic findings with proof.
Aerospace, chip design, core banking and regulated safety-critical software all reached the same answer, and in several of these fields regulators wrote it into the requirements.
The answer was determinism. When a failure can’t be recovered, you don’t estimate the probability of a fault and ship. You specify the properties that must hold and verify them exhaustively against every reachable state before the system goes live.
The method was proven. The cost of doing it by hand is what kept it out of reach. Manual formal verification is labor-intensive and demands scarce specialists, so teams scope it narrowly: one critical component verified in depth while the rest of the system goes unverified. A component can be verified in isolation and still sit inside a larger system with unverified parts.
Closing that gap means automating the methods underneath, not the manual practice.
Nothing off the shelf could do this. Automating formal methods for smart contracts meant building the engine from scratch: a custom intermediate representation that captures program semantics precisely, a deterministic symbolic execution engine, and machine-checkable proof artifacts. Not a wrapper around a general-purpose model or an open-source analyzer.
From formal methods we took what makes them authoritative: specify the properties that must hold, then verify exhaustively rather than sample. What we changed is what made the manual practice unscalable. Deductive Interception reduces seemingly infinite state space, derives the properties from the code and everything around it itself, and uses a combination of methods to find vulnerabilities where they must be.
An analogy in nature is the dragonfly. A dragonfly doesn’t pursue its prey. It reads the trajectory and moves to where the fly is going to be. The fly can go anywhere, but it can only be somewhere.
Product
Bounded Adversarial Verification (BAV).
Works from the signal inward: enumerates which paths are feasible, then runs the known attack strategies relevant to the system until one lands or the path is shown to be safe. Fully deterministic.
You get back a measurement as well as a finding: which reachable paths were adversarially tested, and which weren’t. An enforceable metric, not an estimate.

Product
Counterexample-Guided Invariant Refutation (CEGIR).
Builds from the system outward: infers the invariants, rules and security claims the code implicitly rests on but never states, then symbolically executes until one breaks. Deterministic + AI rather than pattern matching alone, so it finds unknown, novel and sophisticated attack vectors. AI proposes the invariants; the deterministic engine decides whether one actually breaks, by counterexample.
You get back an executable POC that reproduces the exploit, plus the trace, the exact state transitions, and the minimum conditions required to trigger it.

Building this engine from scratch also enabled us to rebuild the tools every smart team uses on a foundation purpose-built for blockchain: static analysis and mutation testing.
Two tests, both run by us, both published with their corpora so the arithmetic can be checked.
Against what auditors found
Fifteen EVM protocols that had already been through a professional security review, 188 high and medium severity findings between them. Olympix ran at the same commits, with no access to the reports and no human in the loop, and reproduced 128 of them.
Read the benchmark report →Against what auditors missed
Every EVM exploit of 2025 with a smart contract issue at its root cause: fifty incidents, roughly $240M in code-level losses. Assessed against the engine at the state of the code before each exploit, it surfaced the underlying vulnerability in 49 of the 50. Engine updates since cover the remaining one.
Read the 2025 exploit analysis →The first number is how much of an audit the engine reaches. The second is what it reaches that an audit didn’t.
Olympix spent its first two and a half years as a research lab. The engine was built, run and iterated against real codebases, real engineers and real deployed capital, with Circle among the teams informing it from day one.
The method was empirical throughout. Run the engine, observe which measurable patterns actually correlated with real vulnerabilities, formalize the ones that held, run it again. The signals weren’t designed. They were observed.
Four years of that loop compounded into proprietary empirical insight the engine rests on: which signals precede a real break, which abstractions hold under symbolic execution, which paths are worth traversing and which can be set aside. No model replicates that, regardless of scale or training data.

Contributed to security standards for


Members of


The whitepaper