Skip to main content
This is an enterprise-only feature. Please contact us to enable.
Fireblocks Flow lets your users pay from any supported wallet, exchange, or deposit address and have the funds settle in the token and chain you configure. This guide covers the full client-side flow with the Dynamic Flutter SDK.

Prerequisites

Before starting a flow on the client, create it from your backend. The flow creation endpoint is server-side only, authenticated by an API token with flow.write scope — this is where the amount, currency, settlement, and destination are fixed.
The response includes flow.id — pass this as the flowId to your Flutter app when calling the SDK methods below.
Optional — collect your own fee. Add a feeConfig to the create body to take a percentage of each swap to your own EVM wallet(s). Recipient addresses must be EVM (0x…). See Fee collection and claiming for the config shape, how to check balances, and how to claim accrued fees.

Installation

The dynamic_sdk_fireblocks_flow package is available from Dynamic Flutter SDK 1.14.0 onward. Add it to your pubspec.yaml:
For EVM sources you also need dynamic_sdk_web3dart:
For Solana sources you need dynamic_sdk_solana:
Then run:

Supported chains

The Flutter SDK supports the following source chains:
  • BTC
  • EVM
  • SOL
  • SUI
  • TRON
TRON cross-chain swaps currently route through intent-based bridges and may incur higher gas costs relative to the transfer amount.

Overview

The client-side flow follows these steps:
  1. Attach the source wallet or deposit address with attachSource.
  2. Quote the conversion with getQuote.
  3. Prepare the unsigned source-chain payload with prepareSigning.
  4. Sign and broadcast the payload with the source wallet’s own signer.
  5. Record the resulting transaction hash with broadcast.
  6. Poll for completion with getFlow.
attachSource returns a one-time session token (dft_…). The SDK persists it to secure storage keyed by flowId and adds it automatically to every subsequent call. You never need to handle it directly.

Resume a flow from its current state

A flowId represents one execution attempt. On page load, retry, or reconnect, call getFlow before calling a mutation. Do not unconditionally call attachSource again.
source_confirmed means source execution is finished, not necessarily that settlement is finished. Keep tracking settlementState until it reaches completed or failed.

Full example

flowId and wallet come from your app state. wallet is a BaseWallet returned by the Dynamic SDK.

Chain-specific signing

Step 4 (sign and broadcast) is not an API call. You sign prepared.signingPayload with the source wallet’s own signer and submit the result to the chain. The SigningPayload exposes one chain-specific field:
  • EVMevmTransaction (and optional evmApproval)
  • SOL / SUIserializedTransaction (base64)
  • BTCpsbt (base64-encoded unsigned PSBT)
  • TRONtronTransaction

EVM source

If evmApproval is present, submit the ERC-20 approval transaction first and wait for it to be mined before signing the main evmTransaction.

Solana source

Bitcoin source

TRON source

Deposit address source

With a deposit address flow the user sends funds directly to a generated address — no wallet connection or on-chain signing required from your app. Works for BTC, SOL, EVM, and TRON.
1

Attach a deposit address source

2

Get a quote — response includes the deposit address

3

Poll until the transfer is detected

The backend detects the inbound transfer automatically. Poll getFlow until executionState leaves quoted.
There is no signing step. Once the user sends funds to depositAddress, the transfer is detected automatically and the flow advances to source_confirmed.

Resuming after an app restart

The session token returned by attachSource is persisted to secure storage automatically. To resume tracking an in-flight flow after the app was killed, call getFlow — it needs no session token:
If a later call throws FireblocksFlowException with sessionTokenInvalid == true, the stored token has expired or was rejected and has already been removed. Call attachSource again to obtain a new token.

Error handling

All Fireblocks Flow methods throw FireblocksFlowException on failure. The exception exposes message, statusCode, and sessionTokenInvalid. Use sessionTokenInvalid to decide whether to re-run attachSource.

Common errors

Polling for status

After broadcast, poll getFlow to track execution and settlement. Stop when settlementState reaches completed or failed, or when executionState reaches a terminal state (cancelled, expired, failed).
Last modified on August 5, 2026