$3B+
Notional spot volume executed
100+
Institutions onboarded
Millions
Successful Transactions
Audits
Flash’s smart contracts were completed with no major findings: Additionally, Definitive’s smart contracts (the same trade engine that powers Flash) have been audited multiple times by leading security firms, including Zellic, OtterSec, and Cantina. All audits have been completed with no material findings and are available for review here.Settlement contracts
Flash settles trades through audited contracts deployed onchain, and every address is independently verifiable. On EVM, integrators grant the ERC-20 approval to the settlement contract; on Solana, the trading program holds the SPL delegate authority and verifies each order signature.
The EVM contract is deployed at the same address on every supported EVM chain.
Non-custodial by design
Flash never takes custody of user funds. Tokens remain in the user’s wallet until the exact moment a trade executes (even for triggered/conditional orders). There is no intermediate holding contract, no fund transfers to a separate account, and no shared pools. This applies to every order type, including conditional orders (Limit, TWAP, Stop Loss, Take Profit) that may sit open for days or weeks before execution. During that entire period, the user’s tokens remain in their wallet and are visible in their balance. For a detailed walkthrough of how this works on EVM and Solana, see the Non-Custodial page.Trade order signing
Every Flash trade requires two independent authorizations from the user’s wallet. Neither alone is sufficient to move funds. Layer 1: Onchain approval (one-time per token). The user grants Flash permission to move a specific token. On EVM, this is a standard ERC-20 approval to the Flash settlement contract. On Solana, this is an SPL token delegation granting the Flash program delegate authority over the spent token’s associated token account. Layer 2: Offchain order signature (per order). For each trade, the user signs an offchain payload that authorizes the exact amount and includes an expiration deadline. On EVM, this is an EIP-712 typed-data signature (evm.orderTypedData). On Solana, this is an Ed25519 signature over svm.orderMessage.
The order signature is a key security control that caps the amount Flash can pull to exactly what the order specifies. Flash cannot execute a swap for more than the signed order authorizes, and cannot execute after the deadline has passed.
MEV protection
Multiple layers of MEV protection are built into the execution pipeline: Offchain order intent. All Flash trade orders are held offchain and are not visible to MEV bots or other market participants before execution. This mitigates front-running and other malicious attacks compared to protocols that publicize trades in public mempools. Pre-execution simulation. Before submitting any transaction onchain, Flash simulates the swap offchain to detect malicious or compromised liquidity pools. Private submission. Orders are submitted through private channels, preventing front-running and sandwich attacks by keeping trade intent out of the public mempool. Slippage optimization. Flash re-evaluates pricing at execution time and applies tight slippage to make sandwich attacks economically unfeasible.API key security
Flash requires an API key passed via thex-definitive-api-key header on every request. Keys are scoped to each specific integrator, and funds are never commingled amongst integrators.
A leaked API key cannot move funds on its own. Every trade still requires the user’s signed order and a valid onchain allowance, and an API key produces neither. If a key is exposed, revoke it and issue a replacement from the Flash integrator dashboard.