Development of Flash Loan Protocol
Flash loan — atomic credit: borrow any amount, do anything, return in same transaction. If return didn't happen — entire transaction reverts. No collateral, no credit history. Aave V3 holds hundreds of millions in flash loan pools — and it works, because EVM atomicity is absolute guarantee.
But same atomicity makes flash loans primary tool for DeFi attacks. Of 10 largest hacks in past three years — minimum 7 used flash loans as startup capital for oracle manipulation, price manipulation, or governance attacks.
Flash loan protocol architecture
Execution mechanics
Classic Aave V2 scheme: pool calls executeOperation() on receiver address, transfers assets, receiver does what's needed, returns assets + premium. Entire scenario — one flashLoan() call, one transaction, one block.
Aave V3 added flashLoanSimple() for single asset (cheaper gas) and reworked receiver interface to IFlashLoanSimpleReceiver. EIP-3156 formalized standard: flashLoan(receiver, token, amount, data) and mandatory onFlashLoan() callback. Building protocol for integration — makes sense to support both interfaces.
Implementation types
Single-asset flash loans (EIP-3156 compliant): simplest option. One token, one receiver. Minimal gas. Works for protocols wanting monetize idle liquidity.
Multi-asset batch loans (Aave-style): multiple tokens in one transaction. More complex implementation, but opens scenarios like "borrow ETH + USDC simultaneously for pool arbitrage". Implemented via arrays of assets/amounts in one call.
Callback-less flash loans (Uniswap V2-style): pool transfers tokens first, receiver returns at end of transaction via separate call. Less secure construction — receiver must check it's not called repeatedly.
Key security issues
Reentrancy via flash loan callback
Standard trap: receiver contract calls other pool function inside executeOperation(). If pool not protected by reentrancy guard at storage level — attacker can change pool state before original transaction completes.
// WRONG: reentrancy possible
function flashLoan(address receiver, uint256 amount) external {
uint256 balanceBefore = token.balanceOf(address(this));
token.transfer(receiver, amount);
IFlashLoanReceiver(receiver).executeOperation(amount, fee, msg.sender);
// receiver could call deposit() and change balanceBefore logic
require(token.balanceOf(address(this)) >= balanceBefore + fee);
}
Solution: nonReentrant modifier from OpenZeppelin on flashLoan() and all pool state-changing functions (deposit, withdraw, borrow).
Caller verification in receiver contract
Receiver must verify that executeOperation() called by trusted pool, not arbitrary address. Without this check, attacker can call executeOperation() directly on receiver, simulating flash loan.
function executeOperation(
address asset,
uint256 amount,
uint256 premium,
address initiator,
bytes calldata params
) external override returns (bool) {
require(msg.sender == address(LENDING_POOL), "Invalid caller");
require(initiator == address(this), "Invalid initiator");
// logic
}
Fee accounting and precision issues
Typical mistake: fee calculated as amount * FEE_BPS / 10000 where FEE_BPS = 9 (0.09%). With small amounts, result rounds to 0 due to integer division. Attacker splits one large loan into thousands small and pays zero fee.
Protection: minimum fee in absolute value (e.g., 1 wei) and check amountOwed > amount — not just amountOwed >= amount + fee_calculated.
Building flash loan protocol
Stack: Solidity 0.8.x, OpenZeppelin 5.x for ReentrancyGuard and SafeERC20, Foundry for testing.
Pool contract stores provider liquidity. Support multiple tokens via token => PoolState mapping. PoolState includes: totalLiquidity, totalBorrowed (for simultaneous loan tracking), feeAccumulator for LP rewards.
Fee distribution: flash loan fees accumulate in pool and increase LP token exchange rate (like Compound cTokens). LPs earn yield without separate claim — simply get more base token on withdrawal.
Access control: via OpenZeppelin AccessControl. Roles: PAUSER_ROLE (circuit breaker during attack), FEE_SETTER_ROLE (under timelock governance), ASSET_MANAGER_ROLE (adding new tokens).
Circuit breaker: if more than X% liquidity left pool in single block — automatic pause. Implemented via _blockLoanVolume mapping and check at flashLoan() start. False positives possible with legitimate use — set threshold via governance.
Testing
Fork-tests on Ethereum mainnet critical. Run through Foundry:
- Standard loan and return with fee
- Attempt no-return — transaction should revert
- Reentrancy attack on
flashLoan()via malicious receiver - Zero fee on minimum amount (check anti-dust logic)
- Panic: 100 consecutive max-volume loans
Fuzzing in Echidna with invariant: totalLiquidity after any operation sequence not less than sum of deposits minus withdrawals.
Legitimate use cases — why build this
Flash loans — not just attacks. Protocol opens:
Arbitrage without capital: trader sees price difference between Uniswap and Curve, borrows loan, executes arbitrage, returns. Profit — spread minus gas. DEX arbitrage equalizes prices, making markets efficient.
Self-liquidation: user with Aave position near liquidation borrows flash loan, repays debt, withdraws collateral, returns loan. Avoids external liquidator penalty.
Collateral swap: replace ETH collateral with WBTC without closing position. One transaction instead of four.
Leverage unwinding: close leveraged position in one transaction.
Timeline estimates
Basic EIP-3156 compliant protocol for single token — 3-5 days including tests. Multi-asset pool with LP tokens and fee distribution — 1-1.5 weeks. Integration with existing lending protocol (adding flash loans on top) — 1-2 weeks depending on base protocol architecture. Cost calculated after requirements analysis.