How Ecash Inherits Your Bitcoin
The most common question readers ask after reading the other essays on this blog is the most practical one: what happens to my Bitcoin when Ecash forks? The short answer is that you keep all of it, twice. The long answer requires a few hours of attention, some patience, and a healthy respect for the things that can go wrong in the first weeks of a new chain.
This piece is the practical guide. It will not make you rich. It will, hopefully, prevent you from making expensive mistakes.
The basic mechanic: a snapshot in time
A hard fork is a moment, not a process. At a specific block height — current rumors suggest around block 964,000, which projects to roughly August 2026 — the Bitcoin blockchain's state will be copied. Every address with a balance at that block will hold the same balance on Ecash, on a new chain that proceeds independently from then on.
If you hold 1 BTC at the fork block, you will hold 1 BTC on Bitcoin (the original chain) and 1 ECA on Ecash (the new chain). These are now separate assets, with separate prices, separate transaction histories, and separate communities. The same private key controls both, because the same UTXO set was inherited by both.
This is not a token airdrop. It is not a free distribution. It is the standard mechanic of every hard fork in Bitcoin's history — the same mechanic that created Bitcoin Cash from Bitcoin in 2017, that created Bitcoin SV from Bitcoin Cash in 2018, and that has occurred dozens of times in less famous splits. The technique is well understood. The execution details, however, vary considerably from fork to fork, and that is where the practical work begins.
The replay protection problem
This is the most important technical concept for fork users, and the one most people get wrong.
A replay attack is what happens when a transaction broadcast on one chain is valid on the other chain. Imagine the morning after the fork. You decide to sell your BTC for dollars at an exchange. You sign a transaction sending 1 BTC from your wallet to the exchange's deposit address. You broadcast it. Bitcoin nodes accept it. The transaction confirms on Bitcoin.
But here is the problem: that transaction is also valid on Ecash, because Ecash inherited the same UTXO set and the same signing rules. A malicious actor — or even just an automated bot — can take your signed Bitcoin transaction and rebroadcast it on the Ecash network. Your 1 ECA gets sent to the same exchange address. The exchange does not know what to do with it. Often it gets lost. Sometimes it gets stolen.
Replay protection is a consensus change that makes transactions on one chain invalid on the other. There are several technical mechanisms — different signature hash flags, different chain IDs, different opcodes — but they all accomplish the same thing: a transaction signed for Bitcoin cannot be replayed on Ecash, and vice versa. You can spend your BTC without affecting your ECA, and you can spend your ECA without affecting your BTC.
When replay protection is active: the two chains are practically independent. You can transact normally on either one. Most users never need to think about it.
When replay protection is missing or weak: every transaction is dangerous. Sophisticated users handle it with manual UTXO splitting (creating a transaction that is only valid on one chain, by including an output that references chain-specific data). Ordinary users get burned, often badly.
The 2017 Bitcoin Cash fork did include replay protection, and the split was relatively clean. The 2018 Bitcoin SV fork did not include strong replay protection initially, and many users lost coins. The lesson has been learned, and it would be surprising if Ecash launched without robust replay protection — but it is not yet confirmed publicly what mechanism the Ecash fork will use.
What we do not yet know
Here is where caution becomes essential. As of this writing, several critical details about the Ecash fork are still unconfirmed:
- The exact block height of the fork (rumored around 964,000, but not finalized)
- The specific replay protection mechanism (which sighash flag, which marker, which opcode)
- The list of wallets that will support Ecash on day one
- The list of exchanges that will support trading ECA
- The reference client release schedule and audit status
Rumors are circulating. Twitter is full of confident claims. Some of those claims will turn out to be wrong. Treat any specific technical detail you hear before August 2026 as provisional. Even details that come from people who should know are subject to revision as the codebase matures and the developer community converges on final specifications.
The authoritative sources for fork details are:
- ecash.com — the official project website, owned and operated by Paul Sztorc
- @truthcoin on X — Sztorc's personal account, where major announcements appear first
- Sztorc's Wednesday Twitter Spaces — weekly live discussions where he answers questions and clarifies technical details in real time
- truthcoin.info — the long-form essays where Sztorc explains his thinking in detail
Follow all four. The Wednesday Spaces are particularly valuable because they allow real-time clarification of rumors, and Sztorc is patient with technical questions even from non-experts.
Why you should NOT rush to claim ECA in the first days
This is the single most important practical advice in this essay. Do not import your Bitcoin private keys into the first Ecash wallet you find. Wait at least a week, ideally two.
The reasons are simple:
First, new clients have bugs. Even well-audited software has issues that only surface in production. The first few days of a new chain are the highest-risk period for any wallet implementation. Bugs that lose coins, leak private keys, or mishandle replay protection are most likely to appear during this window. Letting other people find these bugs first, at the cost of their coins, is a service they are performing for the rest of us, and you should not feel guilty about accepting it.
Second, fake clients appear immediately. Within hours of any major fork, malicious actors publish wallet software that looks legitimate but is designed to steal private keys. These fake clients are advertised aggressively on social media, often by accounts that look authoritative. The pattern is well-documented from every previous fork. Anyone who imports keys into a malicious client loses their coins on both chains, not just the new one.
Third, rushing yields nothing. Your ECA does not go anywhere if you wait. The UTXO set is fixed at the fork block. Your coins are safely controlled by your private key whether you claim them on day one or day thirty. The price of ECA on day one will almost certainly be wrong — too high or too low — and waiting a few days for the market to find equilibrium is usually the more profitable approach anyway.
The professional users — wallet developers, security researchers, large custody operators — will spend the first week stress-testing the software, finding the bugs, and reporting them. By the time the dust settles, you will have confirmed, audited tools to use. The cost of waiting two weeks is essentially zero. The cost of being early is potentially everything you hold.
A reasonable timeline looks like this:
- Day 0 (fork): Do nothing. Hold your private keys offline. Read updates from official sources only.
- Days 1-7: Watch the security researcher community. If problems emerge, they will be publicized quickly. If the launch is clean, that will become clear too.
- Days 7-14: Major wallets — Sparrow, Electrum, hardware wallet vendors — will release Ecash-compatible versions if they intend to. Wait for the wallet you already use to support Ecash, rather than installing something new.
- Day 14+: With audited tools and a clean launch confirmed, follow your wallet's documented procedure to access your ECA balance.
The custody choice: exchanges versus self-custody
If your BTC is currently on an exchange — Coinbase, Kraken, Binance, any major centralized custodian — your situation is different from a self-custody holder's, and the decision tree is more complex.
The optimistic case is that the exchange supports the Ecash fork. This means they hold your BTC through the fork, automatically credit your account with the corresponding ECA, and let you trade or withdraw it normally. Coinbase, for instance, did this for Bitcoin Cash in 2017. Kraken did the same. The mechanism is well-understood and exchanges that have done it before generally know how to do it again.
The pessimistic case is that the exchange ignores the fork. They keep your BTC, but they do not credit you with ECA. The ECA that "should" belong to you remains controlled by the exchange's hot wallet keys, and the exchange either keeps it for themselves or simply lets it sit unclaimed. This has also happened in past forks, and there is rarely meaningful legal recourse.
What you should do depends on which case you expect:
If you want to be certain you receive your ECA, withdraw your BTC to self-custody before the fork. This means moving it to a wallet where you control the private keys — a hardware wallet, a software wallet you trust, or even a paper wallet for cold storage. The cost is one on-chain transaction fee and the cognitive overhead of managing your own keys. The benefit is certainty: when the fork happens, you control both the BTC and the ECA.
If you prefer to stay on an exchange, start lobbying now. Tweet at their official accounts. Email their support. Post on their feedback forums. Exchanges respond to user pressure. The cost of supporting a fork is non-trivial for the exchange, but if they see significant demand, the decision becomes easier. Bitcoin Cash got listed everywhere because the user pressure was overwhelming. Smaller forks have been ignored because no one bothered to ask.
A reasonable hybrid approach: withdraw most of your BTC to self-custody, leave a small trading balance on the exchange, and lobby anyway. This gives you certainty on the bulk of your holdings while leaving room for the exchange to add Ecash support later.
Why self-custody is doubly valuable here
There is a deeper reason to take self-custody seriously around the Ecash fork, and it has nothing to do with ECA itself. Self-custody gives you access to the actual technology — drivechains — that makes Ecash interesting in the first place.
If you hold ECA in self-custody, you can experiment. You can move BTC into a privacy sidechain and transact with stronger anonymity than the Bitcoin main chain provides. You can use a smart contract sidechain to participate in lending, escrow, or prediction markets denominated in BTC. You can try a Truthcoin-style prediction market — the use case Paul Sztorc designed twelve years ago and never got to ship on Bitcoin.
None of this is possible on an exchange. Exchanges treat your ECA as a balance on their internal ledger. You cannot interact with sidechains through an exchange account, any more than you can interact with Lightning channels through one. The exchange is a layer on top of the chain that intentionally abstracts away the chain itself.
If you find the technical case for drivechains compelling — and most readers of this blog do — then self-custody is the only path that lets you actually use what you have been reading about. Holding ECA on an exchange is, in this sense, the same as holding BTC on an exchange in 2014 and never trying to send a transaction. You technically own the asset, but you have never met it.
Drivechains are the technology Bitcoin could have had if the political process had not blocked them for a decade. Ecash exists in part to give them a place to actually run. If you are going to hold ECA, you should also try the thing the chain was built for.
The learning curve for sidechain interaction will not be trivial in the first months. Wallets will be rough. Documentation will be incomplete. Some sidechains will be poorly designed and best avoided. But the ones that work will demonstrate something that has not existed in production before: programmable Bitcoin sidechains, secured by Bitcoin's miners, denominated in BTC, without launching a new monetary asset. That is worth experimenting with directly, not just reading about.
A summary checklist
For the practical reader, here is the entire essay compressed into action items.
Before the fork (now through August 2026):
- Follow ecash.com, @truthcoin on X, and the Wednesday Twitter Spaces
- If your BTC is on an exchange, decide: withdraw to self-custody, or lobby the exchange to support Ecash
- If you choose self-custody, set up your wallet, verify your backup, and practice with a small amount before the fork
- Treat all technical rumors as provisional until confirmed by official sources
- Do not pre-install any "Ecash wallet" software before the official client is released
At the fork (around block 964,000):
- Do nothing for the first few days
- Read security advisories from researchers you trust
- Watch which wallet vendors announce official Ecash support
- Confirm that replay protection is functioning as expected
After the fork (week 2 onward):
- Use the official Ecash client released through ecash.com, or a wallet vendor you already trust
- If you self-custody, follow the documented procedure to access your ECA balance
- If your exchange supports Ecash, you will see ECA appear in your account; if not, your withdrawal decision matters
- Once your ECA is accessible, explore the drivechain ecosystem — that is the entire point of the project
The fork itself is a moment. The interesting work happens in the years after, when the architecture finally gets to do what it was designed to do. Inheriting your Bitcoin is the easy part. Actually using Ecash for what makes it different — that is where the real opportunity lives.