Crypto project security system development

DeFi Protocol Security Audit

A DeFi audit is not a formality before launch. It is a structured process for identifying vulnerabilities in code that will manage real money without the possibility of emergency patching. Over the past three years, more than $5 billion has leaked through DeFi exploits. Most hacks are not exotic zero-day attacks, but classical vulnerabilities: reentrancy, integer overflow, incorrect state validation, price manipulation via flash loans.

A good audit finds these problems before attackers do.

What a professional DeFi audit includes

Manual code review

Automated tools (Slither, Mythril) find ~30-40% of typical vulnerabilities. The rest requires manual analysis. An auditor reads the code as an attacker: what invariants must be maintained? What happens if each is violated? How can the contract be forced to violate its own invariants?

Specific vectors checked manually:

Reentrancy. Including cross-function reentrancy (attack through another function of the same contract) and cross-contract reentrancy (contract A reenters contract B via callback). Example: Curve in 2023 had a reentrancy vulnerability in the Vyper compiler that allowed attacking multiple pools, total losses $62M.

// Vulnerable pattern
function withdraw(uint256 amount) external {
    balances[msg.sender] -= amount;
    (bool success,) = msg.sender.call{value: amount}(""); // vulnerable if msg.sender is a contract
    require(success);
}

// Correct: CEI pattern (Checks-Effects-Interactions)
function withdraw(uint256 amount) external nonReentrant {
    require(balances[msg.sender] >= amount, "Insufficient");
    balances[msg.sender] -= amount;  // Effect first
    (bool success,) = msg.sender.call{value: amount}(""); // Interaction last
    require(success, "Transfer failed");
}

Oracle manipulation. Protocols using spot price from AMM pools as oracle are vulnerable to flash loan attacks: in one transaction, (1) attacker takes a flash loan, (2) manipulates pool price, (3) exploits protocol at distorted price, (4) repays loan. Mango Markets ($114M), Euler Finance ($197M) — oracle manipulation was among the vectors.

Check: does the protocol use TWAP (time-weighted average price) from Uniswap v3, Chainlink, or custom VWAP? Single-block flash loan manipulations are only possible against spot price.

Access control. Who can call privileged functions? Are roles configured correctly? Are there unprotected functions that should be restricted? Standard pattern: check each external and public function to determine if it should be restricted.

Formal verification

For critical mathematical invariants — formal verification through Certora Prover or Halmos (symbolic execution on Foundry). Example invariant for lending protocol: "total debt of all borrowers never exceeds total deposits plus accumulated interest".

Certora Prover works with CVL (Certora Verification Language) — a declarative language for describing properties:

rule totalDebtNeverExceedsDeposits {
    uint256 totalDebt = getTotalDebt();
    uint256 totalDeposits = getTotalDeposits();
    uint256 accruedInterest = getAccruedInterest();
    
    assert totalDebt <= totalDeposits + accruedInterest;
}

If a rule is violated — Prover generates a counterexample: a specific sequence of calls leading to violation. This is not just a test — it is a mathematical proof for all possible inputs.

Economic attack analysis

Technical correctness of code is necessary but insufficient. An economically sophisticated attacker can exploit protocol mechanics without a single technical vulnerability.

Price impact attacks. If protocol uses on-chain pricing with insufficient slippage protection — large trades can move price unfavorably for the protocol.

Liquidation cascades. In lending protocols: sharp drop in collateral price → many positions underwater → liquidators can't keep up → protocol accumulates bad debt. Analysis: is liquidation margin sufficient? How does protocol behave with 50% collateral price drop in one block?

MEV and sandwich attacks. If frontend allows too high slippage tolerance — user transactions are vulnerable to sandwich attacks. Audit checks not only contracts but also frontend recommendations.

Token-specific risks. Tokens with transfer fees (deflationary), rebase tokens (AMPL, stETH), tokens with blacklist function (USDC, USDT) — all violate standard ERC-20 expectations. A protocol not accounting for these quirks gets accounting errors.

Static analysis tools

Slither

Slither (Trail of Bits) — the most powerful static analyzer for Solidity. 90+ detectors for known vulnerability patterns. Runs locally or in CI:

slither . --checklist --markdown-root https://github.com/project/repo/

Generates report classified by severity: High, Medium, Low, Informational, Optimization. Most High findings are false positives or known patterns, but need manual verification.

Useful detectors: reentrancy-eth, arbitrary-send-eth, controlled-delegatecall, msg-value-loop, tautology.

Mythril

Mythril (ConsenSys Diligence) — symbolic execution. Attempts to find execution paths where asserts are violated. Slower than Slither, analyzes execution paths more deeply.

Echidna (fuzzing)

Echidna (Trail of Bits) — property-based fuzzer for Solidity. You define invariants as functions with echidna_ prefix, Echidna generates random transaction sequences trying to violate them:

contract TestLendingPool is LendingPool {
    // Invariant: totalBorrowed never exceeds totalDeposited
    function echidna_debt_invariant() public view returns (bool) {
        return totalBorrowed() <= totalDeposited();
    }
    
    // Invariant: user balance doesn't go negative
    function echidna_no_negative_balance() public view returns (bool) {
        return balanceOf(msg.sender) >= 0; // uint256, always true — but checks overflow
    }
}

Echidna is especially effective at finding edge cases in math: uint256 overflow, division by zero, precision loss in rounding.

Foundry invariant tests

Foundry has built-in invariant fuzzing through invariant_ prefix. Integrates into existing test suite:

function invariant_totalSharesMatchTotalAssets() public {
    assertApproxEqRel(
        vault.totalAssets(),
        vault.totalShares() * vault.sharePrice() / 1e18,
        1e15 // 0.1% tolerance for rounding
    );
}

Vulnerability classification

Critical and High findings must be fixed before deployment. Medium — fixed or explicitly documented with accepted risk rationale.

Process and timeline

Pre-audit (1 week). Team provides: final code (frozen), architecture documentation, invariant specification, known limitations. Auditor prepares threat model and scope.

Audit phase 1 (2-3 weeks). Each auditor works independently. Manual review + automated tools. No communication between auditors — prevents bias.

Audit phase 2 (1 week). Auditors exchange findings, joint analysis of disputed cases, economic attack simulation.

Draft report (3-5 days). Report with classified findings, proof of concept for critical vulnerabilities, remediation recommendations.

Remediation (1-3 weeks). Team fixes findings. Auditors verify fixes — separate review pass.

Final report. Public or private report with resolved/acknowledged/won't-fix statuses.

Choosing an auditor

Top-tier firms: Trail of Bits, OpenZeppelin, ChainSecurity, Halborn, Certik (for larger projects), Spearbit. Independent researchers via Code4rena or Sherlock — a good way to get additional eyes after main audit.

Red flags when choosing auditor: no public reports in portfolio, audit timeline less than 1 week for >1000 LOC, no economic analysis.

Audit cost (estimate): simple ERC-20 + staking — $10-30K, medium DeFi protocol (1000-3000 LOC) — $40-100K, complex lending/perp DEX — $100-300K+. Expensive? Compare with $50-200M lost in average DeFi exploit.