ProtocolConcepts
Flash Trade v2 uses the same trading mechanics as v1 (pool-to-peer, oracle pricing, leverage, fees, TP/SL, limit orders). What changes for an integrator is where positions are stored and how funds move in and out. This page covers the v2-specific concepts you need before calling the API.
Two Kinds of Calls
The v2 API has two groups of endpoints:
Account & funds endpoints (
init-*,deposit-direct,delegate-basket,request-withdrawal,execute-withdrawal) — set up your wallet and move collateral in and out.Trading endpoints — open, close, and manage positions and orders (fast and gasless).
Each returns an unsigned transaction you sign and submit. The two groups submit to different RPC endpoints — see TransactionFlow.
Key Entities
Basket
The defining difference from v1. Each wallet has a single Basket PDA that holds all of its v2 positions and orders — one position per market. There are no standalone Position or Order accounts.
Because of this, the API identifies a position by a friendly tuple — (owner, marketSymbol, side) — and resolves the underlying market pubkey internally. Each market is one side (long and short are separate markets), so a wallet can hold one long and one short per symbol, and (marketSymbol, side) is always unambiguous.
The basket must be delegated before trading. The snapshot and WebSocket endpoints return the basket's positions and orders already decoded as positionMetrics / orderMetrics (UI-ready strings) — use those directly. The raw basket bytes are also included (base64) for clients that prefer to decode native PositionMeta[] / OrderMeta[] with the v2 client SDK.
Deposit Ledger
A per-owner PDA that tracks a wallet's deposited balances available as collateral. Funds enter via deposit-direct and are drawn down when opening positions / adding collateral.
Custody & Platform Vault
As in v1, each token has a custody that holds pooled liquidity. v2 additionally uses a platform vault per mint (the token account that deposits land in and withdrawals are paid from) and a custody settlement receipt used to reconcile custody ↔ vault balances during withdrawals (see Withdrawal Lifecycle).
Market
Same as v1: a (target custody, lock/collateral custody, side) triple. The backend resolves market pubkeys from marketSymbol + side against the live pool config.
Account Lifecycle
A wallet must be set up once before it can trade:
See TransactionFlow for the full request/response sequence.
Delegation
delegate-basket is a one-time step that enables trading on your basket.
Withdrawals
Withdrawals happen in two steps:
request-withdrawal— starts the withdrawal and idempotently creates the owner's receiving ATA.Funds are released automatically into the owner's ATA. Poll until the withdrawal escrow account closes — that means the withdrawal completed.
If the withdrawal doesn't complete automatically, execute-withdrawal finishes it in a single transaction (optionally including the custody settlement via includeCustodySettlement).
For SOL, the receiving token is WSOL; unwrap the WSOL ATA back to native SOL after the withdrawal completes.
Pricing & Markets
v2 uses the same Pyth Lazer feeds as v1, filtered to the tokens in the v2 pool config — notably equity tokens (e.g. SPY, MSTR, CRCL) that trade on market hours. The /v2/prices payload includes a marketSession field so clients can reflect open/closed equity sessions.
Program IDs
v2 program (mainnet)
FTv2RxXarPfNta45HTTMVaGvjzsGg27FXJ3hEKWBhrzV
v2 program (devnet)
FMTgsEDaPPfJi1PKD67McLTC5n833T4irbBP53LLxtvj
Differences from v1 at a Glance
Position storage
Standalone Position accounts
Stored in a per-owner Basket (one per market)
Order storage
Standalone Order accounts
Stored in the Basket
Position identity
Position PDA / raw keys
(owner, marketSymbol, side) tuple
Funds movement
Direct
deposit → delegate → trade → withdraw lifecycle
Swaps
Supported (SWAP)
Not supported
Streaming
positions + orders messages
basket + metrics messages (decode basket bytes)
Last updated
Was this helpful?