plamentsv/flash-loan-interaction

FLASH_LOAN_INTERACTION Skill (Solana)

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

Key Solana difference: There is no callback model. Flash loans work via instruction composition in a single transaction. The attack pattern is: IX1 borrow -> IX2 manipulate -> IX3 exploit -> IX4 repay - all sequential instructions in one transaction.

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 programs the protocol CPIs to have state manipulable by a third party within the same transaction.

0a: External Interaction Inventory

| External Program | Interaction Type | State Read by Our Program | Can 3rd Party Manipulate That State in Same Tx? | |------------------|-----------------|---------------------------|------------------------------------------------| | {DEX/AMM/vault} | {swap/deposit/price query} | {reserves, price, balance} | {YES if spot state / NO if TWAP or slot-gated} |

0b: Third-Party Flash Attack Modeling (Instruction Composition)

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

1. IX1 - BORROW: Flash-borrow via lending program instruction
2. IX2 - MANIPULATE: Instruction to external program that changes state X (e.g., swap to move pool reserves)
3. IX3 - VICTIM CALL: Instruction to OUR program that reads manipulated state X
4. IX4 - RESTORE: Instruction to reverse external manipulation (reverse swap)
5. IX5 - REPAY: Instruction to repay flash loan
6. IMPACT: What did the attacker gain from our program acting on manipulated state?

Key question: Does our program use spot state (manipulable within tx) or time-weighted/slot-gated state (resistant)?

<!-- LOAD_IF: DEX_INTERACTION -->

0c: DEX Price Manipulation Cost Estimation

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

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

Cost formula: manipulation_cost = slippage * trade_size. If manipulation_cost < extractable_value -> VIABLE.

<!-- END_LOAD_IF: DEX_INTERACTION -->

1. Flash-Loan-Accessible State Inventory

Enumerate ALL program state that can be manipulated within a single transaction via flash-borrowed capital or instruction composition:

| State Variable / Account | Location | Read By | Write Path | Flash-Accessible? | Manipulation Cost | |--------------------------|----------|---------|------------|-------------------|-------------------| | token_account.amount | {account} | {instructions} | SPL transfer (anyone) | YES | 0 (unsolicited) | | vault.total_value | {PDA} | {instructions} | deposit instruction | YES if permissionless | Deposit amount | | AMM pool reserves | {pool account} | {instructions} | Swap instruction | YES | Slippage cost | | Oracle price account | {oracle PDA} | {instructions} | Oracle update IX | YES if same-slot | Market depth | | Threshold/quorum state | {governance PDA} | {instructions} | Stake/vote IX | YES | Threshold amount |

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

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

2. Atomic Attack Sequence Modeling (Instruction Composition)

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

Attack Template (Solana Transaction with Multiple Instructions)

TX containing ordered instructions:
  IX1 - BORROW:     Flash-borrow {amount} of {token} from {lending program}
  IX2 - MANIPULATE:  {action} to change {state_variable} from {value_before} to {value_after}
  IX3 - CALL:        Invoke {target_instruction} on our program which reads manipulated state
  IX4 - EXTRACT:     {what_is_gained} - quantify: {amount}
  IX5 - RESTORE:     {action} to return state (if needed for repayment)
  IX6 - REPAY:       Return {amount + fee} to flash loan source

  PROFIT: {extract - fee - tx_fee} = {net_profit}

Profitability gate: If net_profit <= 0 for all realistic amounts -> document as NON-PROFITABLE but check Step 3 for multi-instruction chains.

For each sequence, verify:

• [ ] Can IX2-IX5 execute atomically in one transaction?
• [ ] Does any instruction fail under normal conditions?
• [ ] Is the manipulation detectable/preventable by the program?
• [ ] What is the minimum flash loan amount needed?
• [ ] Does compute unit budget allow the full sequence?

3. Cross-Instruction Flash Loan Chains

Model multi-instruction atomic sequences within a single transaction:

| Step | Instruction | State Before | State After | Enables Next Step? | |------|-------------|-------------|------------|-------------------| | IX1 | {program_A.instruction_X} | {state} | {state'} | YES - changes {X} | | IX2 | {program_B.instruction_Y} | {state'} | {state''} | YES - enables {Y} | | IXN | {program_N.instruction_Z} | {state^N} | {final} | EXTRACT profit |

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

Common multi-instruction patterns: Deposit->manipulate oracle->withdraw, stake->trigger reward->unstake, transfer to inflate balance->price-dependent IX->transfer back, multiple CPIs with state mutation between.

3b. Flash-Loan-Enabled Debounce DoS

For each permissionless instruction with a cooldown affecting OTHER users (epoch/slot/global timestamp): can attacker compose borrow->debounced IX->trigger cooldown, blocking legitimate callers?

| Instruction | Cooldown Scope | Shared Across Users? | Flash-Triggerable? | DoS Duration | |-------------|---------------|---------------------|-------------------|-------------|

If global/shared AND permissionless AND flash-triggerable -> FINDING (R2, minimum Medium). Solana-specific: Clock::get()?.slot/epoch cooldowns shorter than 1 slot are ineffective against same-slot composition.

3c. No-Op Resource Consumption

For each state-modifying instruction 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?

| Instruction | Resource Consumed | No-Op Parameters | Resource Wasted? | Impact | |-------------|------------------|-----------------|-----------------|--------|

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

3d. External Flash x Debounce Cross-Reference (MANDATORY)

For EACH external program flagged as flash-susceptible in Section 0:

| External Program | Flash-Accessible Action | Debounce/Cooldown Affected (from 3b) | Combined Severity | |------------------|------------------------|--------------------------------------|-------------------|

If YES: (1) permanent or temporary consumption? (2) on-chain reset path? (3) combined severity = HIGHER of the two. Tag: [TRACE:flash({external})->ix({debounce_fn})->cooldown consumed->{duration}]. If no debounce from 3b: N/A.

<!-- LOAD_IF: BALANCE_DEPENDENT -->

4. Flash Loan + Donation Compound Attacks

Combine flash loan capital with unsolicited SPL/SOL transfers:

| Donation Target | Flash Loan Action | Combined Effect | Profitable? | |-----------------|-------------------|-----------------|-------------| | vault token_account.amount | Deposit/withdraw | Rate manipulation | {YES/NO} | | AMM pool token account | Swap | Price oracle manipulation | {YES/NO} | | governance staking account | Vote/propose | Quorum manipulation | {YES/NO} |

Check: Can a flash-borrowed amount be transferred (not deposited) to the protocol's token account to manipulate token_account.amount accounting, and then extracted via a subsequent instruction within the same transaction?

Solana-specific: Unsolicited SPL transfers are trivially cheap (no function call needed on receiver side). Anyone who knows the token account address can transfer tokens to it.

<!-- END_LOAD_IF: BALANCE_DEPENDENT -->

5. Flash Loan Defense Audit

For each flash-loan-accessible attack path identified:

| Defense | Present? | Effective? | Bypass? | |---------|----------|------------|---------| | Anchor reentrancy guard (#[access_control]) | YES/NO | {analysis} | {if YES: how} | | Same-slot prevention (last_slot check) | YES/NO | {analysis} | Multi-slot possible? | | TWAP instead of spot price | YES/NO | TWAP window length: {N slots} | Short TWAP vulnerable? | | Epoch-based cooldown | YES/NO | Duration: {N epochs} | Bypass via epoch boundary? | | Balance snapshot (pre/post CPI comparison) | YES/NO | {analysis} | {if YES: how} | | Flash loan fee exceeds profit | YES/NO | Fee: {X}, max profit: {Y} | Fee < profit? | | Instruction introspection (sysvar check) | YES/NO | Checks for: {what} | Spoofable? |

Solana-specific defenses: Clock::get()?.slot comparison, instruction sysvar introspection (detect flash loan IX in tx), CPI depth limits (max 4), compute unit limits as implicit protection.

5b. Defense Parity Audit (Cross-Instruction)

For each user-facing action in multiple instructions or program versions:

| Action | Instruction A | Flash Defense | Instruction B | Flash Defense | Parity? | |--------|--------------|---------------|--------------|---------------|---------| | {action} | {ix_name} | {defense list} | {ix_name} | {defense list} | {GAP if different} |

Key question: If deposit has a slot-based cooldown but deposit_v2 has NONE for the same economic action -- can attacker use deposit_v2 as the undefended path? For each GAP: can undefended IX achieve same outcome? Does defended IX's protection become meaningless? Intentional or accidental?

Finding Template

**ID**: [FL-N]
**Severity**: [based on profitability and fund impact]
**Step Execution**: S0,1,2,3,4,5 | X(reasons) | ?(uncertain)
**Rules Applied**: [R2:Y, R4:Y, R10:Y, R15:Y]
**Location**: programs/vault/src/instructions/file.rs:LineN
**Title**: Instruction composition enables [manipulation] via [mechanism]
**Description**: [Full atomic instruction sequence with amounts]
**Impact**: [Quantified profit/loss with realistic flash loan amounts]

---

Step Execution Checklist (MANDATORY)

| Section | Required | Completed? | Notes | |---------|----------|------------|-------| | 0. External Flash Susceptibility Check | YES | Y/X/? | For each external program interaction | | 1. Flash-Loan-Accessible State Inventory | YES | Y/X/? | | | 2. Atomic Attack Sequence Modeling | YES | Y/X/? | For each accessible state | | 3. Cross-Instruction Flash Loan Chains | YES | Y/X/? | | | 3b. Flash-Loan-Enabled Debounce DoS | YES | Y/X/? | Shared cooldown instructions | | 3c. No-Op Resource Consumption | YES | Y/X/? | Zero-effect calls consuming resources | | 3d. External Flash x Debounce Cross-Ref | YES | Y/X/? | Cross-reference 0 x 3b | | 4. Flash Loan + Donation Compounds | IF BALANCE_DEPENDENT | Y/X(N/A)/? | | | 5. Flash Loan Defense Audit | YES | Y/X/? | For each attack path | | 5b. Defense Parity Audit | YES | Y/X/? | For each action in multiple instructions |