Flash loans break the most basic assumption in lending - that a borrower needs collateral or creditworthiness. They allow anyone to borrow millions of dollars, uncollateralized, with zero risk to the lender. That sounds like it shouldn't work, but it does. Thanks to transaction atomicity, the loan is issued and repaid within a single transaction. On Ethereum, they rely on a callback pattern that has been the root cause of hundreds of millions in exploits. Solana takes a fundamentally different approach. Its instruction introspection model eliminates entire categories of vulnerabilities by allowing programs to verify repayment before releasing funds. This article breaks down how that mechanism works at the code level, what it means for protocol security, and why it matters for the future of DeFi lending. hundreds of millions in exploits before What Flash Loans Actually Do (And Why They Exist) A flash loan lets a user borrow tokens without collateral, use them within the same transaction, and repay with a fee, all atomically. If any step fails, the entire transaction reverts. If it succeeds, the lender loses nothing, and the borrower gains access to capital they never had. The use cases are well-documented: arbitrage across DEXs, collateral swaps on lending protocols, and liquidation assistance. According to Trading View, Aave’s V3 protocol has processed billions in flash loan volume. The mechanism works because blockchain transactions are atomic - they either fully succeed or fully revert. arbitrage across DEXs Trading View But the implementation of that atomicity guarantee varies dramatically between chains. And that difference has serious security implications. implementation Ethereum's Callback Pattern: Power With a Price On Ethereum, flash loans use a callback pattern. The lender contract calls a function on the borrower's contract, transfers the tokens, waits for the borrower to perform the requested action, and then verifies that the balance has been restored. Here's the simplified flow: Lender.flashLoan() → Borrower.executeOperation() → Lender checks balance Lender.flashLoan() → Borrower.executeOperation() → Lender checks balance This works. But it introduces reentrancy as a structural risk. The borrower's contract executes arbitrary code within the context of the lender's transaction. Every DeFi developer knows the consequences. From the 2020 bZx attacks that drained $8.1 million to the 2023 Euler Finance exploit that cost $200 million. In both cases, the callback execution model gave attackers a window to manipulate state between the loan disbursement and the balance/liquidity check. within the context of the lender's transaction 2020 bZx attacks $200 million Ethereum developers mitigate this with reentrancy guards, checks-effects-interactions patterns, and careful state management. But these are developer-imposed safeguards. The protocol architecture does not prevent reentrancy by default. developer-imposed Solana's Instruction Introspection: A Different Architecture Solana's transaction model is structurally different. A transaction contains an ordered list of instructions, and Solana exposes a special account known as the Instructions Sysvar, which lets any instruction inspect every other instruction in the same transaction, including ones that haven't executed yet. Instructions Sysvar This means a flash loan program on Solana can verify repayment before disbursing funds. There is no callback. There is no reentrancy window. The borrow instruction literally reads ahead in the transaction to confirm that a valid repay instruction exists at the end. before disbursing funds Here is how that looks in practice, using the Anchor framework: Anchor framework let ixs = ctx.accounts.instructions.to_account_info();

// Ensure borrow is the first instruction
let current_index = load_current_index_checked(&ctx.accounts.instructions)?;
require_eq!(current_index, 0, ProtocolError::InvalidIx);

// Read total instruction count from the sysvar
let instruction_sysvar = ixs.try_borrow_data()?;
let len = u16::from_le_bytes(instruction_sysvar[0..2].try_into().unwrap());
drop(instruction_sysvar); // Must drop borrow before loading instructions

// Verify the last instruction is a valid repay
if let Ok(repay_ix) = load_instruction_at_checked(len as usize - 1, &ixs) {
    require_keys_eq!(repay_ix.program_id, crate::ID, ProtocolError::InvalidProgram);
    require!(repay_ix.data.len() >= 8, ProtocolError::InvalidIx);
    require_keys_eq!(
        repay_ix.accounts.get(3).ok_or(ProtocolError::InvalidBorrowerAta)?.pubkey,
        ctx.accounts.borrower_ata.key(),
        ProtocolError::InvalidBorrowerAta
    );
    require_keys_eq!(
        repay_ix.accounts.get(4).ok_or(ProtocolError::InvalidProtocolAta)?.pubkey,
        ctx.accounts.protocol_ata.key(),
        ProtocolError::InvalidProtocolAta
    );
} else {
    return Err(ProtocolError::MissingRepayIx.into());
} let ixs = ctx.accounts.instructions.to_account_info();

// Ensure borrow is the first instruction
let current_index = load_current_index_checked(&ctx.accounts.instructions)?;
require_eq!(current_index, 0, ProtocolError::InvalidIx);

// Read total instruction count from the sysvar
let instruction_sysvar = ixs.try_borrow_data()?;
let len = u16::from_le_bytes(instruction_sysvar[0..2].try_into().unwrap());
drop(instruction_sysvar); // Must drop borrow before loading instructions

// Verify the last instruction is a valid repay
if let Ok(repay_ix) = load_instruction_at_checked(len as usize - 1, &ixs) {
    require_keys_eq!(repay_ix.program_id, crate::ID, ProtocolError::InvalidProgram);
    require!(repay_ix.data.len() >= 8, ProtocolError::InvalidIx);
    require_keys_eq!(
        repay_ix.accounts.get(3).ok_or(ProtocolError::InvalidBorrowerAta)?.pubkey,
        ctx.accounts.borrower_ata.key(),
        ProtocolError::InvalidBorrowerAta
    );
    require_keys_eq!(
        repay_ix.accounts.get(4).ok_or(ProtocolError::InvalidProtocolAta)?.pubkey,
        ctx.accounts.protocol_ata.key(),
        ProtocolError::InvalidProtocolAta
    );
} else {
    return Err(ProtocolError::MissingRepayIx.into());
} Three things are happening here that have no equivalent in Ethereum flash loans: 1. Position enforcement. The borrow must be instruction index 0. The repayment must be the last instruction. This creates a deterministic transaction structure that the program can reason about. 1. Position enforcement. 2. Forward-looking validation. load_instruction_at_checked() reads instructions that haven't been executed yet. The program verifies repayment will happen before transferring a single token. 2. Forward-looking validation. load_instruction_at_checked() 3. Account-level integrity checks. The program validates that the repayment instruction targets the exact same token accounts (borrower ATA at index 3, protocol ATA at index 4). This prevents a class of attack where a malicious reply instruction targets different accounts. 3. Account-level integrity checks. The Repay Side: Cross-Instruction Data Extraction The repay instruction demonstrates another powerful aspect of instruction introspection by reading data from other instructions in the same transaction: let ixs = ctx.accounts.instructions.to_account_info();

let amount_borrowed = if let Ok(borrow_ix) = load_instruction_at_checked(0, &ixs) {
    let mut borrowed_data: [u8; 8] = [0u8; 8];
    borrowed_data.copy_from_slice(&borrow_ix.data[8..16]);
    u64::from_le_bytes(borrowed_data)
} else {
    return Err(ProtocolError::MissingBorrowIx.into());
};

// 5% fee: 500 basis points
let fee = (amount_borrowed as u128)
    .checked_mul(500)
    .unwrap()
    .checked_div(10_000)
    .ok_or(ProtocolError::Overflow)? as u64;

let repay_amount = amount_borrowed
    .checked_add(fee)
    .ok_or(ProtocolError::Overflow)?; let ixs = ctx.accounts.instructions.to_account_info();

let amount_borrowed = if let Ok(borrow_ix) = load_instruction_at_checked(0, &ixs) {
    let mut borrowed_data: [u8; 8] = [0u8; 8];
    borrowed_data.copy_from_slice(&borrow_ix.data[8..16]);
    u64::from_le_bytes(borrowed_data)
} else {
    return Err(ProtocolError::MissingBorrowIx.into());
};

// 5% fee: 500 basis points
let fee = (amount_borrowed as u128)
    .checked_mul(500)
    .unwrap()
    .checked_div(10_000)
    .ok_or(ProtocolError::Overflow)? as u64;

let repay_amount = amount_borrowed
    .checked_add(fee)
    .ok_or(ProtocolError::Overflow)?; The repay instruction reads the borrow instruction's serialized data (skipping the 8-byte Anchor discriminator) to extract the exact borrowed amount. No on-chain state storage needed. No contract storage slots. The instruction data is the state. is This is significant because it eliminates an entire category of storage manipulation attacks. On Ethereum, a flash loan contract must write the borrowed amount to storage and then read it back later. Between those two operations, a reentrancy attack could modify that stored value. On Solana, the data is embedded in the transaction itself and cannot be altered after submission. The Account Model: Why PDAs Replace Access Control Lists Solana programs don't have internal storage like Ethereum contracts. Instead, they operate on explicitly passed accounts. The protocol's liquidity pool lives in a token account owned by a Program Derived Address (PDA): #[account(
    seeds = [b"protocol".as_ref()],
    bump,
)]
pub protocol: SystemAccount<'info>, #[account(
    seeds = [b"protocol".as_ref()],
    bump,
)]
pub protocol: SystemAccount<'info>, A PDA is a deterministic address derived from the program's ID and a set of seeds. Only the owning program can sign transactions on behalf of this address. This means the protocol's funds are cryptographically locked to the program's logic. There’s no admin key, no multisig, no external access. When the borrow instruction transfers tokens, it uses PDA signing: let seeds = &[b"protocol".as_ref(), &[ctx.bumps.protocol]];
let signer_seeds = &[&seeds[..]];

transfer(
    CpiContext::new_with_signer(
        ctx.accounts.token_program.to_account_info(),
        Transfer {
            from: ctx.accounts.protocol_ata.to_account_info(),
            to: ctx.accounts.borrower_ata.to_account_info(),
            authority: ctx.accounts.protocol.to_account_info(),
        },
        signer_seeds
    ),
    borrow_amount
)?; let seeds = &[b"protocol".as_ref(), &[ctx.bumps.protocol]];
let signer_seeds = &[&seeds[..]];

transfer(
    CpiContext::new_with_signer(
        ctx.accounts.token_program.to_account_info(),
        Transfer {
            from: ctx.accounts.protocol_ata.to_account_info(),
            to: ctx.accounts.borrower_ata.to_account_info(),
            authority: ctx.accounts.protocol.to_account_info(),
        },
        signer_seeds
    ),
    borrow_amount
)?; The authority over the protocol's token account is the PDA itself. The program reconstructs the signing seeds at runtime and passes them to the SPL Token program. No private key exists for this account. The funds can only move according to the program's validated logic. A Subtle but Critical Detail: Rust's Borrow Checker as a Security Feature There is a detail in the borrow instruction that is easy to overlook but architecturally important: let instruction_sysvar = ixs.try_borrow_data()?;
let len = u16::from_le_bytes(instruction_sysvar[0..2].try_into().unwrap());
drop(instruction_sysvar); // Explicit drop required let instruction_sysvar = ixs.try_borrow_data()?;
let len = u16::from_le_bytes(instruction_sysvar[0..2].try_into().unwrap());
drop(instruction_sysvar); // Explicit drop required The drop(instruction_sysvar) is not optional. Solana's load_instruction_at_checked() needs to borrow the instructions account data internally. If a previous borrow is still active, the Rust compiler will refuse to compile, and the runtime will panic if the borrow is held through RefCell. drop(instruction_sysvar) load_instruction_at_checked() RefCell This is Rust's ownership model functioning as a security layer. In C or Solidity, this kind of concurrent data access would compile silently and potentially cause undefined behavior or exploitable state inconsistencies. Rust makes it a compile-time error. For Solana program developers, this means: scope your borrows deliberately. Read what you need, extract it into local variables, and drop the borrow before calling functions that need the same underlying data. The compiler is enforcing a correctness guarantee that other languages leave to the developer's discipline. scope your borrows deliberately. Comparing the Security Models Property

Ethereum (Callback)

Solana (Introspection)



Reentrancy risk

Structural - requires guards

Eliminated by design



State manipulation window

Between loan and check

None - verified before disbursement



Repayment verification

Post-execution balance check

Pre-execution instruction validation



Storage attack surface

Contract storage slots

No mutable state - data in transaction



Fund custody

Contract-held, admin key possible

PDA-held, no external keys



Developer burden

Must implement safety patterns

Architecture provides guarantees Property

Ethereum (Callback)

Solana (Introspection)



Reentrancy risk

Structural - requires guards

Eliminated by design



State manipulation window

Between loan and check

None - verified before disbursement



Repayment verification

Post-execution balance check

Pre-execution instruction validation



Storage attack surface

Contract storage slots

No mutable state - data in transaction



Fund custody

Contract-held, admin key possible

PDA-held, no external keys



Developer burden

Must implement safety patterns

Architecture provides guarantees Property

Ethereum (Callback)

Solana (Introspection) Property Property Ethereum (Callback) Ethereum (Callback) Solana (Introspection) Solana (Introspection) Reentrancy risk

Structural - requires guards

Eliminated by design Reentrancy risk Reentrancy risk Structural - requires guards Structural - requires guards Eliminated by design Eliminated by design State manipulation window

Between loan and check

None - verified before disbursement State manipulation window State manipulation window Between loan and check Between loan and check None - verified before disbursement None - verified before disbursement Repayment verification

Post-execution balance check

Pre-execution instruction validation Repayment verification Repayment verification Post-execution balance check Post-execution balance check Pre-execution instruction validation Pre-execution instruction validation Storage attack surface

Contract storage slots

No mutable state - data in transaction Storage attack surface Storage attack surface Contract storage slots Contract storage slots No mutable state - data in transaction No mutable state - data in transaction Fund custody

Contract-held, admin key possible

PDA-held, no external keys Fund custody Fund custody Contract-held, admin key possible Contract-held, admin key possible PDA-held, no external keys PDA-held, no external keys Developer burden

Must implement safety patterns

Architecture provides guarantees Developer burden Developer burden Must implement safety patterns Must implement safety patterns Architecture provides guarantees Architecture provides guarantees This is not to say Solana flash loans are invulnerable. Oracle manipulation, economic attacks, and logic bugs remain possible regardless of the chain. But the structural vulnerability of the callback pattern - the reentrancy window - does not exist in the introspection model. structural What This Means for DeFi Protocol Designers Instruction introspection is not limited to flash loans. The same pattern can enforce: Atomic multi-step DeFi operations. A swap aggregator can verify that all legs of a multi-hop trade are present before executing the first leg.
Sandwich attack protection. A program can verify that no unexpected instructions are inserted between its own instructions in a transaction.
Conditional execution. A program can check whether specific instructions from other programs are present, enabling composable protocol interactions with built-in safety checks. Atomic multi-step DeFi operations. A swap aggregator can verify that all legs of a multi-hop trade are present before executing the first leg. Atomic multi-step DeFi operations. Sandwich attack protection. A program can verify that no unexpected instructions are inserted between its own instructions in a transaction. Sandwich attack protection. Conditional execution. A program can check whether specific instructions from other programs are present, enabling composable protocol interactions with built-in safety checks. Conditional execution. The Solana Cookbook documents several of these patterns. For protocol architects considering Solana, instruction introspection is arguably the most underappreciated security primitive available. Solana Cookbook Limitations of This Implementation This implementation is educational, not production-grade. Several gaps remain: No liquidity management. There is no initialization instruction to fund the protocol. A production system needs deposit/withdrawal mechanisms and utilization tracking. No liquidity management. Fixed fee model. The hardcoded 5% fee (500 basis points) does not respond to market conditions. Production flash loan protocols like Solend and MarginFi use dynamic fee curves based on pool utilization. Fixed fee model. Solend MarginFi No governance. Fee adjustments, emergency pauses, and protocol upgrades require a governance mechanism, even if they’re a multisig, DAO, or timelocked admin. No governance. Single-token support. The protocol handles one token at a time. Multi-token pools with cross-asset flash loans are standard in production DeFi. Single-token support. Minimal test coverage. The test suite does not exercise the core borrow/repay flow. Production deployment requires comprehensive testing, including edge cases, overflow scenarios, and adversarial transaction construction. Minimal test coverage. Conclusion Solana's instruction introspection model represents a genuine architectural improvement over Ethereum's callback pattern for flash loan implementation. By allowing programs to verify future instructions before executing, it eliminates the reentrancy window that has been the root cause of the most damaging DeFi exploits. Combined with PDA-based fund custody and Rust's ownership guarantees, it produces flash loan protocols that are secure by construction rather than by convention. Overall, the core insight that security can be built into the transaction model rather than bolted on through developer discipline extends well beyond flash loans and into the broader design space of on-chain financial protocols.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Aave

Ethereum

How Instruction Introspection Makes Solana Flash Loans Structurally Safer Than Ethereum’s

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Why On-Chain IP Registration Still Takes 30 Minutes (And How a State Machine Fixes It)

4 Common Crypto Scams and How to Detect Them

A Beginner’s Guide to Web3.0 Security

Are Your Crypto Wallet Keys Really Safe?

Cybersecurity in Web3: How to Jump on the Bandwagon Safely

David Schwed of Halborn Explores the Culture and Mechanics of Web3 Security

Why On-Chain IP Registration Still Takes 30 Minutes (And How a State Machine Fixes It)

4 Common Crypto Scams and How to Detect Them

A Beginner’s Guide to Web3.0 Security

Are Your Crypto Wallet Keys Really Safe?

Cybersecurity in Web3: How to Jump on the Bandwagon Safely

David Schwed of Halborn Explores the Culture and Mechanics of Web3 Security

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps