Skip to main content

General

Any Solana wallet that supports standard transaction signing.
No. Funds stay in the user’s wallet throughout the trade lifecycle.
Spot trades are non-custodial and don’t require KYC.
No.
No.
Yes. Both on the bonding curve and after graduation to PumpSwap (Pump.fun’s native AMM).
On the roadmap. No timeline yet.

Trading & Routing

Use the WSOL mint (So11111111111111111111111111111111111111112) as inputMint or outputMint and set wrapAndUnwrapSol=true. DFlow auto-wraps and unwraps SOL.
Use the destination wallet address, not the wallet’s WSOL associated token account address.
Slippage is the price drift between quote and execution. Price impact is the gap between market price and your effective fill, caused by your trade’s size relative to available liquidity.
The server applies a default threshold and rejects trades that exceed it with a price_impact_too_high error. Override with priceImpactTolerancePct.
DFlow uses the associated token account by default. To send output elsewhere, pass destinationTokenAccount on /order; output lands in that account even if it isn’t the ATA.
Traditional aggregators commit a route at quote time. DFlow’s JIT routing may refine the route at execution onchain, reflecting current conditions.
Yes, as an opt-in. Most builders use /order (imperative): the app signs a fully constructed transaction and submits through its own RPC. The intent flow (GET /intent + POST /submit-intent) gives stronger sandwich resistance on standard SPL pairs: the user signs an open order without a fixed route, and DFlow submits the open order and fill atomically as a Jito bundle. Token-2022 mints aren’t supported on /intent.
Multi-leg routes can create intermediate token accounts to pass value between legs.
  • Full consumption: If subsequent legs consume the intermediate amount, the accounts are closed.
  • Partial consumption: If a residual remains (venue rounding, leg constraints), the accounts stay open with small dust.
It means DFlow couldn’t find a route for the pair at your trade size. A likely cause is insufficient liquidity for that pair and size. It’s also worth confirming both mint addresses are correct and that amount is in atomic units (scaled by the input token’s decimals, e.g. 5000000 for 5 USDC).
No. The Trading API accepts base58 mint addresses only; there’s no symbol resolver. (The dflow CLI resolves a small set of common symbols, but the API does not.)
Call /order without userPublicKey. It returns the price fields (inAmount, outAmount, priceImpactPct) and no transaction, so you can show a price before the user has connected a wallet. A separate /quote endpoint still works, but /order is preferred for new integrations.

Fees & Sponsorship

Network fees, optional priority fees, optional platform fees if you set them, and any DEX fees baked into the route. Slippage depends on market liquidity and trade size.
Pass prioritizationFeeLamports on /order as a lamport amount or one of auto, medium, high, veryHigh, disabled. See Priority Fees for the two fee modes.
Yes. Pass the sponsor parameter on /order to have a sponsor wallet cover the transaction fee.
No. The API factors platformFeeBps into slippage tolerance, so declaring a fee you don’t collect wastes slippage budget and gives users worse pricing. See Platform Fees.

Troubleshooting

The transaction hit its compute unit (CU) limit. Pass dynamicComputeUnitLimit=true on /order to have the API size the limit automatically.
Enabling dynamicComputeUnitLimit may add latency; however, it depends on the rest of your parameters.
No. The Trading API doesn’t set CORS headers, so browser requests are blocked. Proxy /order through your backend; most builders use an edge function (Cloudflare Workers, Vercel Edge Functions) to keep added latency low.
No. As a security best practice, your DFlow API key belongs on the backend, not in browser code where anyone can read it. Stream through a backend proxy that holds the key, connects to DFlow, and relays messages to the browser.
Access to the quote and book streams is granted per API key; it’s a separate permission, not automatic with a valid or production key. A key that trades fine on /order can still be refused on the stream until the team enables stream access on that specific key. So if a working key is rejected only on the stream, that’s a key permission, not a bug in your integration; request stream access from the team.

Proof

No.
Yes. Your app directs the user to https://dflow.net/proof to complete KYC, with a redirect URL to send them back to your app after verification.
Proof only redirects to https:, moz-extension://, or chrome-extension: URLs. Custom schemes (e.g. myapp://callback) silently fail. Native mobile apps should use universal links (iOS) or app links (Android). See redirect_uri parameter docs.