Top Bitcoin dev is launching a new BTC fork giving holders new eCash, but claiming it may be a real risk

Paul Sztorc, LayerTwo Labs CEO and longtime Bitcoin developer, is planning an August 2026 Bitcoin hard fork called eCash, targeted around Bitcoin block 964,000 . His April 24 announcement described a new chain that would copy Bitcoin history , give holders 1 eCash for every 1 BTC at the split, and launch with a Bitcoin-Core-like base layer mined with SHA-256d alongside Drivechain-style sidechains. For ordinary Bitcoin holders, the practical question is more specific than the backlash. The fork can create a new asset, new confusion, and new operational decisions, while BTC balances remain governed by Bitcoin software, Bitcoin consensus, and Bitcoin private keys. In a later clarification , Sztorc said the current eCash plan would give Satoshi Nakamoto 600,000 eCash rather than 1.1 million eCash. He also repeated that BTC balances are untouched by eCash and that moving BTC always requires Bitcoin software plus the relevant Bitcoin private key. That distinction sets the holder map. A Bitcoin holder can ignore a fork and still keep the same BTC. The unresolved issue is whether eCash becomes a supported asset that exchanges, wallets, custodians, miners, and tax records have to process. Until that happens, the controversy is mostly about legitimacy, incentives, and precedent on a new ledger. What eCash would copy from Bitcoin The proposed chain starts from a familiar hard-fork mechanic. At the fork height, Bitcoin history would be copied into a new network. A wallet holding 4.19 BTC at the split would have 4.19 eCash on the new chain, according to Sztorc's announcement. Holders could keep, sell, or ignore those coins if the new chain launches and if they can safely access them. The base-chain pitch is intentionally close to Bitcoin. Sztorc described the eCash layer 1 as a near-copy of Bitcoin Core, mined with the same SHA-256d algorithm, with a one-time difficulty reset to its minimum value at launch. He also said the chain would activate BIP300 and BIP301 through CUSF, a route meant to bring Drivechain-style sidechains into eCash without changing Bitcoin itself. The Drivechain component should stay in the background for holders. BIP300 describes hashrate escrows for sidechains, while BIP301 describes blind merged mining, a design under which SHA-256d miners can collect revenue from other chains without running those chains' full software. Those mechanics explain why Sztorc wants a separate eCash network. BTC remains governed by Bitcoin mainnet rules. Code readiness is a separate threshold. The public LayerTwo Labs CUSF enforcer repository showed active development, while LayerTwo Labs' download page offered BitWindow software related to the Drivechain stack. Final eCash launch software, replay rules, and user-grade splitting tools still need verification before ordinary holders can treat the fork as operational. Preserving BTC requires no claim action during the proposal phase. Holders can leave seed phrases private, avoid importing keys into new software, and ignore claim pages while the chain remains unlaunched. The chain has to exist first, then the ecosystem has to decide whether it will recognize the forked coins. That sequencing is the difference between a theoretical allocation and a usable asset. Those same practical gates determine whether the 1:1 allocation becomes anything more than a paper balance in a copied ledger. The Satoshi allocation fight lives on the new chain The controversy grew out of the initial funding design. Reporting and Sztorc's own post described a plan to manually reassign fewer than half of the eCash coins corresponding to the presumed Patoshi-pattern coins, often framed around 1.1 million BTC, to early investors or supporters. The Bitcoin mainnet coins would stay where they are. The dispute is over whether a fork should edit the copied version of those balances before launch. Sztorc's latest clarification sharpens that point instead of removing it. He says eCash would gift Satoshi 600,000 eCash rather than 1.1 million, a figure closer to the lower Patoshi estimate than the common million-plus framing. That still leaves the core objection. A straight 1:1 copy would assign every copied coin to the same keys that held the BTC at the split, while the current eCash proposal would choose a different treatment for part of the dormant copied balance. Bitcoin's social contract treats signatures and private keys as the boundary of control. A new chain can choose different rules, but a chain that reallocates dormant copied coins tells users something about how its own ledger treats old balances. Critics see that as a precedent problem. Sztorc has argued that a pure fork can leave contributors undercapitalized before launch, creating a chain that starts as a zombie project. The size of the Satoshi-linked pool also deserves care. BitMEX Research found strong evidence of a dominant early miner, but argued that the evidence is less robust than the common million-plus framing suggests. Its analys