Forking
Overview
Ergo's view is that disruptive hard forks should be avoided unless absolutely critical. Ergo implements various measures to prevent hard forks, such as pushing complexity to the application layer and enabling many things to be implemented via soft-forks.
BackIf a supermajority (90%+) of the network accepts a new feature, it is activated; however, old nodes that do not upgrade continue to operate normally and skip over this feature validation.
Velvet Forks
Minority‑upgrade fork enabling gradual deployment via NiPoPoW interlinks; stays compatible with non‑upgraded nodes.
Soft Forks
Requires a subset of nodes; miner‑enforced via protocol rules (e.g., EIP‑37 re‑emission) and activatable with 90% miner support.
Hard Forks
Requires all nodes to upgrade; used only when backward‑compatible approaches are insufficient.
Additional Information
For more information, refer to the Ergo Improvement Proposals (EIPs).
Fork Prevention Measures
- Pushing complexity to the application layer: By keeping the core protocol simple and pushing complexity to the application layer, Ergo reduces the need for frequent protocol-level changes that could lead to hard forks.
- Enabling soft-forks: Many features and improvements can be implemented through soft-forks, which allow for backward compatibility and gradual adoption without disrupting the network.
Fork Activation Process
- Proposal and Discussion: The proposed change is discussed and evaluated by the Ergo community and developers.
- Consensus and Approval: If the proposal gains consensus and is approved, it is scheduled for implementation.
- Fork Type Determination: Based on the nature of the change, it is determined whether a velvet-fork, soft-fork, or hard-fork is required.
- Activation: If a supermajority (90%+) of the network accepts the new feature, it is activated. Old nodes that do not upgrade continue to operate normally and skip over the new feature validation.