How diligent fork analysis uncovered a replay risk between eCash stages and how coordinated disclosure helped protect the forthcoming mainnet
Disclosure note. While analyzing the implications of the eCash fork on Bitcoin custody, we identified a cross-network replay vulnerability in eCash’s staged rollout. Had the existing replay-protection rule been carried into mainnet, transactions made on the earlier practice networks could also have moved or destroyed the corresponding mainnet ECX. We disclosed the issue to the eCash developers, who rapidly acknowledged it and implemented the protocol-level change described in this article ahead of the planned mainnet launch. This disclosure precedes that launch: the change protects mainnet from practice-stage replays, but does not prevent replay between the earlier practice networks.
eCash is rolling out in three stages: alphanet, the first rehearsal, launched on 23 August 2026; betanet, the second rehearsal, followed on 19 September; and mainnet, the intended permanent network, is planned for around 31 October. These are not successive upgrades to one chain. Each starts afresh from Bitcoin’s mainnet ledger at a different fork height, giving holders of Bitcoin at that height corresponding coins on the new network. Alpha and beta coins are called practice eCash (pECX); their balances do not carry forward into mainnet.
The unusual choice was to start the practice networks from Bitcoin mainnet rather than from a separate test ledger. They therefore inherited actual Bitcoin transaction history and unspent transaction outputs (UTXOs), with spending controlled by the same private keys as on Bitcoin. An output left unspent on Bitcoin could appear in more than one of these snapshots. That shared ancestry created the conditions for replay across stages; reusing the same transaction-validity exception made the replay possible.
When practicing could have become dangerous
There was also a reason to destroy practice coins deliberately. The developers offered a burn incentive: participants could send pECX to a designated address beginning “1BitcoinEater”, intended to make the coins unspendable, in return for a promised allocation of permanent ECX after mainnet launch. The alphanet offer was 10 ECX for every 1,000 pECX burned. This was a reward for destroying practice coins, not an intention to destroy the corresponding future mainnet coins.
Consider the following situation. You own some Bitcoin and are somewhat interested in eCash; a friend of yours is fully committed to it. Because the eCash alphanet spun off Bitcoin mainnet on 23 August, you received coins on that alphanet by virtue of holding Bitcoin before the fork height. Your friend asks for those coins to experiment with. Using them requires the same private key that protects your Bitcoin, so you are cautious. You read the available documentation, notably the coin-splitting instructions, and follow them to the letter. You create a transaction with nLockTime set to the magic value 499999999 and preserve the required nSequence. The transaction is not valid on Bitcoin, but it is valid on eCash. You send the explicitly experimental, supposedly worthless “practice eCash” (pECX) to your friend (or perhaps sell it for a nominal amount) and then leave both eCash and your rarely used Bitcoin untouched.
Fast-forward to shortly after the planned eCash mainnet launch. You consider accessing or selling your mainnet ECX. Which of the following is true?
a. Your mainnet ECX are safe and sound. The alphanet was just a practice run without consequences. The “what to expect” page of the project states “Every address holding BTC at each snapshot is credited automatically, with no action required from you.” You got your alphanet pECX, your betanet pECX, and your mainnet ECX. That you sent your alphanet pECX to a friend has no impact on your mainnet ECX. You and only you can use your Bitcoin private key again to access your mainnet ECX.
b. The ECX block explorer shows that your mainnet ECX balance is 0. It shows a transaction that sends them to your friend. You call your friend and he’s nice enough to send it back to you.
c. The ECX block explorer shows that your mainnet ECX balance is 0. It shows a transaction that sends them to your friend. And you further see that from your friend the ECX (together with a larger number of other coins) travel on to the designated burn address that starting with “1BitcoinEater”. You call your friend. He’s stunned upon your discovery. He participated in the project’s published burn incentive. He collected 1000 pECX and “burned” them to get 10 ECX gifted by them after mainnet launch. He did get those 10.
Without the protocol change described below, case (b) or (c) could have occurred. The transaction was correctly split from Bitcoin, but it was not split from the later eCash stages. The holder could have followed every published instruction and still seen an experimental transaction acquire real economic consequences on mainnet.
The cross-network replay risk
An eCash alphanet transaction that fulfilled all documented replay-protection requirements was safe from replay to Bitcoin. It was not, however, separated from eCash betanet or the planned eCash mainnet. The one-directional protection therefore did something useful: it created a boundary between Bitcoin and eCash. The problem was that it did not create the necessary boundaries among eCash’s own fork stages.
The documented and implemented parameters for alphanet, betanet and the intended mainnet were identical. A transaction using the magic nLockTime value 499999999 could be invalid on Bitcoin while remaining valid across those eCash networks. During our analysis, this was readily demonstrated by identifying protected alphanet transactions whose inputs remained available at the betanet tip: broadcasting them on betanet was sufficient for them to be included in a block. An official replayer intentionally carried eligible Bitcoin transactions onto betanet, just as one had for alphanet; replaying transactions between eCash stages would have required only minimal additional code.
Why we were looking at replay protection
Fork analysis is part of the less visible work of digital-asset custody. When an asset we support forks, we need to understand whether transactions on one chain can unintentionally move assets on another. That remains relevant even if we do not support the new asset at launch: months later, the fork may prove viable and valuable, and clients may expect the corresponding forked coins still to be under custody if support is added.
We recently described this custody perspective in the context of BIP 110 and the custody implications of a Bitcoin chain split. The same discipline led us to examine eCash’s replay characteristics. For our immediate custody use case, its one-directional replay protection was helpful: an eCash split transaction did not move the underlying Bitcoin. Following that question through, however, exposed the inverse problem. A mechanism that separated eCash from Bitcoin did not also separate alphanet, betanet and mainnet from one another.
From theoretical vulnerability to measurable exposure
To test whether the issue was merely theoretical, we analysed every post-fork alphanet transaction sending coins to the designated 1BitcoinEater burn address used for the incentive described above. We then isolated burns whose inputs could be traced exclusively to pre-fork Bitcoin UTXOs that remained unspent on Bitcoin. We found 11 burn transactions with a combined value just above 34,000 ECX. At the updated projected
mainnet price, that represented a material potential loss; the precise fiat estimate is secondary to the on-chain result.
That figure is evidence of real exposure, not an estimate of the vulnerability’s full impact. It covers the alphanet-to-mainnet burn case only. We did not aggregate a separate betanet figure because overlapping Bitcoin UTXOs would make a simple addition misleading. More importantly, the measurable burn case was not necessarily the most consequential one. A person could have acquired practice-stage coins from others and later replayed those transfers against valuable mainnet coins. Blockchain data cannot reliably distinguish transfers between wallets controlled by one person from genuine changes in beneficial ownership, so that larger ownership-transfer risk cannot be responsibly quantified.
From disclosure to fix
We presented the finding and its potential consequences to the eCash developers. They promptly acknowledged the vulnerability and its potential consequences, allowing us to coordinate disclosure while they implemented the proposed mainnet mitigation.
The cleanest mitigation was a protocol-level change before mainnet: every transaction that split eCash from Bitcoin also needed to be split from eCash mainnet. The nLockTime value 499999999 was a magic value. On Bitcoin, it would make a transaction valid only at a block height thousands of years in the future. eCash instead treated that specific value as valid immediately, allowing an intentionally crafted transaction to move eCash without moving Bitcoin.
We proposed assigning mainnet a different magic value: 499999998. Under that rule, existing alphanet and betanet split transactions using 499999999 would be invalid on mainnet, just as they are on Bitcoin, while newly crafted mainnet split transactions could use the new value. eCash implemented precisely this change in its mainnet replay-protection update.
The fix prevents their protected transactions from carrying over into the forthcoming mainnet under the amended rule. It does not isolate alphanet and betanet from each other, so replay of past alphanet transactions to betanet remain possible. The potential mainnet exposure however, is counterfactual at this point in time.
If LOCKTIME_THRESHOLD − 2 looks less obvious than the elegant LOCKTIME_THRESHOLD − 1, the reason is now part of the protocol’s history: the obvious value had already been used by the earlier stages and could not safely be reused by mainnet.
Without the protocol change, affected holders would have needed to consume the corresponding Bitcoin UTXOs before mainnet launch, for example by moving all relevant UTXOs to a wallet they controlled, so that replayed practice-stage transactions would become double-spends. Fixing the rule at protocol level was cleaner and more robust than requiring individual holders to identify the exposure and take action.
The lesson is bigger than eCash
Replay protection is not simply present or absent. It has a direction and a domain. In this case, the mechanism successfully created a boundary between Bitcoin and eCash while initially failing to create the necessary boundaries among eCash stages. Asking only whether a fork “has replay protection” can therefore conceal the more important question: which transactions are separated from which networks?
Practice assets are not automatically isolated from real economic assets. Calling pECX experimental and designing it to disappear did not by itself prevent transactions involving it from acquiring consequences on a later network. Isolation must come from transaction validity rules, not labels or expectations. Forking a practice network from Bitcoin mainnet imports real transaction history and signing keys into the rehearsal. It may serve as a testing purpose, but it does not have the independent transaction history of a separate test ledger. This requires explicit replay boundaries wherever the inherited outputs can reappear.
A custodian’s security perimeter extends beyond its supported-asset list. An asset does not need to be supported today for activity on its network to affect assets already under custody or future client entitlements created by a fork. Understanding forks, replay domains, key reuse and future claims is therefore part of custody security, not an extracurricular interest in protocol engineering.
Ecosystem security is collaborative
Diligent custody analysis surfaced an issue beyond our immediate supported-asset perimeter. On-chain research showed that the consequences were not merely theoretical. Through coordinated disclosure, the eCash developers acknowledged the finding quickly and implemented the mainnet mitigation ahead of launch.
Under the amended rule, protected transactions from the earlier practice stages will not carry over into mainnet. Replay between the practice stages remains possible.
For clients and market participants, this case demonstrates how technical rigor, transparency, and collaboration can reduce risk before it reaches the market. It also shows how trust in digital assets is built: not only through secure products and services, but through a shared commitment to strengthening the ecosystem. By identifying risks early, disclosing them responsibly, and working constructively with industry participants, Crypto Finance Group helps address challenges at their source. The result is a more secure and resilient digital asset ecosystem, providing a stronger foundation for institutional adoption.
Read more News here