The planned eCash (ECX) hard fork of Bitcoin is approaching its final launch, with exchanges taking different positions on whether customers will receive the new asset. As of October 25, 2026, the project targets Bitcoin block 973,728, estimated around October 30. That is a block-height target, not a fixed appointment.

ECX is separate from the existing cryptocurrency eCash (XEC). The similar names do not make their networks, balances or deposit addresses interchangeable. For BTC holders, the immediate questions concern custody, transaction handling and wallet security.

One Bitcoin history, then separate networks

A chain split creates a new network that shares an earlier transaction history with the original blockchain and then follows different rules. Bitcoin continues on its own chain. The planned ECX network does not convert BTC into another asset or require Bitcoin users to adopt its software.

The project, associated with Paul Sztorc and LayerTwo Labs, aims to activate Drivechains through BIP300 and BIP301. These are proposals for sidechain functionality. Implementing them on ECX would change the new network, not the rules enforced by ordinary Bitcoin nodes.

The project's allocation model starts from a snapshot of Bitcoin's ledger. A snapshot records the relevant state at a particular block. Creating a corresponding balance on another chain does not establish a market price, exchange support or an entitlement to a credit from a custodian.

The final snapshot is separate from Alpha and Beta

The project describes three stages, each starting from a fresh Bitcoin snapshot:

  • Alpha forked at block 963,648 on August 23, 2026. The integration documentation records its retirement on September 24.
  • Beta began at block 967,680 on September 19, 2026.
  • The final phase, described as Mainnet or Full Release, is planned for block 973,728. The launch remains ahead as of October 25.

Alpha and Beta were rehearsals. Their balances are not the final mainnet snapshot, and completing a test procedure on Beta does not complete it for Mainnet.

Calendar estimates have moved. Coincheck's October 9 notice used approximately October 31, while bitFlyer's October 15 notice used approximately October 30. The project's current website also displays an October 30 estimate. These dates depend on Bitcoin block production; block 973,728 remains the relevant trigger in the notices reviewed.

Exchange policies determine account credits

bitFlyer's third notice, published October 15, says BTC trading will continue normally and no service suspension is currently planned. Deposits and withdrawals are also expected to continue, although network conditions could cause delays or a temporary suspension to protect customer assets.

The exchange does not plan to handle ECX, credit it to customers or pay a cash equivalent. It warns users not to send ECX to its BTC receiving addresses because assets could be lost. Its notice also flags phishing and says it will not request private keys or recovery phrases.

Coincheck's October 9 notice takes a similar position: no planned ECX handling or customer distribution, with BTC trading and transfers continuing unless conditions require restrictions.

CoinW announced a different policy on October 19. It plans a one-for-one ECX distribution for eligible BTC balances already credited to customer accounts at the snapshot. However, that notice addresses the snapshot and distribution only. Any ECX trading, deposit or withdrawal arrangements would need separate announcements. A distribution policy should not be read as confirmation of those services.

Invity also said on October 19 that it will not support ECX, citing its Bitcoin focus and constraints involving its custodian and license. The contrasting policies show why a project's ledger allocation and a customer's exchange account are separate matters.

Replay protection exists, but it is not automatic

Replay protection is a safeguard against a transaction signed for one chain being accepted on the other. The ECX project documentation describes an opt-in mechanism for protected ECX transactions. It does not describe automatic, universal separation of every BTC and ECX balance.

The current project guide warns that an ordinary transaction involving shared outputs can be copied to both networks. Changing the destination address alone does not prevent that. Its operator documentation describes the protection as one-directional and distinguishes Mainnet's transaction marker from the one used in testing.

That distinction matters because instructions written during Beta can be inappropriate for Mainnet. The documentation provides a mechanism, but it does not establish that every wallet implements it correctly.

Keep recovery information out of fork tools

Never enter a recovery phrase or private key into a website or tool offering to claim ECX. Be wary of fake wallets, support messages and urgent prompts that present disclosure of a secret as a required security step. Ledger's published phishing guidance likewise warns against counterfeit wallet applications and requests for recovery words.

Use a provider's established app or independently opened official support channel to check its policy. Do not treat an unsolicited message as proof that a wallet update or transfer is required. The guide to crypto wallets and recovery safety explains why a receiving address can be shared while recovery information must remain secret.

The remaining uncertainties are practical: the exact block-arrival time, final operating conditions and any updated provider restrictions. Until those are settled, a projected launch date is not evidence that the final fork has occurred or that a particular account supports ECX.