Security Model

The Zero-CPI verification pattern relies on multiple layers of validation. This page documents each security guarantee and how it prevents specific attack vectors.

Security Guarantees

Property	Mechanism	Attack Prevented
Owner verification	`flash_state.owner == VAEA_PROGRAM_ID`	Forged PDA from another program
PDA derivation	Seeds validated: ["flash", payer, token_mint]	Cross-user or cross-token collision
Instruction introspection	Sysvar scan for begin_flash before + end_flash after	Standalone call without active loan
Slot freshness	slot_created checked against current slot	Replaying a PDA from a prior transaction
Atomicity	If end_flash fails → entire TX reverts	Partial execution / fund extraction
Non-custodial	Tokens flow: protocol → user → protocol	VAEA holding user funds

Can the FlashState PDA Be Forged?

No. On Solana, only a program can modify accounts it owns. The FlashState PDA is owned by the VAEA program (HoYiwkNB7a3gmZXEkTqLkborNDc976vKEUAzBm8YpK5E). A malicious program cannot:

• Create an account owned by the VAEA program — only VAEA can do that
• Modify an existing FlashState's data — only the owner can write
• Set its own program as the owner and fool verify() — the owner check rejects it

Can a FlashState Be Replayed?

No. The FlashState PDA is created by begin_flash and closed by end_flash in the same transaction. After the transaction, the account no longer exists. Even if it could persist:

• The slot_created field would not match the current slot
• The instruction introspection would not find begin_flash / end_flash in the current TX
• Both checks must pass — either one prevents replay

Instruction Introspection

verify() uses the instructions sysvar (Sysvar1nstructions1111111111111111111111111) to scan the current transaction's instruction list. It verifies:

rust

// Pseudocode of what verify() checks internally:

// 1. Find begin_flash BEFORE current instruction index
for (ix_idx = 0; ix_idx < current_ix_idx; ix_idx++) {
    if ix.program_id == VAEA_PROGRAM_ID
       && ix.data starts with BEGIN_DISCRIMINATOR {
        found_begin = true;
        break;
    }
}

// 2. Find end_flash AFTER current instruction index
for (ix_idx = current_ix_idx + 1; ix_idx < total_ixs; ix_idx++) {
    if ix.program_id == VAEA_PROGRAM_ID
       && ix.data starts with END_DISCRIMINATOR {
        found_end = true;
        break;
    }
}

// Both must be true — otherwise verify() returns Err
require!(found_begin && found_end, "No active flash loan");

CPI Depth Comparison

The key advantage of CTX over CPI-based verification:

Scenario	With CPI Verification	With VAEA CTX
Protocol → token_program	2 levels ✅	1 level ✅
Protocol → Jupiter → AMM → token	4 levels ⚠️	3 levels ✅
Proto_A → Proto_B → Jupiter → AMM	5 levels ❌	4 levels ✅

text

// With CPI verification — 1 level consumed:
YourProtocol.execute()
  └→ CPI: FlashLoanProgram.is_active()    ← 1 CPI level gone
  └→ CPI: Jupiter.route()
       └→ CPI: AMM.swap()
            └→ CPI: TokenProgram.transfer() ← Level 4 ⚠️

// With VAEA CTX — 0 levels consumed:
YourProtocol.execute()
  └→ READ: flash_state PDA                ← 0 CPI, just a read
  └→ CPI: Jupiter.route()
       └→ CPI: AMM.swap()
            └→ CPI: TokenProgram.transfer() ← Level 3 ✅

Program Immutability

Post-mainnet, the VAEA on-chain program will have no upgrade authority. Properties:

• No admin key — nobody can pause or modify the program
• No upgrade authority — the bytecode is frozen
• No fee changes — the 2 bps rate is hardcoded in the config PDA
• Fully permissionless — anyone can use it, no registration needed

ℹ️ Note

The VAEA backend (Smart Router, API) is separate from the on-chain program. The verify() flow is fully decentralized — it reads on-chain data only, with no dependency on VAEA servers.