Security Blog

Understanding Flash Loans

Flash loans allow users to borrow capital without collateral, provided the loan is repaid within the same transaction. If any operation fails, the entire transaction reverts. This enables arbitrage opportunities but also creates attack vectors.

In Q1 2024 alone, 10 high-profile flash loan attacks resulted in over $33 million in losses. The Sonne Finance exploit in May 2024 stands out, where attackers drained $20 million by exploiting a known vulnerability in Compound V2 forks combined with flash-loaned capital.

Anatomy of a Flash Loan Attack

Flash loan attacks typically follow this pattern:

1. Borrow: Attacker takes out a massive flash loan (often millions of dollars)
2. Manipulate: Use the borrowed funds to manipulate prices, collateral values, or protocol state
3. Exploit: Take advantage of the manipulated state to extract value
4. Repay: Return the flash loan plus fees from the profits
5. Profit: Keep the remaining extracted value

All of this happens in a single, atomic transaction. If any step fails, the entire transaction reverts, and the attacker only loses gas fees.

Common Flash Loan Attack Vectors

1. Oracle Manipulation

Many protocols use on-chain price oracles, such as Uniswap's spot price. Attackers can use flash loans to temporarily skew these prices:

// Simplified Oracle Manipulation Attack
function attack() external {
    // 1. Borrow 100M USDC via flash loan
    flashLender.flashLoan(100_000_000 * 1e6);
}

function executeOperation(uint256 amount) external {
    // 2. Dump USDC into ETH/USDC pool, crashing USDC price
    uniswapPool.swap(amount, 0, address(this), "");

    // 3. Protocol now thinks ETH is worth more USDC
    // Borrow against inflated collateral value
    lendingProtocol.borrow(massiveAmount);

    // 4. Swap back to restore prices
    // 5. Repay flash loan, keep profits
}

2. Governance Attacks

Attackers can flash loan governance tokens to gain temporary voting power, pass malicious proposals, or manipulate protocol parameters within a single block.

3. Liquidation Manipulation

By manipulating collateral prices, attackers can trigger liquidations on healthy positions or prevent their own positions from being liquidated.

4. Reentrancy Amplification

Flash loans can amplify the impact of reentrancy vulnerabilities by providing the capital needed to repeatedly exploit the vulnerability.

Case Study: Euler Finance ($197M, March 2023)

The Euler Finance hack remains one of the largest flash loan attacks in history. The attacker exploited a vulnerability in the donation and liquidation mechanism:

1. Flash borrowed DAI and WETH
2. Deposited into Euler to mint eDAI tokens
3. Used the "donateToReserves" function to inflate bad debt
4. Exploited the soft liquidation mechanism
5. Drained the protocol's reserves

Mitigation Strategies

1. Use Decentralized Oracle Networks

Chainlink and other decentralized oracle networks aggregate prices from multiple sources and include manipulation-resistant mechanisms like TWAP (Time-Weighted Average Price).

2. Implement TWAP with Sufficient Windows

If using on-chain oracles, ensure TWAP windows are long enough to resist single-block manipulation. A minimum of 30 minutes is recommended for high-value operations.

3. Add Flash Loan Guards

modifier noFlashLoan() {
    require(
        tx.origin == msg.sender ||
        lastTxBlock[msg.sender] < block.number,
        "Flash loan detected"
    );
    lastTxBlock[msg.sender] = block.number;
    _;
}

4. Implement Borrow Limits

Cap the amount that can be borrowed or the value that can be extracted in a single transaction.

5. Time-Lock Sensitive Operations

Require a delay between depositing collateral and borrowing, or between governance proposals and execution.

The Double-Edged Sword

Flash loans democratize access to capital and enable legitimate use cases like:

• Arbitrage that improves market efficiency
• Collateral swaps without additional capital
• Self-liquidation to avoid penalties
• One-transaction leveraged positions

The challenge for protocol developers is embracing these benefits while hardening their systems against manipulation. As DeFi matures, we expect to see more sophisticated defenses and, inevitably, more sophisticated attacks.

Conclusion

Flash loan attacks represent the cutting edge of DeFi exploitation. They demonstrate that security in blockchain isn't just about individual contract safety - it's about understanding how your protocol interacts with the broader ecosystem under adversarial conditions. Every protocol should assume attackers have access to unlimited capital for the duration of a single transaction and design accordingly.

The Cost of Broken Access Control

Access control vulnerabilities are the leading cause of funds lost in smart contract exploits. In 2024, these flaws accounted for approximately $953 million in losses. Unlike flash loan manipulation, access control bugs are often simple: a missing onlyOwner modifier or a public function that should have been internal.

Common Access Control Vulnerabilities

1. Missing Function Visibility

In Solidity versions before 0.8.0, functions defaulted to public visibility. Even in modern Solidity, developers sometimes forget to restrict sensitive functions:

// VULNERABLE: Anyone can call this
function setAdmin(address newAdmin) external {
    admin = newAdmin;
}

// SECURE: Properly restricted
function setAdmin(address newAdmin) external onlyOwner {
    admin = newAdmin;
}

2. Unprotected Initialize Functions

Upgradeable contracts using proxy patterns must protect their initialization functions. The Parity Wallet hack of 2017 occurred because anyone could call initWallet() and take ownership:

// VULNERABLE: Can be called by anyone after deployment
function initialize(address _owner) public {
    owner = _owner;
}

// SECURE: Can only be initialized once
bool private initialized;

function initialize(address _owner) public {
    require(!initialized, "Already initialized");
    initialized = true;
    owner = _owner;
}

3. tx.origin Authentication

Using tx.origin for authentication is dangerous because it refers to the original transaction sender, not the immediate caller. This enables phishing attacks:

// VULNERABLE: Phishing attack possible
function transferOwnership(address newOwner) external {
    require(tx.origin == owner, "Not owner");
    owner = newOwner;
}

// Attack scenario:
// 1. Victim is tricked into calling attacker's contract
// 2. Attacker's contract calls transferOwnership()
// 3. tx.origin == victim (the owner), so check passes
// 4. Attacker becomes new owner

// SECURE: Use msg.sender
function transferOwnership(address newOwner) external {
    require(msg.sender == owner, "Not owner");
    owner = newOwner;
}

4. Signature Replay Attacks

When using signatures for authentication, failing to include proper replay protection allows attackers to reuse valid signatures:

// VULNERABLE: Same signature can be used multiple times
function executeWithSig(bytes calldata data, bytes calldata sig) external {
    address signer = recoverSigner(data, sig);
    require(signer == owner, "Invalid signature");
    // Execute data...
}

// SECURE: Include nonce and chain ID
mapping(address => uint256) public nonces;

function executeWithSig(
    bytes calldata data,
    uint256 nonce,
    uint256 deadline,
    bytes calldata sig
) external {
    require(block.timestamp <= deadline, "Expired");
    require(nonces[msg.sender]++ == nonce, "Invalid nonce");

    bytes32 hash = keccak256(abi.encodePacked(
        data, nonce, deadline, block.chainid, address(this)
    ));
    address signer = recoverSigner(hash, sig);
    require(signer == owner, "Invalid signature");
}

5. Improper Role Management

Role-based access control (RBAC) systems can have vulnerabilities in how roles are granted, revoked, or checked:

// VULNERABLE: Role check before setting new admin
function grantRole(bytes32 role, address account) public {
    // Bug: Should check if msg.sender has admin role FIRST
    roles[role][account] = true;
    require(hasRole(ADMIN_ROLE, msg.sender), "Not admin");
}

// SECURE: Check authorization first
function grantRole(bytes32 role, address account) public {
    require(hasRole(ADMIN_ROLE, msg.sender), "Not admin");
    roles[role][account] = true;
}

Real-World Example: Wormhole Bridge ($320M)

The Wormhole bridge hack in February 2022 exploited an access control flaw in the signature verification process. The attacker was able to:

1. Bypass the guardian signature verification
2. Forge a message indicating 120,000 wETH had been deposited
3. Mint 120,000 wETH on Solana without any actual deposit

Best Practices for Access Control

1. Use OpenZeppelin's Access Control Libraries

Don't reinvent the wheel. OpenZeppelin provides battle-tested implementations of Ownable, AccessControl, and AccessControlEnumerable.

2. Apply Principle of Least Privilege

Every function should require the minimum permissions necessary. Avoid god-mode admin roles that can do everything.

3. Implement Time Locks for Sensitive Operations

Give users time to react to malicious admin actions by requiring delays on sensitive changes.

4. Use Multi-Sig for Critical Functions

Require multiple signatures for operations like upgrading contracts, changing parameters, or withdrawing funds.

5. Audit All External and Public Functions

Every function that can be called externally is an attack surface. Review each one carefully for proper access restrictions.

Conclusion

Access control bugs are often the simplest vulnerabilities but have the most devastating consequences. A single missing modifier can result in complete loss of funds. Developers should treat every external function as potentially dangerous and explicitly verify that proper restrictions are in place. When in doubt, make it more restrictive - you can always loosen permissions later, but you can't recover stolen funds.

The Problem

Integer overflow and underflow vulnerabilities occur when arithmetic operations produce results outside the range a data type can represent. These bugs have been exploited to mint unlimited tokens, steal funds, and bypass security checks. The BeautyChain (BEC) hack of 2018 used an integer overflow to generate tokens, crashing the token's value.

How Overflow and Underflow Work

Solidity integers have fixed sizes. A uint8 can store values from 0 to 255. A uint256 can store values from 0 to 2^256 - 1. When arithmetic exceeds these bounds:

// Overflow Example (in Solidity < 0.8.0)
uint8 a = 255;
uint8 b = a + 1;  // b = 0 (wrapped around!)

// Underflow Example
uint8 c = 0;
uint8 d = c - 1;  // d = 255 (wrapped around!)

// Real Attack Scenario
function transfer(address to, uint256 amount) external {
    // If balance is 100 and amount is 101:
    // 100 - 101 = huge number due to underflow
    require(balances[msg.sender] - amount >= 0);  // Always passes!

    balances[msg.sender] -= amount;  // Underflows to max uint256
    balances[to] += amount;
}

The BeautyChain Exploit

The BEC token had a batch transfer function that calculated the total amount by multiplying the value per address by the number of recipients:

function batchTransfer(address[] _receivers, uint256 _value) public {
    uint256 cnt = _receivers.length;
    uint256 amount = cnt * _value;  // OVERFLOW HERE!

    require(_value > 0 && balances[msg.sender] >= amount);

    balances[msg.sender] -= amount;
    for (uint256 i = 0; i < cnt; i++) {
        balances[_receivers[i]] += _value;
    }
}

// Attack: Call with 2 receivers and value = 2^255
// amount = 2 * 2^255 = 2^256 = 0 (overflow!)
// Check passes: balance >= 0
// Each receiver gets 2^255 tokens for free!

Solidity 0.8+ Built-in Protection

Starting with Solidity 0.8.0, the compiler automatically checks for overflow and underflow, reverting the transaction if detected:

// In Solidity 0.8+
uint8 a = 255;
uint8 b = a + 1;  // REVERTS with panic code 0x11

When 0.8 Protections Fail

Despite these protections, integer issues can still occur:

1. Unchecked Blocks

Developers can disable overflow checks for gas optimization:

function riskyOperation() external {
    unchecked {
        uint8 a = 255;
        uint8 b = a + 1;  // b = 0, no revert!
    }
}

2. Type Casting

Casting between integer sizes doesn't check for overflow:

uint256 big = 1000;
uint8 small = uint8(big);  // small = 232 (1000 mod 256)
// No revert, silent truncation!

3. Division and Modulo

While overflow is checked, precision loss from integer division is not:

uint256 a = 5;
uint256 b = 2;
uint256 c = a / b;  // c = 2, not 2.5
// In financial calculations, this rounding can be exploited

4. Shift Operations

Bit shift operations have their own edge cases:

uint256 x = 1;
uint256 y = x << 256;  // y = 0 (shifted out)
uint256 z = x >> 256;  // z = 0

Mitigation Strategies

1. Use Solidity 0.8.0 or Later

This provides automatic overflow/underflow protection for most operations.

2. Careful Use of unchecked

Only use unchecked blocks when you've mathematically proven overflow is impossible:

// Safe: i can never overflow because of loop bound
for (uint256 i = 0; i < arr.length;) {
    // process arr[i]
    unchecked { i++; }  // Gas optimization
}

3. Safe Casting Libraries

Use OpenZeppelin's SafeCast for type conversions:

import "@openzeppelin/contracts/utils/math/SafeCast.sol";

uint256 big = 1000;
uint8 small = SafeCast.toUint8(big);  // Reverts if big > 255

4. Multiplication Before Division

To minimize precision loss:

// BAD: precision loss
uint256 result = (a / c) * b;

// BETTER: minimize precision loss
uint256 result = (a * b) / c;

// BEST: check for overflow first
uint256 result = FullMath.mulDiv(a, b, c);

Testing for Integer Issues

Effective testing strategies include:

• Boundary testing: Test with values at 0, 1, max-1, and max
• Fuzzing: Use tools like Foundry's fuzzer to find edge cases
• Static analysis: Tools like Slither can detect potential integer issues
• Formal verification: Mathematically prove absence of overflow

Conclusion

While Solidity 0.8+ has dramatically reduced integer overflow vulnerabilities, they haven't been eliminated. Developers must remain vigilant about type casting, unchecked blocks, and precision loss. The most dangerous bugs often lurk in code that looks correct at first glance but fails at extreme values. Comprehensive testing with boundary values and fuzzing remains essential.

What is MEV?

Maximal Extractable Value (MEV) refers to the maximum value that can be extracted from a block by manipulating the order, inclusion, or exclusion of transactions. Originally called "Miner Extractable Value," the concept was renamed after Ethereum's transition to Proof of Stake, where validators now control transaction ordering.

MEV represents an invisible tax on blockchain users. When you submit a transaction, sophisticated actors can see it in the mempool and reorder or insert their own transactions to extract value from yours. A 2-year dataset analysis of Ethereum shows that despite countermeasures, MEV extraction continues to grow, potentially hindering Ethereum's adoption.

Types of MEV Attacks

1. Front-Running

An attacker sees your profitable transaction in the mempool and submits the same transaction with a higher gas price, ensuring theirs executes first:

// You: Spot arbitrage opportunity, submit tx to buy TOKEN cheap
// Mempool: Your tx visible with all details
// Attacker: Copies your tx, sets higher gas price
// Block order: [Attacker's buy] -> [Your buy (now unprofitable)]
// Result: Attacker profits, you get worse price or fail

2. Sandwich Attacks

The most common MEV attack on DEX traders. The attacker places transactions before AND after your swap:

// Your pending swap: Buy 1 ETH with USDC, 1% slippage tolerance

// Sandwich attack structure:
// 1. [Attacker Front-run] Buy ETH, push price up
// 2. [Your Swap] Buy ETH at inflated price (within slippage)
// 3. [Attacker Back-run] Sell ETH at higher price

// Example with numbers:
// ETH price: $2000
// 1. Attacker buys, price now $2018
// 2. You buy at $2018 (within 1% slippage of $2020)
// 3. Attacker sells at $2016 (price drops slightly)
// Attacker profit: ~$16 per ETH you bought

3. Liquidation MEV

Bots compete to liquidate undercollateralized positions in lending protocols, often front-running each other and legitimate liquidators.

4. Time-Bandit Attacks

In extreme cases, the MEV opportunity may be large enough to incentivize validators to propose competing blocks or reorganize recent blocks - essentially rewriting short-term history.

5. Just-In-Time (JIT) Liquidity

MEV bots add liquidity to a pool immediately before a large swap (earning fees) and remove it immediately after, capturing value without long-term liquidity commitment.

The MEV Supply Chain

MEV extraction has become industrialized:

1. Searchers: Bots that identify MEV opportunities
2. Builders: Entities that construct optimized blocks
3. Relayers: Infrastructure connecting builders to validators
4. Validators: Propose blocks, capture majority of MEV value

Services like Flashbots have created a parallel, private transaction pool where users can submit transactions that won't be seen by the public mempool, protecting against some forms of MEV.

Protecting Your Smart Contracts

1. Commit-Reveal Schemes

Hide transaction details until execution:

// Phase 1: Commit (reveals nothing about the trade)
function commit(bytes32 hash) external {
    commits[msg.sender] = Commit({
        hash: hash,
        block: block.number
    });
}

// Phase 2: Reveal (after commitment is finalized)
function reveal(
    uint256 amount,
    uint256 minOut,
    bytes32 secret
) external {
    Commit memory c = commits[msg.sender];
    require(block.number > c.block + REVEAL_DELAY, "Too early");
    require(
        keccak256(abi.encode(amount, minOut, secret)) == c.hash,
        "Invalid reveal"
    );

    // Execute trade
    _swap(amount, minOut);
}

2. Private Transaction Pools

Use Flashbots Protect or similar services to submit transactions directly to block builders, bypassing the public mempool:

// Instead of:
provider.sendTransaction(tx);

// Use Flashbots:
flashbotsProvider.sendPrivateTransaction(tx);

3. MEV-Resistant AMM Designs

Some protocols implement batch auctions or other mechanisms that eliminate ordering advantages:

• CoW Protocol: Batch auctions with uniform clearing prices
• Frequent Batch Auctions: Collect orders over time, execute simultaneously
• Threshold Encryption: Orders are encrypted until execution time

4. Dynamic Slippage Protection

Calculate safe slippage bounds based on pool liquidity and trade size rather than using fixed percentages.

5. Time-Weighted Average Price (TWAP)

Split large orders into smaller pieces over time to reduce sandwich profitability.

The Future of MEV

The MEV landscape is evolving rapidly:

• Encrypted Mempools: Transactions encrypted until block finalization
• Intent-Based Systems: Users specify outcomes, solvers compete to fulfill
• MEV Redistribution: Protocols returning MEV to affected users
• Cross-Domain MEV: Extraction across L1s, L2s, and bridges

Conclusion

MEV is not going away - it's a fundamental property of public, transparent blockchains with value at stake. However, understanding MEV allows developers to design more resilient protocols and users to protect themselves. The key is recognizing that in blockchain, transaction ordering is a privilege that creates power - and that power will always be exploited unless explicitly mitigated.