DeFi Protocol Patterns

AMM (Automated Market Maker)

The constant product formula x * y = k is the foundation of Uniswap V2-style AMMs.

Core mechanics:

• Two tokens in a pool with reserves x and y
• Product k = x * y must remain constant after every trade
• Buying token A increases its price (less A, more B in pool)
• Liquidity providers (LPs) deposit both tokens proportionally

contract SimpleAMM {
    IERC20 public tokenA;
    IERC20 public tokenB;
    uint256 public reserveA;
    uint256 public reserveB;

    function swap(address tokenIn, uint256 amountIn)
        external
        returns (uint256 amountOut)
    {
        require(amountIn > 0, "Zero amount");
        bool isA = tokenIn == address(tokenA);
        (uint256 resIn, uint256 resOut) = isA
            ? (reserveA, reserveB)
            : (reserveB, reserveA);

        // 0.3% fee
        uint256 amountInWithFee = amountIn * 997;
        amountOut = (amountInWithFee * resOut) /
            (resIn * 1000 + amountInWithFee);

        // Update reserves
        if (isA) {
            reserveA += amountIn;
            reserveB -= amountOut;
        } else {
            reserveB += amountIn;
            reserveA -= amountOut;
        }

        IERC20(tokenIn).transferFrom(msg.sender, address(this), amountIn);
        (isA ? tokenB : tokenA).transfer(msg.sender, amountOut);
    }
}

Key risks:

• Impermanent loss for LPs when prices diverge
• Flash loan manipulation of reserves for price oracle attacks
• Sandwich attacks (front-running + back-running user swaps)

Mitigation: Use TWAP oracles, enforce slippage protection (minAmountOut), add deadline parameters.

Lending protocol

Lending protocols (Aave, Compound) allow users to supply collateral and borrow against it.

Core concepts:

• Collateral factor: Maximum borrow value as % of collateral (e.g., 75%)
• Liquidation threshold: Borrow/collateral ratio triggering liquidation (e.g., 80%)
• Interest rate model: Algorithmic rate based on utilization (borrowed / supplied)
• Health factor: (collateral * liquidation_threshold) / borrow_value - below 1.0 = liquidatable

contract SimpleLending {
    struct UserAccount {
        uint256 collateral;
        uint256 borrowed;
        uint256 lastUpdate;
    }

    uint256 public constant COLLATERAL_FACTOR = 7500; // 75% in basis points
    uint256 public constant LIQUIDATION_THRESHOLD = 8000; // 80%
    uint256 public constant BASIS_POINTS = 10000;

    mapping(address => UserAccount) public accounts;

    function borrow(uint256 amount) external {
        UserAccount storage account = accounts[msg.sender];
        accrueInterest(account);

        uint256 maxBorrow = (account.collateral * COLLATERAL_FACTOR) / BASIS_POINTS;
        require(account.borrowed + amount <= maxBorrow, "Exceeds collateral factor");

        account.borrowed += amount;
        // transfer borrowed tokens to user
    }

    function isLiquidatable(address user) public view returns (bool) {
        UserAccount memory account = accounts[user];
        uint256 threshold = (account.collateral * LIQUIDATION_THRESHOLD) / BASIS_POINTS;
        return account.borrowed > threshold;
    }
}

Key risks:

• Oracle manipulation to trigger false liquidations
• Bad debt from rapid price drops exceeding liquidation capacity
• Interest rate model exploits (manipulating utilization ratio)

ERC-4626 tokenized vault

The standard interface for yield-bearing vaults. Users deposit an underlying asset and receive vault shares representing their proportional claim.

Core formula:

• shares = assets * totalSupply / totalAssets (on deposit)
• assets = shares * totalAssets / totalSupply (on withdrawal)

import "@openzeppelin/contracts/token/ERC20/extensions/ERC4626.sol";

contract YieldVault is ERC4626 {
    constructor(IERC20 asset_)
        ERC4626(asset_)
        ERC20("Yield Vault", "yVAULT")
    {}

    function totalAssets() public view override returns (uint256) {
        // Include earned yield in total
        return IERC20(asset()).balanceOf(address(this)) + _pendingYield();
    }

    function _pendingYield() internal view returns (uint256) {
        // Calculate yield from strategy
        return 0; // placeholder
    }
}

Key risks:

• First depositor attack: attacker inflates share price to steal from next depositor
• Mitigation: seed vault with initial deposit, or use virtual shares (OpenZeppelin default)
• Donation attacks: sending assets directly to inflate totalAssets

Staking and reward distribution

Distributing rewards proportionally to stakers without iterating over all stakers.

Reward-per-token accumulator pattern (used by Synthetix):

contract StakingRewards {
    IERC20 public stakingToken;
    IERC20 public rewardToken;

    uint256 public rewardRate; // rewards per second
    uint256 public lastUpdateTime;
    uint256 public rewardPerTokenStored;

    mapping(address => uint256) public userRewardPerTokenPaid;
    mapping(address => uint256) public rewards;
    mapping(address => uint256) public balances;
    uint256 public totalSupply;

    modifier updateReward(address account) {
        rewardPerTokenStored = rewardPerToken();
        lastUpdateTime = block.timestamp;
        if (account != address(0)) {
            rewards[account] = earned(account);
            userRewardPerTokenPaid[account] = rewardPerTokenStored;
        }
        _;
    }

    function rewardPerToken() public view returns (uint256) {
        if (totalSupply == 0) return rewardPerTokenStored;
        return rewardPerTokenStored +
            ((block.timestamp - lastUpdateTime) * rewardRate * 1e18) / totalSupply;
    }

    function earned(address account) public view returns (uint256) {
        return (balances[account] *
            (rewardPerToken() - userRewardPerTokenPaid[account])) / 1e18
            + rewards[account];
    }

    function stake(uint256 amount) external updateReward(msg.sender) {
        totalSupply += amount;
        balances[msg.sender] += amount;
        stakingToken.transferFrom(msg.sender, address(this), amount);
    }

    function withdraw(uint256 amount) external updateReward(msg.sender) {
        totalSupply -= amount;
        balances[msg.sender] -= amount;
        stakingToken.transfer(msg.sender, amount);
    }

    function getReward() external updateReward(msg.sender) {
        uint256 reward = rewards[msg.sender];
        if (reward > 0) {
            rewards[msg.sender] = 0;
            rewardToken.transfer(msg.sender, reward);
        }
    }
}

Key insight: The accumulator pattern avoids iterating over all stakers. Each user's reward is calculated as balance * (currentRewardPerToken - userPaidRewardPerToken).

Governance

On-chain governance typically follows the Governor pattern (OpenZeppelin Governor):

Components:

• Token: ERC-20 with voting power (ERC20Votes)
• Governor: Propose, vote, execute lifecycle
• Timelock: Delay between vote passing and execution (gives users time to exit)

Typical flow:

1. User creates proposal (requires minimum token threshold)
2. Voting delay (e.g., 1 day) for users to delegate/prepare
3. Voting period (e.g., 3 days)
4. If passed: queued in timelock (e.g., 2 day delay)
5. After timelock: anyone can execute

Key risks:

• Flash loan governance attacks (borrow tokens, vote, return in same block)
• Mitigation: Require token balance at a past snapshot block, not current balance
• Low voter turnout allowing minority capture
• Timelock bypass via emergency functions

Common ERC standards reference

Gas Optimization Guide

EVM opcode cost reference

Understanding gas costs at the opcode level is essential for meaningful optimization.

Key insight: Storage operations dominate gas costs. A single SSTORE costs more than hundreds of memory or calldata operations combined.

Storage layout optimization

Struct packing

EVM storage uses 32-byte (256-bit) slots. Variables smaller than 32 bytes can share a slot if packed correctly. Solidity packs variables in declaration order.

// BAD: 3 slots (96 bytes of storage)
struct UserBad {
    uint8 age;        // slot 0 (wastes 31 bytes)
    uint256 balance;  // slot 1 (full slot)
    uint8 level;      // slot 2 (wastes 31 bytes)
}

// GOOD: 2 slots (64 bytes of storage)
struct UserGood {
    uint256 balance;  // slot 0 (full slot)
    uint8 age;        // slot 1 (1 byte)
    uint8 level;      // slot 1 (1 byte, packed with age)
}

Rule: Group smaller-than-32-byte types together. Place uint256/bytes32/address types on their own.

Packing booleans

Each bool uses a full storage slot by default. Pack multiple bools into a uint256 using bitwise operations, or use a bitmap.

// BAD: 3 storage slots
bool public paused;
bool public initialized;
bool public locked;

// GOOD: 1 storage slot using bit flags
uint256 private _flags;
uint256 constant PAUSED = 1 << 0;
uint256 constant INITIALIZED = 1 << 1;
uint256 constant LOCKED = 1 << 2;

function isPaused() public view returns (bool) {
    return _flags & PAUSED != 0;
}

Calldata vs memory vs storage

// BAD: copies array to memory (expensive for large arrays)
function sum(uint256[] memory values) external pure returns (uint256) {
    uint256 total;
    for (uint256 i; i < values.length; ++i) {
        total += values[i];
    }
    return total;
}

// GOOD: reads directly from calldata (no copy)
function sum(uint256[] calldata values) external pure returns (uint256) {
    uint256 total;
    for (uint256 i; i < values.length; ++i) {
        total += values[i];
    }
    return total;
}

Rule: Use calldata for external function parameters that are read-only. Use memory only when you need to modify the data within the function.

Loop optimization

// BAD: reads .length from storage each iteration, uses checked arithmetic
function processAll() external {
    for (uint256 i = 0; i < items.length; i++) {
        process(items[i]);
    }
}

// GOOD: cached length, unchecked increment, pre-increment
function processAll() external {
    uint256 length = items.length; // cache storage read
    for (uint256 i; i < length; ) {
        process(items[i]);
        unchecked { ++i; } // safe: i < length guarantees no overflow
    }
}

Savings per iteration: ~100 gas (SLOAD for .length) + ~60 gas (overflow check).

Constants and immutables

// BAD: stored in storage (SLOAD on every read)
address public owner;
uint256 public fee = 300;

// GOOD: embedded in bytecode (no SLOAD)
address public immutable owner; // set once in constructor
uint256 public constant FEE = 300; // compile-time constant

• constant: value known at compile time, embedded in bytecode
• immutable: value set in constructor, embedded in deployed bytecode
• Both avoid SLOAD (2,100 gas saving per read)

Custom errors vs require strings

// BAD: stores string in bytecode, expensive to deploy and emit
require(balance >= amount, "InsufficientBalance: balance too low for withdrawal");

// GOOD: 4-byte selector, minimal bytecode, cheaper to deploy and revert
error InsufficientBalance(uint256 available, uint256 required);

if (balance < amount) revert InsufficientBalance(balance, amount);

Custom errors save ~50 gas per revert and significantly reduce deployment cost for contracts with many require statements.

Event optimization

Events are 10-100x cheaper than storage for data that only needs to be read off-chain.

// BAD: storing historical data in storage
mapping(uint256 => Transfer) public transferHistory;

// GOOD: emit events, index off-chain with The Graph or similar
event TransferRecorded(
    address indexed from,
    address indexed to,
    uint256 amount,
    uint256 timestamp
);

Use indexed on parameters you need to filter by (up to 3 per event). Each indexed parameter adds 375 gas (LOG topic cost).

Deployment cost reduction

Quick reference: optimization checklist

1. Storage variables packed into minimal slots
2. Constructor-set values use immutable
3. Compile-time values use constant
4. External function params use calldata not memory where possible
5. Storage reads cached in local variables inside loops
6. Array .length cached before loops
7. Loop counters use unchecked { ++i; }
8. Custom errors replace require strings
9. Events used instead of storage for off-chain-only data
10. Solidity optimizer enabled with appropriate runs count

Smart Contract Security Audit Guide

Audit checklist

Work through each category in order. For each finding, classify severity as Critical / High / Medium / Low / Informational.

1. Reentrancy

• All external calls happen AFTER state updates (CEI pattern)
• ReentrancyGuard (nonReentrant) used on functions with external calls
• Cross-function reentrancy checked (function A calls B which re-enters A)
• Read-only reentrancy checked (view functions reading stale state during callback)

Real exploit: The DAO hack (2016) - $60M drained because withdraw() sent ETH before updating the balance. The attacker's fallback function re-entered withdraw() repeatedly before the balance was set to zero.

// VULNERABLE
function withdraw() external {
    uint256 amount = balances[msg.sender];
    (bool success, ) = msg.sender.call{value: amount}(""); // external call first
    balances[msg.sender] = 0; // state update after - too late
}

// FIXED (CEI pattern)
function withdraw() external nonReentrant {
    uint256 amount = balances[msg.sender];
    balances[msg.sender] = 0; // state update first
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "Transfer failed");
}

2. Access control

• All privileged functions have proper access modifiers (onlyOwner, role-based)
• Constructor sets initial owner/admin correctly
• No unprotected selfdestruct or delegatecall
• Ownership transfer uses two-step pattern (propose + accept)
• No functions accidentally left public that should be internal or private

3. Integer arithmetic

• Solidity >= 0.8.0 used (built-in overflow/underflow checks)
• unchecked blocks are truly safe (loop counters, verified math)
• Division before multiplication avoided (precision loss)
• Casting between types checked for truncation (uint256 -> uint128)

4. Oracle manipulation

• Spot prices from DEX pools are NOT used for critical decisions
• TWAP (time-weighted average price) used with sufficient window (30 min+)
• Chainlink price feeds use latestRoundData() with staleness checks
• Oracle failure mode handled (stale price, zero price, negative price)

// Chainlink oracle with proper validation
function getPrice(address feed) internal view returns (uint256) {
    (, int256 price, , uint256 updatedAt, ) = AggregatorV3Interface(feed)
        .latestRoundData();
    require(price > 0, "Invalid price");
    require(block.timestamp - updatedAt < 3600, "Stale price");
    return uint256(price);
}

5. Flash loan attack vectors

• No single-transaction price manipulation possible
• Governance voting requires token locking (not just balance snapshot)
• Reward calculations use time-weighted mechanisms
• No reliance on balanceOf(address(this)) for accounting (use internal tracking)

6. Front-running / MEV

• Slippage protection on swaps (minAmountOut parameter)
• Commit-reveal schemes for sensitive operations (auctions, governance)
• Deadline parameters on time-sensitive transactions
• No information leakage in pending transactions that can be exploited

7. External call safety

• Return values of call, delegatecall, staticcall are checked
• No use of transfer() or send() (2300 gas limit breaks receivers)
• External contract addresses validated (not zero address)
• Callbacks from untrusted contracts handled safely

8. Proxy and upgradeability

• Storage layout is append-only between upgrades (no reordering)
• Implementation contract has initializer instead of constructor
• initialize() can only be called once (use OpenZeppelin's Initializable)
• No storage collision between proxy and implementation
• UUPS proxies have _authorizeUpgrade properly restricted

9. Token integration

• ERC-20 tokens with fee-on-transfer handled (check actual received amount)
• ERC-20 tokens with rebasing handled or explicitly blocked
• approve race condition mitigated (use increaseAllowance/decreaseAllowance)
• ERC-777 callback hooks accounted for (reentrancy via token transfer)

10. Denial of service

• No unbounded loops that grow with user count
• Pull-over-push pattern for payments (users withdraw, not contract pushes)
• No single point of failure (owner key compromise doesn't freeze all funds)
• Emergency withdrawal mechanisms for edge cases

Common vulnerability catalog

Tools for auditing