Architecture

How VAEA Flash works under the hood — the sandwich pattern, program accounts, multi-protocol routing, and security guarantees.

Sandwich Pattern

Every VAEA Flash loan is a single atomic Solana transaction. Your instructions are sandwiched between a begin_flash (borrow) and end_flash (repay) instruction.

text

┌──────────────────────────────────────────────────┐
│                Solana Transaction                 │
│                                                   │
│  IX 1:  begin_flash(SOL, 1000)                    │
│         → Transfer 1000 SOL from vault to wallet  │
│                                                   │
│  IX 2:  your_arbitrage_ix()                       │
│  IX 3:  your_swap_ix()                            │
│  IX 4:  ... (any number of instructions)          │
│                                                   │
│  IX N:  end_flash(SOL)                            │
│         → Transfer SOL + fee (2 bps) back to vault  │
│         → If insufficient balance → TX REVERTS    │
└──────────────────────────────────────────────────┘

ℹ️ Note

The atomicity guarantee means you can never end up in a state where you borrowed tokens but failed to repay. Either everything succeeds, or nothing happens. You only lose the base TX fee (~0.000005 SOL) on failure.

Program Accounts (PDAs)

The on-chain program uses Program Derived Addresses (PDAs) to manage state:

Account	PDA Seeds	Purpose
Flash Vault	`["flash", token_mint]`	Holds borrowed tokens during the transaction
User State	`["flash", payer, token_mint]`	Tracks the active loan for a specific user/token pair
Config	`["config"]`	Global protocol configuration (fee rates, authority)

💡 Tip

The SDK derives all PDAs automatically. You never need to compute them manually — executeLocal() handles everything.

Multi-Protocol Routing

VAEA Flash doesn't hold any liquidity. It routes borrows through existing lending protocols with automatic fallback:

text

Your Request: "Borrow 1000 mSOL"
       ↓
VAEA Router:
  1. Check Marginfi   → has mSOL?  → NO
  2. Check Kamino     → has mSOL?  → NO
  3. Check Jupiter Lend → has mSOL?  → NO
  4. No direct route  → Synthetic:
     → Borrow SOL from Marginfi (deepest pool)
     → Swap SOL → mSOL via Sanctum (~0.03% slippage)
     → You get mSOL ✓

Protocol	Role	Tokens Served
Marginfi	Primary lender	SOL, USDC, USDT, JupSOL, JitoSOL, JUP
Kamino	Fallback	SOL, USDC, cbBTC, JLP
Jupiter Lend	Third source	SOL, USDC, USDT + 35 others

Address Lookup Tables

VAEA uses a pre-deployed Address Lookup Table (ALT) to compress transactions — saving ~124 bytes per TX. Since Solana transactions are limited to 1232 bytes, this leaves maximum room for your instructions.

typescript

import { VAEA_LOOKUP_TABLE } from '@vaea/flash';
// DjncKSi9KqtnFx6hFYa7ARmwJ7B4Y7UH3XpR2XEuXNJr

// The ALT contains 4 fixed accounts:
// [0] Config PDA           — 27qrSQk6xUGtdMQmMobsQWCSts67jtXqA2gZzPK1wubQ
// [1] Fee Vault PDA        — BQNpRH1kahoFqxu5tiZaQYuKb7p41o3cmyXrFWsDmYPn
// [2] Sysvar Instructions  — Sysvar1nstructions1111111111111111111111111
// [3] System Program       — 11111111111111111111111111111111

// Auto-used by execute() / executeLocal() — zero config
// Fetched once and cached for the lifetime of the VaeaFlash instance

Security Model

Security Feature	Detail
Instruction introspection	`begin_flash` ↔ `end_flash` pairing verified within the same TX via sysvar
Atomicity	If repay fails, entire TX reverts — no partial execution possible
Non-custodial	Tokens flow: lending protocol → you → lending protocol. VAEA never holds funds
Permissionless	Anyone can use — no KYC, no registration, no approval needed
Fee floor	Minimum 1 lamport fee prevents micro-loan evasion
Cross-token isolation	PDA seeds include token_mint — prevents collisions in multi-token flash
Zero data retention	No database. On-chain state reads only. Zero user data stored