A Bitcoin hard fork called eCash (ECX) is underway. Fireblocks does not support ECX. If you use raw signing to interact with this fork, you take on a specific and elevated risk of replay attack against your BTC funds. This article explains what is happening, what the risk is, and what to consider if you decide to proceed.

This is a community-run project. Neither Fireblocks nor any major established player in the industry is affiliated with it or endorses it.

What is happening

The rollout happens in three stages, announced on August 7th, 2026:

Holders of BTC receive an allocation of ECX based on their holdings at each of these blocks. Coins collected during the alpha and beta stages are provisional. When the permanent chain launches at block 973,728, we expect these provisional coins to be burned and redeemed for "real" ECX.

Because there are three snapshots instead of one, BTC that moves between them can produce different ECX allocations at each stage. This extends the exposure window described below across all three dates, rather than confining it to a single one.

Bitcoin (BTC) itself does not change as a result of this fork. Your BTC balances, transactions, and Fireblocks vault operations are unaffected under normal use.

A note on naming: this fork's "ECX" is unrelated to the pre-existing eCash (XEC) project, which is a rebrand of Bitcoin Cash ABC. The two share a name but are separate assets on separate chains. This advisory concerns only the new fork described above.

Understanding the replay attack risk

eCash shares Bitcoin's transaction format, address format, and signature scheme. Because of this, a transaction signed and broadcast for one chain can, in some cases, also be valid and processed on the other chain. This is a replay attack.

A few points are worth understanding about how this specific fork behaves:

• The BTC-to-ECX direction appears to be by design, not an oversight. If you do not proactively split your coins, an outgoing BTC transaction is replayed onto the ECX chain as well, carrying your ECX allocation to wherever the BTC went.
• Protection in the other direction is limited. An opt-in tool is expected to help ECX transactions avoid replaying onto Bitcoin, but this is only confirmed for official eCash wallet software, not for Bitcoin transactions generally.
• Replay is time-bounded, but the window is not precisely known. Replay only works while an input (UTXO) exists identically on both chains. When your BTC UTXO set diverges from the ECX UTXO set, which happens naturally as each chain processes independent transactions, replay stops working for those specific inputs. This will happen eventually. How long it takes for any given UTXO is not clear from public information.

Two risk directions

The risk depends on what action you take.

If you deliberately construct a transaction to claim or move ECX: this is high risk to your BTC. Because the transaction is signed with the same keys, and potentially the same shared-history inputs, as Bitcoin, that "ECX" transaction may itself be a valid Bitcoin transaction. An action meant only to interact with ECX could inadvertently authorize movement of real BTC. This is the risk raw signing users need to plan around, and it is addressed in the next section.

If you take no action: this is low risk. Your normal outgoing BTC transactions may, by design, also move your ECX allocation to the same destination. If that destination is not ECX-aware, the ECX can become inaccessible.

Replayed allocations typically become inaccessible only when sent to a destination you do not control, such as an external exchange deposit. When ECX lands at a vault address under your management, retrieval remains operationally possible, in the same way the initial claim process is possible. This still requires you to manually create a raw-signed transaction, which carries a risk of replay attack on your BTC funds.

Why this matters if you use raw signing

Raw signing lets you sign arbitrary data with your BTC vault keys without Fireblocks interpreting what that data represents. Because eCash uses the same cryptographic scheme and address format as Bitcoin, you can technically use raw signing to produce a transaction intended for the eCash (ECX) network.

Fireblocks does not support ECX. Because vault keys are held under MPC, there is no way to export a private key into the official eCash wallet software. This means raw signing is the only available path if you want to claim or move ECX.

Using raw signing to claim or interact with ECX carries a real risk of replay attack and loss of funds. This is not the general, background-level risk that applies to raw signing at large, but rather a specific, elevated risk in this case. We do not recommend or endorse this path.

If you choose to proceed

If you decide to use raw signing to interact with ECX, apply this mitigation to reduce the risk.

Build your eCash transaction using an input that exists only on the eCash chain. For example, use ECX received from a post-fork coinbase, from a counterparty who has already split their coins, or from the official eCash wallet's opt-in replay-protection mechanism (refer to the eCash project's own documentation for how this mechanism works). A transaction built this way is structurally invalid on Bitcoin, because that input doesn't exist in Bitcoin's UTXO set, so it cannot replay onto Bitcoin regardless of whether the fork's own protection performs as described.

This approach requires you to independently verify that the input exists on ECX but not on Bitcoin. The construction is your responsibility. We have not reviewed the eCash client, its replay-protection implementation, or any third-party claim tooling. An error here puts production BTC keys at risk.

Confirmed reporting indicates eCash's replay protection is opt-in and one-directional: official eCash wallet software is expected to help eCash transactions avoid replaying onto Bitcoin, but no equivalent protection is confirmed for the reverse direction. Raw signing bypasses that official wallet software entirely, so whether a manually constructed eCash transaction carries any protection at all is unconfirmed.

Third-party "claim" tools for this fork are unaudited and outside our security review, independent of the replay question.

Fireblocks makes no representation or warranty that any of these mitigation steps are sufficient. Proceed at your own risk.

Our recommendation

If you do not want to claim ECX, no action is required. Replay costs you nothing in this case; your BTC is unaffected either way. It only moves a shadow ECX allocation on a chain you have no interest in.

If you want to claim ECX, raw signing is your only path, and the input-selection safeguard above is the key protection to apply. Take this step only when you have a clear understanding of the construction requirements, and treat ECX as an independent, unaudited asset. Consult your own security team before you take any action with production keys.

Do not use unaudited third-party eCash claim tools with your Fireblocks vault keys without independently verifying how they construct transactions.

What we are doing

We are monitoring the eCash project's technical specification and independent developer analysis ahead of the planned activations. We will update this advisory if the situation changes.

If you have questions or a specific use case you want to discuss, reach out to your Fireblocks account team or support.