DeFi Protocol Security Audit

The contracts you deploy are the core of the engagement. We work from a fixed commit hash so there is no moving target, review the full call graph, and trace how value enters and leaves each contract. Libraries you inherit from, such as OpenZeppelin, get a version and configuration check rather than a blind pass, because the vulnerable pattern is often in how a safe library was wired up.

Price feeds, keeper bots, relayers, and the front end that constructs transactions all shape what an attacker can do on-chain. A protocol that trusts a single spot price from one pool is exposed no matter how clean the contract reads. We map these dependencies and test the assumptions your contracts make about the data they receive.

We start by writing down what the protocol is supposed to do, invariant by invariant. Total supply should equal the sum of balances. A borrower should never withdraw more collateral than backs their debt. Fees should never exceed the configured cap. These invariants become the things we then try to break, and they become the properties we assert against in fuzzing.

Each contract gets read in full by an engineer who has audited comparable systems. We annotate every external call, every place arithmetic can overflow or truncate, and every function that changes ownership or permissions. Reentrancy gets special attention because the checks-effects-interactions pattern is easy to state and easy to violate in a helper three calls deep.

We fork mainnet with Foundry and drive the protocol against real token contracts, real oracles, and real liquidity, so an exploit we write actually executes on a realistic state. Property-based fuzzing with Echidna or Foundry’s invariant testing throws thousands of random sequences at the contracts to find the input ordering that breaks an invariant. Where the logic is subtle, symbolic execution and Mythril help enumerate paths a human might miss.

A finding is worth more when it comes with a working proof of concept. For a high-severity issue we write the exploit as a test that drains or freezes value on a forked chain, so your team can reproduce it in one command and confirm the fix closes it. No hand-waving about theoretical impact.

You get a report with every finding rated by severity, the code location, the exploit or reproduction steps, and a concrete fix. We then review your patches. The free retest confirms the fix works and, just as important, that it did not open a new hole somewhere adjacent.

Classic single-function reentrancy is well understood, yet cross-function and read-only reentrancy still catch teams out, especially in protocols that expose a view function other contracts price against. We check every path where control leaves your contract before state is settled.

Flash loans let an attacker borrow enormous size for the length of one transaction at zero capital risk. If any of your logic reads a price that a large trade can move, that price can be manipulated for free inside the same block. We test time-weighted feeds, Chainlink integrations, and any spot-price reads for exactly this.

Solidity 0.8 removed silent overflow, but rounding direction, precision loss in fixed-point math, and division-before-multiplication still leak value. In a high-frequency AMM or lending market, a one-wei error that rounds in the wrong direction becomes a real drain over millions of transactions.

Who can pause the protocol, who can upgrade it, who can move the treasury. We check that privileged functions are gated, that role changes are two-step where they should be, and that an initializer cannot be called twice or front-run on a fresh proxy.

Proxy patterns are powerful and dangerous. A storage-layout mistake between implementation versions can corrupt balances; an unprotected upgrade function is a total loss waiting to happen. We map your storage slots across versions and confirm the upgrade path cannot be hijacked.

Some attacks break no line of code and still cost users money. Sandwich attacks, just-in-time liquidity, governance vote-buying, and incentive loops that reward the wrong behavior are design problems. We model the game your protocol creates and tell you where the rational move is also the harmful one.

A short, honest read on the protocol’s security posture, the count of findings by severity, and whether we would be comfortable seeing it hold significant value on mainnet.

Every issue with a severity rating, the affected contract and line, a description of the attack, a proof of concept where the severity warrants it, and a specific remediation. We prioritize so your team fixes the flash-loan drain before the missing event emission.

After you remediate, we retest at no extra cost and issue a summary of what was fixed. Many teams publish the report; we write it knowing it may be public, so it is accurate and defensible.

A short spec of what each contract is meant to do, a description of the privileged roles and who holds their keys, and an explanation of the economic model save days. If the mechanism is novel, a whiteboard walkthrough with your engineers at the start is worth more than any document, because it lets us build the threat model against your actual intent rather than our guess at it.

If your protocol spans chains or depends on a bridge, that surface deserves its own attention. Message-passing bugs, replay across chains, and trust assumptions about a relayer or validator set have produced some of the largest losses on record. We scope this explicitly rather than folding it into a single-chain review, because the failure modes are different and the blast radius is larger.

A protocol can be flawless at the contract level and still be captured through governance. We look at proposal thresholds, timelocks, vote delegation, and whether a flash loan can borrow enough voting power to push a malicious proposal through in a single block. The admin keys get the same scrutiny: a multisig with a low threshold or keys on hot wallets is a design decision we will flag plainly.