Skip to main content

​
Custody & Asset Security

No. Assets remain in the user’s wallet at all times. Every order uses an approval the user grants (an ERC-20 allowance or Permit2 on EVM, or token delegate authority on Solana). When an order executes, our contract pulls funds, executes the swap, and returns the output token to the wallet in a single atomic transaction. On a cross-chain order, the output arrives at recipientAddress on the destination chain after bridging. We only pull funds at the moment of execution, and if the transaction fails, funds remain untouched. We never custody or hold assets on your behalf.
On EVM, Flash uses one of two allowance mechanisms: a direct ERC-20 approval to the settlement contract, or Permit2. The quote response tells you which applies. The user signs up to three things depending on the flow:
  1. A one-time ERC-20 approval (approveTx) granting allowance the first time a wallet trades a given token. Its spender is the settlement contract, or the Permit2 contract when the order uses Permit2. By default, later orders for the same token skip this step.
  2. A Permit2 signature (permitTypedData), present only when the order uses Permit2 and the existing permit doesn’t cover it. Gasless and offchain. By default the permit is unlimited with no expiration, so later orders usually skip it.
  3. A Flash order signature (orderTypedData), an EIP-712 payload authorizing the specific trade. Gasless, offchain, signed per order. Always required.
With minimal authorization, the direct approval to Flash or the Permit2 permit is sized to your new order plus your open orders instead, so most new orders need a fresh approval or permit. The ERC-20 approval to the Permit2 contract itself stays unlimited. An attached bracket also needs an authorization for the token the order receives.Our contract validates these signatures onchain at execution time. Users can revoke the approval or cancel the order at any point, which removes our ability to pull funds.
On Solana, the user sets Definitive as a token delegate. The user also signs an offchain payload using a standard signature scheme. We’ve deployed a Solana program that verifies this signature before pulling funds. Optional deadlines can be added (for example, expiring an order after one month). Users can revoke delegate authority at any time.

​
Order Execution

We built a trading system modeled on high-frequency trading infrastructure. Our trade engine continuously evaluates all open orders against real-time pricing events. When a pricing event occurs for a given token, we check whether any open order for that asset is executable.
Yes. Most other swap platforms and order systems require cross-rate pricing (e.g., “sell when TOKEN/ETH hits X”), which is difficult for users to reason about and compute. We support notional pricing for all of our order types. For example, you can set a limit like “sell when TOKEN drops below $1.00.” Cross-rate pricing is supported too, on both limit and trigger prices, if that is the frame you want — see Pricing basis.
We do. After you sign a quote and pass it to us, our execution infrastructure (called “performers”) lands the transaction onchain. This is a key value add: we handle MEV protection, gas optimization, dynamic gas pricing during congestion, and transaction retry logic so you don’t have to.

​
MEV & Transaction Protection

Several layers. First, all order intents are stored offchain, so they aren’t visible onchain before execution. Second, we route through MEV-protection endpoints when available. Third, our trade engine sets tight slippage tolerances, making sandwiching economically unviable. If a sandwich attempt pushes the price outside our slippage threshold, the transaction reverts automatically. All of these configurations are done dynamically by Flash’s trade engine based on current market conditions.
Yes, twice. At quote time, we simulate the trade against onchain state to ensure the quoted output is achievable (not just pool-math estimates). Then, immediately before execution, we simulate again against the latest chain state to validate the fill and abort if the simulation reverts.

​
Supported Chains & Assets

All major EVM chains plus Solana, including Ethereum, Base, Robinhood, Arbitrum, BNB Chain, HyperEVM and more. If there’s an EVM chain we don’t yet support that you need, we’re happy to work with you to add it.
Yes. As long as the RWA token is on a supported chain and has onchain liquidity, we’ll have a quote for it.
It depends on the chain and direction. On EVM chains, you can receive native ETH or the chain’s native gas asset as the output of a trade by using 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee as the received asset.To spend a native gas asset on EVM, quote with 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee as the spent asset, send the returned wrap.evmTx, then submit using the wrapped-native asset returned by the quote.On Solana, quote native SOL input with So11111111111111111111111111111111111111112 as the spent asset and svmUseNativeSOL: true; send the returned wrap.svmInstructions before submitting. Solana output to So11111111111111111111111111111111111111112 is wSOL, not native SOL.

​
Integration & Testing

Set flashIntegratorFeeBps on POST /quote, then submit the same string value on POST /order.
Register a builder code on base.dev, then pass it as erc8021AttributionCode on POST /order (EVM orders only — it does not affect quotes, so it is not sent on POST /quote). Flash appends it to the settlement transaction’s calldata alongside Definitive’s own code. See Base builder-code attribution.
We recommend testing on a production chain like Base or Solana using small amounts. We’ve found this is more reliable than testnets, which often have unrealistic gas behavior and omit nuances of live trading.
Yes. Flash’s EVM and Solana smart contracts have been audited, and the reports are published on the Security page.

​
Order Types & Terminology

A stop buy is a buy-side trigger: it rests until the market rises to your trigger price, then executes a market buy. A stop-loss is the sell-side equivalent: it rests until the market falls to your trigger price, then executes a market sell.
Yes. An attached bracket places a take-profit / stop-loss pair together with a market, limit, or twap order in one quote, sign, and submit flow, on same-chain EVM and Solana orders. The pair activates on the entry’s first fill and protects the asset the entry receives. See Bracket Orders.
Yes. Place a standalone bracket order: side: "sell", the qty to protect, and two triggers with opposite triggerType. Whichever leg fires first sells qty at market and the other leg is discarded. You can rest any number of brackets on the same asset, each with its own qty, and give each an expireTime. See Standalone brackets.
Yes, for prices: PATCH /orders/{orderId} changes the limit price or trigger price of a resting order without cancelling, and the order keeps its orderId — see Updating Orders for which prices each order type accepts. For any other change, cancel the order and place a new one.

​
Signatures, Approvals & Smart Wallets

Yes. Flash supports EIP-1271 signatures, so smart contract wallets that can produce an EIP-1271 signature (for example Safe and account-abstraction wallets) can sign and place orders.
Flash picks the signature check from the funder’s onchain code, not the address type. If the funderAddress has any code, including the 23-byte 0xef0100… delegation indicator an EIP-7702 authorization installs, Flash validates the order signature with EIP-1271 (isValidSignature) rather than plain ECDSA recovery. Validation is then whatever the delegate accepts. Many delegates wrap the digest in a replay-safe hash, so a bare EOA eth_signTypedData_v4 signature over orderTypedData is rejected with PERMISSION_DENIED: signature verification failed even though it recovers to the account.Sign through the delegated smart account’s typed-data flow so the signature passes the delegate’s isValidSignature, then submit that as the userSignature. For example, with an Alchemy Modular Account V2 delegate, build the account with toModularAccountV2({ mode: "7702" }) and sign orderTypedData via its smart-account signTypedData. Alternatively, remove the 7702 delegation (or trade from a plain EOA or dedicated smart wallet) so validation falls back to ECDSA recovery. See EIP-7702 delegated EOAs.
That’s the Definitive vault for your integrator account (your fee-settlement vault and the workspace where the swap executes), and there’s one vault per chain. The signed order binds execution to it: Flash pulls the spent asset into that vault, runs the swap, keeps your integrator fee there, and sends the output to the destination wallet. The quote response fills the address in and you sign what’s returned, so you don’t need to set or track it on your side.
Yes. The onchain ERC-20 approval must be sent from the funderAddress specified in the order. By default, this is a one-time transaction per user per token.
No. The approval is an onchain transaction, while the order signature is a gasless offchain payload. They’re fundamentally different operations. However, by default the approval only needs to happen once per user per token, so subsequent orders for the same token skip this step entirely.
Yes. The spender field in Permit2 signatures is scoped specifically to the Flash settlement contract. It is not a generic Permit2 spender that any arbitrary router could claim against.