Overview
Send a single transaction to multiple destinations with UTXO-based assets. You can execute several "sub-transactions" in a single blockchain transaction that divides the value you transfer across multiple destinations.
This helps you save on transaction fees and makes the operation more efficient. Send transfers to multiple destination types at the same time, and pay only a single transaction fee.
Multi-destination transactions can't use TreatAsGrossAmount
UTXO transactions with multiple destinations cannot use the TreatAsGrossAmount parameter, which automatically deducts fees from the transfer amount.
All destinations are logged in your workspace's Transaction History.
Create multi-destination transactions
Send a single transaction to multiple destinations using the Fireblocks API:
- Create a new transaction via the Fireblocks API.
- Use the destinations parameter instead of destination.
- Specify each destination with its destination type and destination ID.
Destination type behavior
Default behavior
Multi-destination transactions use DestType = MULTI_DESTINATION by default.
Legacy behavior
Some accounts may still use the previous behavior, where multi-destination transactions are marked as DestType = NONE. This legacy setting was preserved to prevent breaking changes for existing implementations.
Changing your behavior
If your account currently uses DestType = NONE for multi-destination transactions, and you want to switch to the default MULTI_DESTINATION behavior, submit a request to Fireblocks Support.
Policy enforcement
Each destination is treated as a separate sub-transaction according to your workspace's Policies. Policy rules are checked for each sub-transaction, but apply to the whole transaction.
If different approval requirements apply to different sub-transactions, they must be approved separately. If any output is rejected, the entire transaction is blocked.
To create a policy rule based on the aggregated transaction amount, use time-based rules in your policy.
Example
A transaction has Vault A as the source, and three destinations: Addresses X, Y, and Z. The workspace policy has rules that match each destination separately:
- Allow if transferring from Vault A to Address X
- Require approval if transferring from Vault A to Address Y
- Deny if transferring from Vault A to Address Z
Because rule 3 blocks any transaction from Vault A to Address Z, the entire transaction is denied to all destinations.
If the transaction is sent to only Address X and Y, then the approval request applies to the whole transaction.