Introduction

The Fireblocks integration makes it possible to view and operate structures from this custody provider through the Wallet Manager.

The experience uses the same general concepts of Vaults, Wallets, Deposit Addresses, balances, and transfers presented in the other articles. However, some features have specific conditions determined by the Fireblocks model.

This article covers:

• which features are available in the integration;
• how Fireblocks Vaults and Wallets are represented;
• the conditions for creating Deposit Addresses;
• the handling of assets that require on-chain activation;
• how Fireblocks balances are presented;
• the specific rules for transfer destinations;
• how deposits and frozen funds are handled.

To operate Fireblocks structures through the Wallet Manager, an active connection with the provider is required.

Available features

The list of features available for the Fireblocks integration is shown below:

Fireblocks Vaults and Wallets

Fireblocks has a native Vault model. For this reason, a Vault Account that exists on Fireblocks is represented in the Wallet Manager as a Native Vault.

This means the Vault actually exists on the provider, and not only as a grouping created by the Wallet Manager.

A Fireblocks Wallet always belongs to a Vault. When creating a new Wallet, it is necessary to:

• select an existing Fireblocks Vault; or
• create a new Vault during the same flow.

Creating Vaults

To create a Fireblocks Vault, a name must be provided.

The following parameters are currently applied automatically in the integration:

• the Vault is created as MPC;
• the AutoFuel feature is disabled.

The complete flow is described in How to create a Wallet in the Wallet Manager.

Deposit Addresses

Main Deposit Address

The Wallet's permanent address on Fireblocks is presented in the Wallet Manager as the Main Deposit Address.

When the network uses complementary information, the Wallet Manager also presents the corresponding:

• memo;
• tag;
• equivalent identifier used by the network.

The address and the memo or tag, when present, must be considered together to correctly identify the deposit's destination.

Additional Deposit Addresses

Fireblocks allows creating additional Deposit Addresses on some networks.

These addresses can be used, for example, to distinguish incoming funds by:

• client;
• source;
• business unit;
• operational purpose.

During creation, an optional description can be added to identify the address. This description can also be changed later.

Availability by network

Creating additional addresses depends on the capabilities Fireblocks offers for each network.

It may be available, for example, on:

• UTXO-based networks;
• networks that use a memo or tag to distinguish incoming funds.

On EVM networks and on Solana, for example, Fireblocks doesn't allow creating multiple addresses for the same Wallet.

Assets that require on-chain activation

Some networks require certain assets to be activated in the Wallet before they can be received or sent.

This process may be called:

• trust line;
• opt-in;
• asset activation.

This condition may exist, for example, on networks such as:

• XRP Ledger;
• Stellar;
• Algorand.

Activation is an on-chain operation, may require a signature, and usually consumes a network fee.

Currently, this activation cannot be commanded from the Wallet Manager.

For this reason, the existence of a Vault or a Wallet for a given network doesn't guarantee that all of that network's assets are already available to operate.

Before using an asset that requires activation, it is necessary to:

1. perform the activation directly on the provider, when needed;
2. wait for the structure to be updated in the Wallet Manager.

How Fireblocks balances are presented

The balances reported by Fireblocks are converted to the Wallet Manager's standardized types.

Outbound transfers

Outbound transfers follow the general Wallet Manager flow, including Governance and AML when enabled.

All the steps are described in How to create and track an outbound transfer.

The main particularity of Fireblocks lies in identifying the destination.

The destination must be registered on Fireblocks

For a transfer to be executed by the Parfin Platform, the destination address must be registered in the same Fireblocks workspace used by the connection.

Currently, the destination must belong to one of these categories:

1. another Vault in the same Fireblocks connection;
2. an Internal Wallet registered on Fireblocks;
3. an External Wallet registered on Fireblocks.

Internal Wallets and External Wallets are categories of Fireblocks Whitelisted Addresses and must be approved in the counterparty's Workspace before they can be used.

Transfers to one-off addresses, also called One-Time Addresses, are not available in the current integration.

How the destination is validated

Before allowing the transfer to be created on the Parfin Platform, the system checks whether the selected destination address belongs to one of the categories mentioned above.

When the same destination is found in more than one of them, the Wallet Manager uses the following priority order:

1. Vault in the same connection;
2. Internal Wallet;
3. External Wallet.

If no match is found, the transfer can't be created. In this case, the destination must be registered in the Fireblocks workspace and the information must become available to the Platform.

Registering Internal and External Wallets

The registration and approval of Internal Wallets and External Wallets must be done directly on Fireblocks, in the Whitelisted Addresses section.

The Wallet Manager uses this information to validate and command transfers, but it doesn't create these structures on the provider.

Deposits and frozen funds

On Fireblocks, it is possible to freeze funds related to a specific transfer. Frozen balances are deducted from the available amount and can't be used in transfers.

When a deposit is frozen, the transfer shows the Rejected status on Fireblocks, even when it is confirmed on-chain.

Freezing a transfer on Fireblocks can happen through:

• the provider's own internal automatic flow;
• a manual freeze request.

In this scenario, the following information is expected:

This information represents different aspects of the operation:

• COMPLETED indicates that the assets were received and the deposit was processed by the Wallet Manager;
• REJECTED preserves the condition reported by Fireblocks;
• RESTRICTED indicates that the received amount is frozen and can't be moved.

Therefore, the COMPLETED status of the transfer doesn't necessarily mean the funds are available for use.

Automatic freeze by AML

When AML is enabled on the instance and a deposit in the Fireblocks connection is classified as risky (Risky), the Wallet Manager automatically requests that the transfer be frozen on Fireblocks.

After the provider's confirmation:

• the frozen amount becomes part of the RESTRICTED balance of the wallet that received the deposit;
• the deposit status remains COMPLETED.

Manual freeze and unfreeze

Currently, these manual actions are available only via API.

It is possible to request the unfreeze of a previously frozen transfer, including when the freeze originated directly on Fireblocks.

After a freeze or unfreeze, Fireblocks updates the corresponding balances, and the Wallet Manager reflects the new Available and Restricted values.