DeFi Smart Contract Audit

A DeFi smart contract audit reviews both contract logic and protocol economics. We test solvency assumptions, share-price integrity, oracle dependencies, MEV exposure, and composability risks with the broader DeFi stack. The output is a written report with reproducible findings, but the threat model goes beyond code-level bugs to include failures in mechanism design.

Request a scoping call

What we cover.

DeFi engagements review the same surface as a smart contract audit, plus the financial mechanism the contracts implement. Typical scope:

  • 01

    Solvency invariants. Total assets greater than or equal to total liabilities under all paths, including liquidation, redemption, and emergency exit.

  • 02

    Share-price manipulation. First-depositor attacks on ERC-4626 vaults, donation attacks, view-function manipulation by sandwich.

  • 03

    Oracle dependencies. Feed selection, staleness, deviation, fallbacks, and worst-case behaviour when an oracle is offline or compromised.

  • 04

    Liquidation correctness. Bad-debt handling, partial liquidation, dust positions, MEV exposure during liquidation cascades.

  • 05

    Liquidity migration and emergency procedures. Pause, freeze, withdrawal, and migration paths under adversarial conditions.

  • 06

    Composability with upstream protocols. What happens to your protocol when Aave changes a risk parameter, when Compound V3 adds a new asset, when Uniswap V4 ships?

  • 07

    MEV exposure. User-facing and protocol-internal value leakage. Sequencer-level exposure on L2s.

Our approach.

DeFi smart contract audits run longer than generic contract reviews because the threat model is broader. We start with a mechanism review before reading any code: we model the protocol on a whiteboard, identify the invariants, and decide what would constitute an exploit. Only then do we open the source.

For mature DeFi protocols, the most valuable findings are usually not in the new code — they are in the interaction between the new code and existing markets. We write integration-level proof-of-concepts using mainnet forks where the impact requires real composability to demonstrate.

Oracle integration is one of the highest-risk surfaces in DeFi. We review feed selection, fallback logic, staleness checks, deviation thresholds, and the behaviour of your protocol when the oracle returns an extreme value. If an oracle bug can drain the protocol, we want to know in scoping, not in production.

Where DeFi audits usually get hard.

Solvency is the target

A DeFi audit is not finished when every contract compiles and common access-control checks pass. The question is whether assets, liabilities, shares, debt, collateral, fees, and withdrawals stay consistent through every path users can take. That includes liquidation, redemption, emergency exits, bad debt, parameter changes, and integrations with external markets.

We look for accounting states that are locally valid but globally wrong. A vault can update one balance correctly and still let the system drift. A lending market can enforce collateral checks and still leak value through rounding, stale prices, or liquidation sequencing.

Markets are dependencies

Oracles, AMMs, liquid staking tokens, bridges, and money markets are not passive integrations. They are part of the DeFi protocol threat model. If a price feed can go stale, liquidity can vanish, a sequencer can delay inclusion, or an upstream governance vote can change a parameter, the audit needs to account for it.

Useful inputs for review

  • A list of solvency, collateral, share-price, and liquidation invariants.

  • Mainnet-fork scenarios that reflect expected production markets and oracle feeds.

  • Parameter ranges, keeper assumptions, emergency powers, and governance controls.

  • Known upstream dependencies, including protocols whose parameter changes could affect user funds.

Related research and guidance.

Frequently asked questions.

  • Do you audit the smart contracts or the economic model?

    Both, on the same engagement. The contracts implement the model — finding a contract bug that breaks the model is part of our scope, and identifying a model that breaks even when the contracts are correct is also part of our scope.

  • Can you audit our oracle integration?

    Yes. Oracle dependencies are one of the highest-risk surfaces in DeFi. We review feed selection, fallback logic, staleness checks, deviation thresholds, and the behaviour of your protocol when the oracle returns an extreme value.

  • What about MEV and sandwich exposure?

    We model MEV exposure as part of the audit. This covers user-facing sandwich and frontrun vectors, sequencer-level exposure on L2s, and protocol-internal value leakage to searchers.

  • How do you scope an audit for a fork of an existing protocol?

    Forks of well-audited code (Compound V2, Uniswap V2/V3, Aave V3) get a delta-focused audit. We review the diff against the upstream version line by line, plus any integrations and parameter choices specific to your deployment.

  • Will you review our test suite?

    We read the test suite as part of audit prep. If there are gaps in invariant or fork-test coverage, the report flags them. We do not write tests on your behalf as part of the audit, but we do recommend specific tests where they would have caught a finding.

Other engagements you might be considering.

Scope a DeFi smart contract audit.

Tell us about the protocol you are building. We respond within two business days with a scoping call and a written engagement proposal.

Request a scoping call

Services

Products

Resources

Company

Social

© Copyright 2026 by Sigma Prime. All Rights Reserved.

contact@sigmaprime.io