Solana Overview

Flash API supports advanced orders for any SPL token on Solana, including Token-2022 mints. Aggregated liquidity across Solana’s DEXs and liquidity sources feeds the Flash smart order router. This page walks through how quoting, routing, and signing work on Solana at a high level. For the full endpoint reference, see Quote and Order. Base URL for all Flash API requests: https://flash.definitive.fi/v1

Solana order flow

Every Solana order follows four steps: quote, delegate, sign, submit. Before your first trade of a token, you also create the token accounts the swap needs. The user’s wallet must authorize every action. Flash never takes custody of funds.

Get a quote

Call POST /quote with the asset pair (targetAsset / contraAsset and their targetChain / contraChain), side (buy or sell), qty (a decimal string in the spent asset’s units: contraAsset on a buy, targetAsset on a sell), and orderType. For a same-chain Solana order, both assets are base58 mint addresses and both chains are solana. Crosschain orders use different chain values and require recipientAddress; see Crosschain Orders. Pass funderAddress (your base58 wallet address) so Flash can build the signing payloads. Flash’s smart order router evaluates routes across Solana liquidity sources and returns the best pricing.The response includes:

quoteId: reference ID to lock this pricing on submit
bridgeQuoteId (crosschain, conditional): bridge quote to echo back on submit when non-null
from / to: the spent and received legs, each with asset (target or contra), amount, and notional
fees.estimatedFeeNotional: total fee (gas, trading, integrator) in USD notional
svm.orderMessage: the UTF-8 message the user must Ed25519-sign
svm.nonce and svm.deadline: order nonce and Unix-seconds expiry, echoed back at submit so the program can rebuild the signed message
svm.ataSetupIxs (conditional): instructions that create your input and/or output token accounts, included when either does not yet exist onchain (see the next step)
svm.delegateIx (conditional): a Solana instruction granting the Flash program delegate authority over the spent token, included when the existing delegation is insufficient
svm.sponsoredDelegateTx (conditional): a sponsor-paid alternative to delegateIx (see below)
wrap (conditional): native-SOL wrapping instructions, included when the quote spends native SOL

On Solana quotes the evm block is always null.

Create your token accounts (first time per token)

The swap moves tokens through your funder wallet’s associated token accounts (ATAs), so the input and output ATAs must exist before the order runs. When either is missing on-chain, the quote returns svm.ataSetupIxs: one idempotent create-associated-token-account instruction per missing account, with your funder wallet in the payer slot. These instructions are not included in the svm.sponsoredDelegateTx, as Definitive does not sponsor token account creation.Send these instructions from your funder wallet before delegating, signing, and submitting. Your funder wallet pays the account rent (about 0.002 SOL per account, more for Token-2022 mints with extensions) and owns the accounts.The instructions are idempotent, so re-sending them is a safe no-op, and svm.ataSetupIxs is null once both accounts already exist. When a single order needs several onchain setup actions, run them in this order: create token accounts, wrap native SOL (if the quote spends native SOL), then delegate. You do not need a separate transaction per step; see combining setup instructions into one transaction.

Definitive does not sponsor token account creation. Execute svm.ataSetupIxs whenever the quote returns it, they are not created for you.

Handle token delegation (one-time per token)

Solana has no ERC-20 approval. Instead, Flash grants itself delegate authority over the spent token’s associated token account using an SPL Approve instruction scoped to the Flash program. This is the Solana equivalent of an EVM token approval and is required once per token per wallet. After the delegation lands onchain, future orders for the same token skip this step. With forceMinimalAllowance: true, the delegation is instead sized to the cumulative amount of this quote plus unfilled open orders and is re-issued whenever the existing delegated amount differs from it. See Minimal authorization.The quote returns the delegation in one of two mutually exclusive forms, and svm.delegateIx is the default:

svm.delegateIx: a raw instruction. Wrap it in a transaction, sign it with your funder wallet, and submit it to Solana yourself, paying the network fee. Build and test against this path, and keep SOL in the funder wallet for it.
svm.sponsoredDelegateTx: a base64 VersionedTransaction. Sign it with your funder wallet and echo it back as svmSponsoredDelegateTx at submit, and Definitive covers the network fee and broadcasts it. Sponsorship is off for new accounts, so do not assume this will appear.

At most one of the two is non-null, and when both are null the existing delegation already covers this order. With forceMinimalAllowance: true, both are null only when the existing delegated amount exactly equals the cumulative amount.

The delegation and the order signature are separate actions by design. The delegation is an onchain (or sponsored) transaction that grants the Flash program authority to pull the spent token. The order signature is a gasless offchain Ed25519 signature. They cannot be batched into a single user interaction.

You do not need a separate transaction for the delegation. See combining setup instructions into one transaction.

Sign the order payload

The user signs svm.orderMessage with their wallet’s Ed25519 key, producing a 64-byte signature. Encode it as base58 and pass it as userSignature. The message is plaintext, so a wallet’s message-signing flow surfaces the order’s mint and amount to the user.

import { Keypair } from "@solana/web3.js";
import nacl from "tweetnacl";
import bs58 from "bs58";

const keypair = Keypair.fromSecretKey(bs58.decode("..."));
const message = new TextEncoder().encode(quote.svm.orderMessage);
const signature = nacl.sign.detached(message, keypair.secretKey);
const userSignature = bs58.encode(signature);

The signed message commits to the order details (input mint, total, nonce, deadline) and to the Flash program and your Definitive trading group, so it cannot be replayed against another order or program. To check the message before signing, see Verifying the order message.

Submit the order

Call POST /order with the original trade parameters plus funderAddress, quoteId, userSignature, svmNonce, and svmDeadline (echoed back unchanged from the quote). For a crosschain market order, also send recipientAddress and echo a non-null bridgeQuoteId. If the quote returned svm.sponsoredDelegateTx, also sign it and include it as svmSponsoredDelegateTx. The EVM-only fields (evmOrderTypedData, evmPermitTypedData, evmPermitSignature) must not be present on Solana submissions.Flash handles priority fees, MEV protection, simulation, and onchain landing. The response returns an orderId for tracking.

Combining setup instructions into one transaction

svm.ataSetupIxs and svm.delegateIx are both plain instructions, so you can send them in a single Solana transaction rather than one per step. Keep the documented ordering inside that transaction: token account creation first, then the native SOL wrap instructions if the quote returned them, then delegation. Solana runs instructions in order, and the Approve needs the input token account to exist before it runs; on the native SOL path, that account is created and funded by the wrap instructions ahead of it. Broadcast the transaction and wait for confirmation before calling POST /order, which rejects the submission when the delegation does not cover the order total, or, on same-chain orders, when the funder’s output token account is still missing. If you run your own sponsor wallet, this is also where you cover the user’s costs. Set the sponsor wallet as the transaction fee payer and have it co-sign alongside the funder wallet, which still signs as the token account authority for the Approve and as the source of any wrapped SOL. To have the sponsor pay account rent as well, rebuild the create-associated-token-account instructions with the sponsor wallet in the payer slot and the funder wallet as the account owner. The instructions the quote returns put the funder wallet in both slots, in svm.ataSetupIxs and in wrap.svmInstructions. Wallet providers that support a separate Solana fee payer document this co-signing pattern in their own gas sponsorship guides.

Native SOL and wSOL

Flash settles Solana trades against SPL tokens. The mint So11111111111111111111111111111111111111112 is the wSOL mint used in Flash requests. To spend native SOL, set the spent asset to So11111111111111111111111111111111111111112 and set svmUseNativeSOL: true on the quote request. For side: "sell", the spent asset is targetAsset; for side: "buy", it is contraAsset. You must also include funderAddress so Flash can build the wrapping instructions. The quote response returns wrap.svmInstructions. Send those instructions from the funder wallet before signing and submitting the order. The order itself uses the wSOL mint, plus the svm.orderMessage, svm.nonce, and svm.deadline returned by the quote. For native-SOL quotes, wrap.svmInstructions creates your wSOL (input) account itself, so svm.ataSetupIxs only covers the output account. Land the onchain steps in order, ataSetupIxs, then the wrap instructions, then delegation, before you sign and submit. (The order signature is offchain; it only needs to be included in the submit.) If you omit svmUseNativeSOL, So11111111111111111111111111111111111111112 is treated as an ordinary existing wSOL balance. When So11111111111111111111111111111111111111112 is the buy asset, the output is wSOL. Flash does not currently support native SOL as the output asset.

Signer support

Flash orders on Solana must be signed by a standard Ed25519 keypair. The funder wallet signs svm.orderMessage directly, and Flash verifies the 64-byte Ed25519 signature against the funder’s public key. A composed order with an attached take-profit / stop-loss pair signs a second message the same way — see Bracket Orders. Multisig wallets that sign through a program-derived address cannot produce a direct Ed25519 order signature. Owners of such a multisig should trade from a dedicated wallet (or a future delegate-registration flow) rather than the multisig address itself.

Verifying the order message

svm.orderMessage is plaintext in this format:

DFS|m=<input_mint>|t=<order_total>|h=<order_hash>

m: the base58 mint of the spent token
t: the order total in the spent token’s base units
h: a truncated, unkeyed SHA-256 hash that you can recompute to confirm what the signature authorizes

h = base58( SHA256( "DFS_ORDER_V1" ‖ output_token_account ‖ nonce ‖ deadline ‖ input_token_account ‖ program_id ‖ group )[0:16] )

Field	Value	Encoding
`"DFS_ORDER_V1"`	Domain tag	12 ASCII bytes, no length prefix or terminator
`output_token_account`	Your funder wallet’s associated token account for the received mint. On crosschain quotes, the Flash program’s `flash_orders` PDA instead	Raw 32 bytes, decoded from base58
`nonce`	`svm.nonce` from the quote	u64, little-endian (8 bytes)
`deadline`	`svm.deadline` from the quote, in Unix seconds	i64, little-endian (8 bytes)
`input_token_account`	Your funder wallet’s associated token account for the spent mint `m`	Raw 32 bytes, decoded from base58
`program_id`	The Flash program: `FLaSHxRVv6G1NCJ2SFGPvQqKUPszuDjaTkBMFCSzEqpJ`	Raw 32 bytes, decoded from base58
`group`	Your Definitive trading group on Solana. Contact Definitive with your organization ID to get it	Raw 32 bytes, decoded from base58

Derive each associated token account with the mint’s own token program (SPL Token or Token-2022).

Slippage and price protection

You configure trader slippage or maximum price impact on the quote request. The signed order message does not contain a minimum-output amount, so Flash resolves the applicable protection when the swap is built and submitted:

Order type	How price is protected
Market	For a standard market order, the keeper computes a minimum-output amount from the quoted output and `maxSlippage`. QuickTrade uses `maxPriceImpact` against the execution-time reference price instead. If the swap cannot meet the applicable bound, the transaction reverts and no funds move.
Limit	The limit price is the binding constraint. The order only fills at or better than the limit price.
Stop, Stop Loss, Take Profit, TWAP	These execute at a future time. The keeper re-evaluates pricing and applies `maxPriceImpact` against the reference price available at execution.

Immediately before submission, the solver also applies an internal onchain-slippage bound against a fresh simulation. This dynamic bound accounts for factors such as Solana block times, pair volatility, and MEV activity. See Slippage and price protection for the complete model.

Routing and MEV protection

Flash routes every order through a smart order router that aggregates Solana’s DEXs and liquidity sources. Before submitting any transaction onchain, Flash simulates the swap offchain to optimize for best execution and to guard against malicious or compromised liquidity. Settlement runs through the Definitive Flash Solana program: the program verifies the user’s Ed25519 signature, pulls the spent token via the granted delegation, executes the swap, and routes the output and fees, all in a single atomic transaction. Orders are landed with priority fees and MEV-protected inclusion.

EVM Overview

How quoting, routing, approvals, and signing work on EVM chains.

Supported Chains

Full chain and asset coverage.

Getting Started

How Flash Works

Flash Integration

Specifications

Solana order flow

Combining setup instructions into one transaction

Native SOL and wSOL

Signer support

Verifying the order message

Slippage and price protection

Routing and MEV protection

EVM Overview

Supported Chains

​Solana order flow

​Combining setup instructions into one transaction

​Native SOL and wSOL

​Signer support

​Verifying the order message

​Slippage and price protection

​Routing and MEV protection

EVM Overview

Supported Chains

Solana order flow

Combining setup instructions into one transaction

Native SOL and wSOL

Signer support

Verifying the order message

Slippage and price protection

Routing and MEV protection