Velocity API documentation

API security: the top priority

In Velocity's model, API keys are your Solana wallet keys: the protocol is non-custodial, and no server ever holds access to your funds. Practical rules: keep the bulk of funds in a cold wallet, run bots on a dedicated low-balance wallet with delegated subaccounts, verify the domain before signing SWIFT messages, and never reuse addresses derived from the halted Drift program.

TypeScript SDK: @velocity-exchange/sdk

The @velocity-exchange/sdk package (version 0.13.x) is a renamed Drift SDK branch with no backward compatibility. Key renames: DriftClient → VelocityClient, DRIFT_PROGRAM_ID → VELOCITY_PROGRAM_ID, DriftEnv → VelocityEnv, and the IDL file drift.json → velocity.json. Under the hood, Anchor was upgraded to @anchor-lang/[email protected] from @coral-xyz/[email protected].

Two migration traps the compiler will not catch: the mainnet quote mint is USDT (read it from getConfig().QUOTE_MINT_ADDRESS — do not hardcode USDC), and the MarketStatus discriminants have shifted — custom raw-byte parsers will silently misclassify market states unless rebuilt.

The velocity-rs Rust client

For system-level integrations and high-performance bots, the monorepo ships the velocity-rs client (source-only). It is the Rust DLOB library used by fillers and keeper bots; one important behavioral change: a resting trigger order is quoted at its computed post-trigger auction price, not its raw trigger price — consumers of the order book should stop assuming the two are equal.

The Data API and playground

The data.velocity.exchange host serves historical and streaming data: trades, funding, candles and market states. The documentation includes an interactive Playground and a column glossary. Drift-era tables have been cleaned of legacy columns (external spot fulfillment, vAMM LP shares) — the full diff is in the migration guide.

SWIFT: off-chain signed orders

The SWIFT path is the primary one for market makers: an order is signed as a message without spending gas or entering the transaction queue, and a network of executors matches signed orders with on-chain settlement. A dedicated SWIFT API with indicative quotes and bot patterns is documented separately.

Keeper bots: four roles

The decentralized order book lives thanks to independent bots. The documentation contains step-by-step tutorials for each role: an order matching bot (matching takers against resting limit orders), an order trigger bot (executing trigger orders against the vAMM), a liquidation bot (liquidations prioritizing the oldest positions) and a JIT maker bot (participating in short execution auctions). Filler rewards are the lesser of two values: 10% of the fee or a time-based component that grows with the order's waiting time.

A technical subtlety for MM cranks: a native MM-oracle write is silently skipped if the interval is under 800 milliseconds or the sequence id is not strictly increasing, and a price step over 1% is clamped rather than rejected — bots pushing updates too aggressively get silent skips with no error signals.

Migrating from Drift: the official guide

The team published two documents: the human-readable Migrate from Drift guide and an AI Agent Guide — a step-by-step procedure a coding agent can execute. The canonical account-layout and ABI reference is the DRIFT-TO-VELOCITY.md file in the monorepo. Typical checklist items: SDK symbol replacement, the USDT mint instead of USDC, rebuilding raw decoders for the new discriminants, and checking order batches against initial (not maintenance) margin.

The general fundamentals of request signing and transport choice are covered in our materials: HMAC-SHA256 authentication and REST vs WebSocket. Hands-on Velocity keeper-bot tutorials will appear in this review's extras section.

Frequently Asked Questions (FAQ) about the Velocity API