The idea of Bitcoin sidechains, first introduced by researchers at Blockstream and later materialized by Rootstock in 2018, represents one of the most promising paths to extend Bitcoin’s functionality without altering its ethos or base-layer properties.
Drivechains, more precisely described as hashrate escrows or hashrate locks, are one of the approaches proposed to enable more decentralized sidechains. In 2016, I introduced an early drivechain proposal based on the COUNT_ACKS opcode. Later that same year, Paul Sztorc presented his own drivechain design. Since then, the concept of hashrate escrow has been widely discussed and debated across Bitcoin forums and conferences. Ultimately, no consensus emerged to incorporate it into Bitcoin, and the community continued exploring alternative approaches to sidechains. More recently, the emergence of BitVM and platforms such as BitVMX has renewed interest in trust-minimized sidechain constructions.
However, Paul Sztorc did not accept the lack of consensus around his proposal. He founded a company to pursue drivechains and continued development using investor funding. From a startup perspective, this path predictably creates a competitive dynamic between the proposed system and Bitcoin itself. Instead of deploying sidechains using alternative bridging mechanisms to attract real users and demonstrate product–market fit—potentially strengthening his position within the Bitcoin ecosystem, he prioritized the technology over adoption. As a result, the success of his company has become tightly coupled to the deployment of drivechains, making that outcome effectively irreversible, regardless of whether it is the best direction.
Before proceeding, it is important to clarify that the eCash project is not a Bitcoin hard fork as some have claimed. eCash is a new blockchain. It is not a Bitcoin hard fork because
- it does not attempt to appropriate the Bitcoin brand, and
- it distributes a new token to bitcoiners rather than directly extracting value from them.
However, there are three critical design choices that makes eCash hostile and harmful to bitcoiners:
- eCash cannot be merge-mined with Bitcoin (even if eCash sidechains can be merge-mined with eCash!) so it competes with Bitcoin hashrate.
- eCash transaction replay protection is only partially implemented (it does not clearly separate the domains of transaction signatures).
- eCash initial coin distribution is not an airdrop, as claimed, but a forkdrop.
An airdrop typically distributes new tokens based on a snapshot of an existing ledger—account balances in EVM systems or the UTXO set in Bitcoin, while ensuring that transactions on one chain cannot be replayed on another. This is not the mechanism being used here: bitcoin transactions are valid on both chains until an eCash transaction breaks this entanglement. I refer to this approach as a forkdrop.
From the three design decisions mentioned follow several serious consequences, many of which are highly controversial and, in my view, detrimental to the broader ecosystem:
- eCash mining decreases Bitcoin’s security budget and can destabilize both chains.
This is a direct consequence of eCash not being merge-mined with Bitcoin. While eCash internal drivechains can be merge-mined with the eCash base layer, the base chain itself operates as an independent proof-of-work network competing for SHA-256 hashpower. This design choice directly undermines Bitcoin’s security model: instead of extending Bitcoin’s security budget, it diverts it into a parallel chain.This creates structural risks. Competing for the same hashpower can lead to oscillations in mining allocation—similar to what has historically occurred between Dogecoin and Litecoin before stable merge-mining equilibria emerged. Such oscillations can destabilize both networks in the short term and weaken their security assumptions. More broadly, the approach is divisive: rather than aligning incentives to reinforce Bitcoin as a single security anchor, it fragments them across competing systems. - Forkdropping does not help bitcoiners and instead exposes them to significant risk.
Claiming the forkdrop generally requires moving bitcoins from cold storage to hot storage and executing scripts created by unknown eCash developers rather than trusted Bitcoin developers, often on less secure hardware. There are many ways this process can fail, and users may end up losing both their bitcoins and their eCash tokens. - Forkdropping is not a fair distribution mechanism.
The custodians controlling UTXO keys are often not the rightful economic owners, but intermediaries. Because institutional bitcoin custody typically involves strict security procedures, those intermediaries may be unable or unwilling to split funds and recover the associated eCash coins. This places users who hold bitcoin through custodians at a disadvantage. If users attempt to withdraw funds to self-custody in order to claim the forkdrop, they may lose the security protections the custodian provides. The entire splitting event creates disruption. Even if intermediaries can perform the split, the procedures may be risky and largely untested, since such events occur only rarely. - The splitting problem is especially severe for highly secure sidechains such as Rootstock.
Coins in these systems may be protected by HSM-based custody systems that do not expose private keys by design. In that case, splitting funds may require a hard fork of Rootstock itself to introduce a one-time migration or splitting procedure. That would require months of planning, and testing such procedures is inherently difficult. If the Rootstock community does not permit this, then some users may attempt to capture the sidechain’s share of eCash by pegging in bitcoin-only UTXOs and pegging out coins valid on both chains. Another possibility is that users rush to peg out before the UTXO snapshot date, depleting the vault UTXOs because change outputs must confirm before reuse. This could create an unnecessary run to exit before the deadline. Similar issues could affect other systems such as Citrea and Liquid Network. - eCash is a premined coin.
Early investors may receive coins instantaneously and without any vesting mechanism. That exposes all other participants to greater volatility and uncertainty, while creating pressure to act quickly. Rushed decisions in these contexts often lead to mistakes and loss of funds. - Paul chose to use Satoshi’s coins (those in the Patoshi pattern I identified).
In my view, this is morally objectionable and unnecessary. New coins could have been created to compensate early investors instead of allocating value taken from an existing party. Even if one argues that the owner may be deceased or permanently absent, nobody truly knows. - Replay protection was not fully implemented.
Paul did not provide replay protection for Bitcoin transactions, but only for eCash transactions. This means bitcoin users may accidentally lose their eCash forkdrop simply by transacting normally on Bitcoin. That places pressure on users to take defensive action, increasing the likelihood of mistakes and losses. The eCash transaction format should have been changed so that signatures could never be valid on both chains. - The proposed drivechain design is not the best possible implementation.
I am not particularly satisfied with the BIP he proposed. Back in 2016, I proposed an alternative drivechain BIP that I believe is more flexible and better aligned with the stateless nature of Bitcoin Script [1]. In my view, the Bitcoin community’s rejection of BIP300 was not only about opposition to the concept of drivechains itself, but also about the fact that the proposed implementation was far from the best possible design.
To summarize, I strongly disagree with the eCash fork on technical, moral, and user-fund security grounds.