/flash-loan-interaction

name: "flash-loan-interaction"
description: "Trigger Pattern FLASH_LOAN flag (required) or BALANCE_DEPENDENT flag (optional complement) - Inject Into Breadth agents, depth-token-flow, depth-edge-case"

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 > **Purpose**: Analyze flash loan attack surfaces in Aptos Move protocols, focusing on the hot potato receipt pattern, state manipulation during flash loan windows, and defense parity

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

| External Protocol | Interaction Type | State Read by Our Protocol | Can 3rd Party Flash-Manipulate That State? | |-------------------|-----------------|---------------------------|-------------------------------------------| | {DEX/pool/vault} | {swap/deposit/query} | {reserves, price, balance} | {YES if spot state / NO if TWAP or time-weighted} |

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 from AMM) 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:

| Pool | Liquidity (USD) | Target Price Change | Est. Trade Size | Slippage Cost | Protocol Extractable Value | Profitable? | |------|----------------|--------------------:|----------------|--------------|---------------------------|-------------| | {pool} | {TVL} | {%} | {USD} | {USD} | {USD} | {YES/NO} |

**For Aptos AMMs**: Most use constant-product (xy=k) or stableswap curves. Identify the specific AMM type from the protocol's swap function signatures (weighted pools, stableswap, or standard xy=k). <!-- 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:

| State Variable / Query | Location | Read By | Write Path | Flash-Accessible? | Manipulation Cost | |------------------------|----------|---------|------------|-------------------|-------------------| | `fungible_asset::balance(store)` | {module} | {functions} | Direct deposit to store | YES if store accepts | 0 (unsolicited) | | `coin::balance<T>(addr)` | {module} | {functions} | Direct `coin::deposit` | YES if CoinStore exists | 0 (unsolicited) | | Pool reserves | {pool module} | {functions} | Swap on pool | YES | Slippage cost | | Oracle spot price | {oracle} | {functions} | Trade on source DEX | YES | Market depth | | Threshold/quorum state | {module} | {functions} | Deposit/stake | YES | Threshold amount |

**Aptos flash loan mechanics (hot potato pattern)**:

• Flash loan providers (Thala, Echelon, etc.) issue a `FlashLoanReceipt` struct with NO abilities (no `copy`, no `drop`, no `store`, no `key`)
• The receipt MUST be consumed by `repay()` in the same transaction -- Move's type system enforces this
• No callback mechanism: caller receives receipt, performs operations, then passes receipt to repay
• The receipt struct often contains the borrowed amount for repayment validation

**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 {CoinType/FA} from {source}
   -> Receive FlashLoanReceipt (hot potato, no abilities)
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 before repayment)
6. REPAY: Call repay() with FlashLoanReceipt + {amount + fee}
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 entry function)?
• [ ] Does any step abort under normal conditions?
• [ ] Is the manipulation detectable/preventable by the protocol?
• [ ] What is the minimum flash loan amount needed?
• [ ] Does the hot potato receipt constrain the call sequence? (receipt must be threaded through all calls)

3. Cross-Function Flash Loan Chains

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

| Step | Function Called | State Before | State After | Enables Next Step? | |------|---------------|-------------|------------|-------------------| | 1 | {function_A} | {state} | {state'} | YES -- changes {X} | | 2 | {function_B} | {state'} | {state''} | YES -- enables {Y} | | N | {function_N} | {state^N