Smart contracts, chain runtimes, and the bridges and infrastructure around them. EVM chains and rollups, Cosmos SDK and CosmWasm, Solana programs, Substrate runtimes, Move-based chains.
We have reviewed a Polkadot runtime continuously since 2019: the state transition logic, the modules that compose it, the on-chain upgrade path, and the contracts running on top. Alongside it we have reviewed dozens of other chains and contract platforms: EVM and rollups, Cosmos, Solana, Move.
A chain that ships does not hold still for an audit. The code changes under you, the upgrade path is itself an attack surface, and the defects worth finding are often the ones that appear only once two subsystems have both moved. Reviewing a release in isolation cannot see those, however carefully it reads the diff.
The first part is the same every time. What follows depends on the system, and we agree it with you.
Always first: understand the system end to end
What the protocol does, and what it promises the people using it
Who gains from breaking it, and how much
What the team optimised for when they built it
Threat modellingLogic is only wrong against intent, and intent is usually not written down. So we write it down first.
Manual reviewReading the code against that intent. Scanners have no rule for a protocol they have not seen.
Dynamic analysisFuzzing, where a property can be stated precisely enough to attack it for weeks.
AI-assisted analysisBreadth across a codebase too large to read closely, with a person on everything it raises.
Threat modelling
Manual review
Dynamic analysis
AI-assisted analysis
A live chain runtime, reviewed across upgrades
A contract set before its first deployment
A large codebase inherited from someone else
Illustrative. The mix depends on the system and what is at risk, and we agree it with you.
The defects are specific to the protocol: arithmetic that wraps, state written before the check that guards it, an access decision taken somewhere it cannot be enforced, or an execution-metering mistake in gas, weights or compute units that lets an attacker buy execution cheaply. None of them has a signature a tool could carry, because the thing being violated is your design and nobody else has it.
A finding closes one bug. An invariant with a fuzzer behind it closes the class, and goes on closing it every time someone commits. CosmFuzz, our CosmWasm fuzzer, is public, and the write-up walks a campaign end to end against a token-accounting bug we planted in cw20-base to demonstrate it.
What we found
A month after the security alert, about 40% of the Parity Ethereum nodes in Ethernodes.org data were still unpatched. The flaw let any node be crashed remotely, which lowers the compute needed for a 51% attack. It spread slowly because the bug had not been marked critical on the project’s own update track, so clients running default settings never fetched it. How long a patch takes to land is part of the risk.
How
Node versions read from their announced headers in data from Ethernodes.org, acquired on 21 March 2019, a month after the security alert for the remotely triggerable integer overflow we disclosed to Parity that February. Ethernodes.org scans the network through the Ethereum discovery protocol and saw close to 11,000 nodes at that time.
Three shapes these engagements take. Scope is set with you, and most clients combine them.
Smart contract audit
We read the contracts against the invariants they are supposed to hold, then try to break them.
—The invariants agreed with you first, in writing
—Manual review of the contract logic and its state transitions
—Arithmetic, access control and ordering: the classes we keep finding
—Coverage-guided fuzzing against the invariants, harnesses left in your repository
Chain and runtime review
We review the chain itself: its state transition logic, the modules that compose it, and the upgrade path, not only what runs on top.
—Runtime modules and state transition logic, including the on-chain upgrade mechanism
—Consensus and networking surfaces reachable by another node
—What a malicious validator or a malformed message can do
—Whether a critical fix can actually reach the network in practice
Bridge and integration review
We test the parts that hold value while it is between two systems that trust each other.
—The trust assumptions on each side, stated explicitly
—Message verification, replay and ordering across the boundary
—The off-chain components: relayers, keys, and who holds them
—What happens when one side halts, forks or lies
Also available: exchange and custody platforms, where the chain is one component and the trading engine, the wallet management and the customer authentication around it are the rest — usually run with our software, cloud and red team practices rather than by this one alone. CosmFuzz and our other fuzzing harnesses are open source, so a team can start finding this class of bug before hiring anyone.
How we work
We start from the invariants: what must never be true of your contracts or your chain, written down before anyone reads code. CosmFuzz came out of exactly that: the demonstration in its write-up plants a token-accounting bug in cw20-base and catches it as a violation of one sentence written down in advance. The code is then read against them by hand, because the defects that cost money here are specific to your protocol, not generic bug classes a scanner knows. We build fuzzing harnesses that attack those invariants directly and hand them over, so the same class of bug fails a build before it ever reaches a chain. Nothing goes in the report until we can show it is reachable and what it lets an attacker take.
Tell us what you are building and what you need looked at. You will get an answer
from the people who would run the engagement, and if another firm is the better
fit for what you are asking, we will name one.