Fireblocks continuously monitors and analyzes Blockchain updates (forks, merges, and upgrades) as they occur, and keep you updated on what you need to do in such cases. This article thoroughly analyzes how Fireblocks deals with expected Blockchain updates.

Monitoring updates

Monitoring

We monitor on a daily basis possible blockchain updates by use of popular news sites which follow cryptocurrency developments, such as:

Messari.io
Blockworks
TLDR Crypto
Twitter

Customer notification

We use the following communication channels to inform you of any updates in supported blockchains:

Help Center articles (Example - London fork)
The Fireblocks status page (Example - London fork)
Console login notifications (pop-up, banner, etc)

Updates analysis

As we become aware of a blockchain update, we take several steps:

Thoroughly examine its announcement on the news sites (and code, when relevant) immediately as it is published.
Carefully estimate the resources required to support the update, and decide on one of the following options:
1. 1. No special resources are required beyond close monitoring of the update.
  2. DevOps resources are required to support the update by upgrading the nodes.
R&D resources are required to implement necessary changes, followed by DevOps resources required for deployment and node upgrades.

What to expect during an update

In an update scenario, you need to be aware of the following factors:

All other blockchains are NOT disrupted by the update
Our support and R&D teams closely monitor the update's progress in real-time
Depending on the use case, we may need to freeze some wallets during the update process, both on the original and forked chains. No transactions or any other activity will be possible during such a freeze, which is expected to remain in effect for one to three hours, depending on the update's progress, related network activity, and our internal testing.

Soft-forks

In a soft fork scenario, which is a backward-compatible software upgrade where validators in the older chain consider the new version as valid, we take the following steps:

Deploy updated mainnet nodes and possible code changes to the staging environment.
Test the updates.
Deploy the new nodes and code to production once testing is complete.

Hard-forks

In a hard fork scenario, which is a radical upgrade that may make previous transactions and blocks invalid and require all validators in a network to upgrade to a newer version (not backward-compatible), we take the following steps:

Prior to the fork occurrence, we test-update the nodes and code on the testnet.
Towards the fork occurrence, we may disable the blockchain's activity on the mainnet.
Update nodes and code in production.
Perform functionality tests on the mainnet.
Monitor the mainnet itself for stability.
Enable blockchain support once testing is done and the mainnet seems stable.
Closely monitor the blockchain and nodes for the next 12 hours.

Notes

We always support the predecessor chain, as long as it has a different chainID.
In some scenarios, we may not immediately support the forked chain, but monitor its progress during its first few days of life (e.g. Terra Classic + Terra 2.0).
As a ground rule, due to the risk of the blockchain not performing smoothly, we recommend avoiding time-sensitive transactions approximately two hours around the time of the fork occurrence. As we previously mentioned, no transactions or any other activity will be possible during the forking process.

What not to expect during a hard fork

In a hard-fork scenario, Fireblocks will usually not create asset wallets on the forked chain on your behalf, as it is your responsibility to do so.

The blockchain deprecation process

In rare scenarios a blockchain network is deprecated. In such a case we take the following steps:

Notify you of an upcoming blockchain deprecation. It is then your responsibility to withdraw your funds from it.
We may set in place a warning message whenever you send/receive funds on that blockchain via the Fireblocks console.
Towards the blockchain's end-of-life, we may contact you and inform you of your balance on the blockchain.
After the blockchain is deprecated, it will no longer be available on our system.

Note

In such cases, token value usually drops rapidly once a deprecation is announced.

Customer FAQ

Can we contribute to the decision-making process of an upcoming fork?

We appreciate any input from our customers and partners about such situations.

Do you have a replay prevention mechanism through the inclusion of "dust" transactions in wallets that are available only on either chain, in order to prevent cross-chain replay?

Yes. This is relevant for forks where you do not want transactions created on the new blockchain to be replayable on older chains.

What do we need to do to reactivate wallets or coins that Fireblocks deactivated during the update process?

In most cases, no action is required on your part. However, when a hard fork occurs or a new blockchain is created, you must create wallets on the new blockchain in the relevant vault account to access the funds located there (e.g., creating a BCH wallet in the same vault account that has a BTC wallet).