Flash Loan Interaction

FLASH_LOAN_INTERACTION Skill

Trigger Pattern: FLASH_LOAN flag (required) or BALANCE_DEPENDENT flag (optional complement) Inject Into: Breadth agents, depth-token-flow, depth-edge-case

For every flash-loan-accessible state variable or precondition in the protocol:

⚠ STEP PRIORITY: Steps 5 (Defense Audit) and 5b (Defense Parity) are where HIGH/CRITICAL severity findings most commonly hide. Do NOT rush these steps. If constrained, skip conditional sections (0c, 4) before skipping 5, 5b, or 3d.

0. External Flash Susceptibility Check

Before analyzing the protocol's OWN flash loan paths, check whether external protocols the contract interacts with are susceptible to third-party flash manipulation.

0a: External Interaction Inventory

0b: Third-Party Flash Attack Modeling

For each external state marked YES in 0a, model:

1. Before: Protocol reads external state X (e.g., pool reserves, spot price)
2. Flash manipulate: Attacker flash-borrows and trades on the external protocol to move state X
3. Victim call: Attacker calls OUR protocol function that reads manipulated state X
4. Restore: Attacker reverses the external manipulation
5. Impact: What did the attacker gain from our protocol acting on manipulated state?

Key question: Does our protocol use spot state (manipulable) or time-weighted state (resistant)?

<!-- LOAD_IF: DEX_INTERACTION -->

0c: DEX Price Manipulation Cost Estimation

For each external DEX/pool whose spot state is read by the protocol, estimate manipulation cost:

Cost formula: manipulation_cost = slippage * trade_size where trade_size = (target_price_change / price_impact_per_unit) * pool_liquidity. If manipulation_cost < extractable_value → VIABLE.

For Uniswap V2-style: price_impact = trade_size / (reserve + trade_size). For V3 concentrated liquidity: impact depends on tick range - use actual liquidity in the affected range, not total TVL.

<!-- END_LOAD_IF: DEX_INTERACTION -->

1. Flash-Loan-Accessible State Inventory

Enumerate ALL protocol state that can be manipulated within a single transaction via flash-borrowed capital:

For each YES entry: trace all functions that READ this state and make decisions based on it.

Rule 15 check: For each balance/oracle/threshold/rate precondition, model the flash loan atomic sequence.

2. Atomic Attack Sequence Modeling

For each flash-loan-accessible state identified in Step 1:

Attack Template

1. BORROW: Flash-borrow {amount} of {token} from {source}
2. MANIPULATE: {action} to change {state_variable} from {value_before} to {value_after}
3. CALL: Invoke {target_function} which reads manipulated state
4. EXTRACT: {what_is_gained} - quantify: {amount}
5. RESTORE: {action} to return state (if needed for repayment)
6. REPAY: Return {amount + fee} to flash loan source
7. PROFIT: {extract - fee - gas} = {net_profit}

Profitability gate: If net_profit ≤ 0 for all realistic amounts → document as NON-PROFITABLE but check Step 3 for multi-call chains.

For each sequence, verify:

• Can steps 2-5 execute atomically (same transaction)?
• Does any step revert under normal conditions?
• Is the manipulation detectable/preventable by the protocol?
• What is the minimum flash loan amount needed?

3. Cross-Function Flash Loan Chains

Model multi-call atomic sequences within a single flash loan:

Key question: Can calling function A then function B in the same transaction produce a state that neither function alone could create?

Common multi-call patterns:

• Deposit → manipulate rate → withdraw (sandwich own deposit)
• Stake → trigger reward calculation → unstake (flash-stake rewards)
• Borrow → manipulate collateral price → liquidate others → repay
• Deposit to inflate shares → withdraw deflated shares

3b. Flash-Loan-Enabled Debounce DoS

For each permissionless function with a cooldown/debounce that affects OTHER users (global cooldown, shared timestamp): Can attacker flash-borrow → call debounced function → trigger cooldown, blocking legitimate callers?

If cooldown is global/shared AND function is permissionless AND flash-triggerable → FINDING (R2, minimum Medium).

3c. No-Op Resource Consumption

For each state-modifying function with a limited-use resource (cooldown, one-time flag, nonce, epoch-bound action): Can it be called with parameters producing zero economic effect (amount=0, same-token swap, self-transfer) while consuming the resource?

If a no-op call consumes a resource blocking legitimate use → FINDING (R2, resource waste).