User-Led Emergency Hardforks
In The Five Component Model we describe a key role of users is their governance capability to initiate a user-led hardfork in the event of an emergency.
In the context of Crosslink, we believe it's beneficial to gain community agreement on a norm for when such emergency hardforks are called for. Having an up-front agreement can help reduce confusion, debate, or contention during specific kinds of emergencies.
A Proposed Governance ZIP for the Use of an Emergency User-Led Hard Fork to Correct Layer-1 Security Failures
An emergency user-led hard fork is an extraordinary intervention that reflects a core value of cryptocurrencies: the ability of users to assert sovereignty over the protocol in response to a failure of its most fundamental security guarantees. This form of intervention is distinct from ordinary network upgrades, which change consensus rules prospectively and only with broad user acceptance. Because an emergency user-led hard fork carries significant social, economic, and political consequences, the Zcash community should establish a clear and limited social consensus in advance about when it is legitimate.
This Governance ZIP establishes that a user-led hard fork should be considered only to rectify and hold consensus operators accountable for failures of the layer-1 consensus system itself, specifically failures to prevent rollback or double-spend attacks, failures to ensure network liveness or availability, and failures to ensure censorship resistance or freedom of participation, including situations in which would-be miners, finalizers, or stakers are being systematically censored or prevented from participating in block production, finalization, or staking. These grounds are intended to capture violations of finality, liveness, and censorship resistance at the base layer and define the exclusive scope of legitimate emergency intervention under this framework.
This Governance ZIP explicitly rejects the use of an emergency user-led hard fork to mitigate harm arising from application-layer failures or to alter outcomes that, while undesirable, do not constitute violations of layer-1 security properties. It does not apply to wallet bugs, smart contract failures, bridge exploits, custodial failures, key management errors, user mistakes, or other application-level attacks or economic losses. A user-led hard fork must not be used to reverse or “make whole” thefts or hacks, to rewrite application-layer outcomes, or for purposes analogous to Ethereum’s DAO hard fork, the SUI blockchain hard fork, or similar interventions motivated by dissatisfaction with economic outcomes rather than base-layer security failure. Control over a large share of hashpower, finalization power, or stake does not itself constitute a violation, and a user-led hard fork must not be used to disadvantage miners, finalizers, or stakers solely for being large, nor to resolve governance disputes or enforce social policy outcomes.
This Governance ZIP also does not apply to ordinary prospective rule changes adopted through standard upgrade processes, including the introduction of new transaction types, new features, or protocol cleanups. It does not apply to monetary policy, economic parameters, or protocol design choices such as shielded pool deprecations, fee changes, new fee mechanisms, staking or unbonding parameters, or funding mechanisms. All such matters fall within the domain of future community governance and must be decided through ordinary governance and network upgrade processes, not through an emergency user-led hard fork justified under this security framework.
Even when one of the legitimate layer-1 security grounds is clearly met, any emergency user-led hard fork should be narrowly scoped to address only the specific security failure, avoid unnecessary collateral changes, minimize downstream disruption, and preserve continuity of honest user state where technically feasible. Possible interventions may include correcting a critical consensus bug, changing a security-critical consensus mechanism that failed to prevent the violation, or, where directly relevant, neutralizing counterfeit or illegitimate base-layer state created by the failure. The objective of such intervention is the restoration of neutral protocol function, not broad protocol re-engineering under crisis conditions.
This Governance ZIP is a proposed expression of social consensus. Its force derives solely from the degree to which the Zcash community chooses to adopt and uphold it. Whether any particular emergency intervention is ultimately acceptable will depend not only on technical criteria, but also on whether it aligns with the community’s explicit or assumed social values. By committing to these constraints in advance, the community strengthens credible neutrality, reduces moral hazard, and increases confidence that the protocol will not be arbitrarily rewritten.