On 22 August 2026, the eCash network is expected to launch by creating a new blockchain that distributes ECX tokens based on Bitcoin ownership. Unlike a traditional airdrop, this is effectively a forkdrop: Bitcoin transactions remain valid on both chains until coins are actively split. This creates technical and operational risks for Bitcoin infrastructure, including Rootstock (read more about how the eCash fork can harm the Rootstock blockchain and its users here).
The BTC held in the Rootstock PowPeg bridge will also become associated with ECX tokens. Because the PowPeg secures funds using Hardware Security Modules (HSMs) that do not expose private keys, safely splitting those assets before the fork would require a protocol upgrade that cannot be completed before the launch date.
If Rootstock takes no action, users may lose the economic value associated with the ECX linked to their rBTC holdings, while the bridge may experience a run-to-the-peg as users or third parties attempt to capture those assets through normal peg operations.
This proposal recommends a best-effort, community-governed recovery process. If the ECX allocation associated with the Rootstock bridge is delivered as proposed by the eCash project, it would be temporarily held in a community-controlled multisignature wallet and distributed to eligible Rootstock users according to their rBTC holdings at the time of the fork.
The proposal asks the community to approve:
a best-effort recovery and distribution process;
temporary community custody of the ECX allocation;
transparent eligibility and distribution rules;
governance over operational costs, claims, and unclaimed tokens.
This proposal does not constitute an endorsement of the eCash network. Its sole objective is to protect Rootstock users and preserve confidence in the Rootstock PowPeg bridge.
Here is a document with the full proposal. We have a very short time window to act (5-days at most) before they close their release source code. Please comment on this thread if you have a better idea or suggest any changes.
Can you explain (1) a bit more ? What is an “ECX contract” ? The Powpeg won’t have any available holdings of ECX because it cannot transfer the ECX tokens. The HSM won’t allow it without proof of work.
The Powpeg won’t have any available holdings of ECX because it cannot transfer the ECX tokens.
Yes, I don’t disagree that Paul needs to manually allocate the ECX to Rootstock. But my point is, he should allocate it to a Hashrate escrow, as one of the Drivechains that are pre-registered without a “Propose” step.
Can you explain (1) a bit more ? What is an “ECX contract” ?
Once the ECX is held in a hashrate escrow, withdrawing them will need a smart contract on Rootstock, where
the RBTC ownership snapshot is copied to grant users “bridged” ECX
allow users to make a withdraw transaction, which then is actually honored (or not) by the miners on eCash
Optionally allow for future pegins from eCash with Bip300 rules.
I don’t think we need to worry about Bip301, miners on eCash will have to run rskj or query an existing rpc node.
I think my proposal replaces this:
If that allocation is successfully delivered, the proposal recommends:
receiving the ECX into a community-controlled multisignature wallet;
temporarily holding custody until predefined distribution conditions are met;
distributing the ECX to eligible Rootstock users according to their rBTC holdings at the time of the fork;
conducting the entire process transparently under community oversight.