Overview
Flash loans allow you to borrow liquidity from Kamino Lending reserves without collateral, provided you repay the loan plus fees within the same transaction. This enables atomic arbitrage, liquidations, collateral swaps, and other advanced DeFi strategies.How Flash Loans Work
Atomicity Requirement
Flash loans must be borrowed and repaid in the same Solana transaction. The protocol validates that:- A
flash_repay_reserve_liquidityinstruction follows theflash_borrow_reserve_liquidityinstruction - Both instructions reference the same reserve
- The repay amount matches the borrow amount
- All accounts match between borrow and repay instructions
lending_market/flash_ixs.rs:18-187.
Instructions
1. Flash Borrow Reserve Liquidity
Handler:handler_flash_borrow_reserve_liquidity.rs:12
Borrows liquidity from a reserve without collateral.
liquidity_amount: Amount to borrow (in token’s smallest unit)
- Flash loans must not be called via CPI (
flash_ixs.rs:92) - A matching repay instruction must exist in the same transaction (
flash_ixs.rs:138) - Reserve flash loan feature is enabled (not
u64::MAX) (lending_operations.rs:1740) - Reserve has sufficient available liquidity
2. Flash Repay Reserve Liquidity
Handler:handler_flash_repay_reserve_liquidity.rs:12
Repays the borrowed liquidity plus fees.
liquidity_amount: Amount to repay (must match borrow amount)borrow_instruction_index: Index of the flash borrow instruction in the transaction
flash_ixs.rs:27):
- Borrow instruction index must be less than current instruction index
- Referenced instruction must be a valid
flash_borrow_reserve_liquidity - Liquidity amounts must match
- All accounts must match between borrow and repay
Fee Calculation
Flash loan fees are calculated instate/reserve.rs:1712:
- Protocol Fee: Determined by
reserve.config.fees.flash_loan_fee_sf - Referral Fee: If a referrer is provided, a portion of the protocol fee goes to the referrer based on
referral_fee_bps
lending_operations.rs:1805):
flash_loan_amount_with_referral_feeto the reserve supply vaultprotocol_feeto the reserve fee vault
Complete Flash Loan Example
Arbitrage Example
This example borrows USDC, executes an arbitrage trade, and repays the loan:Liquidation with Flash Loan
Borrow assets to perform a liquidation without holding the debt asset:Error Handling
Common Errors
FlashLoansDisabled (lending_operations.rs:1742):
u64::MAX.
InvalidFlashRepay (flash_ixs.rs:50):
Occurs when:
- Borrow instruction index is invalid
- Liquidity amounts don’t match
- Reserve accounts don’t match
- Accounts mismatch between borrow and repay
flash_ixs.rs:139):
flash_ixs.rs:94, flash_ixs.rs:30):
flash_ixs.rs:123):
Repayment Failure Handling
If repayment fails, the entire transaction reverts atomically. Common failure scenarios:- Insufficient funds: User account doesn’t have enough tokens to repay
- Fee calculation error: Slippage causes insufficient tokens after intermediate operations
- Token account issues: Invalid or frozen token accounts
Security Considerations
- CPI Protection: Flash loans cannot be called via CPI to prevent reentrancy attacks
- Single Use: Only one flash borrow per transaction to prevent complex attack vectors
- Atomic Execution: All operations are atomic - if repayment fails, the borrow is reverted
- Account Matching: Strict validation ensures the same accounts are used for borrow and repay
- Fee Enforcement: Fees are always collected, making unprofitable attacks expensive
Tips for Success
- Test thoroughly: Simulate transactions on devnet before mainnet deployment
- Account for slippage: Add buffer to ensure repayment amount after intermediate swaps
- Monitor liquidity: Check reserve available liquidity before attempting large flash loans
- Optimize compute: Flash loan transactions can be complex - optimize compute budget
- Handle referrals: Pass referrer accounts to reduce fees if you have a referral relationship