Executive Summary
Avalanche pre-consensus gives fast convergence and lets the network activate policy and parameter changes without splitting the canonical chain. However, it cannot make two contradictory validation rules true at once. If nodes can’t safely run both rule sets during a transition, a hard fork is required.
What Fork-Free Upgrades Cover
- Parametric changes: dynamic block size ceilings, relay limits, fee/incentive tuning.
- Range-based operation: binaries can accept a safe range of values.
- Consensus activation: Avalanche selects/activates the chosen value after supermajority signaling.
Why Hard Forks Still Exist
Avalanche can coordinate which rule set the network prefers, but it cannot “juggle” two universes of validity when they are mutually exclusive and the binaries do not implement safe dual logic.
- New transaction format (critical serialization/consensus change): if old nodes cannot parse/verify new txs, validity diverges.
- Deep changes to script system or signature semantics: new opcodes/algorithms can turn previously valid scripts invalid (and vice versa).
- Rule contradictions: any change where a block/tx is valid under A and invalid under B, with no backward compatibility.
Decision Framework: Do We Need a Hard Fork?
- Compatibility: can old and new nodes accept the same blocks/txs during a grace window?
- Dual-logic safety: can binaries ship with “accept both” logic without opening consensus holes?
- Scope: parameter/policy vs. consensus primitive (serialization, scripts, signatures).
- Validation symmetry: does the new rule only expand acceptance, or does it contradict old criteria?
- Risk: would running both paths add ambiguity, malleability, or attack surface?
Examples Table
| Change Type | Typical Examples | Fork-Free? | Reason |
|---|---|---|---|
| Policy / Parameter | Dynamic block size ceilings, mempool/relay rules, fee & incentive tuning | Yes (Avalanche) | Nodes operate across a safe range; Avalanche activates the chosen setting. |
| Serialization / TX Format | New tx structure or digest algorithm without dual support | No (Hard Fork) | Old nodes can’t parse/validate new txs; validity sets conflict. |
| Script / Signature Semantics | New opcodes, changed script verification, new signature scheme | No (Hard Fork) | Previously valid vs. invalid diverges; no safe dual acceptance. |
| Consensus Rule Contradiction | Redefining block validity so A-valid becomes B-invalid (no back-compat) | No (Hard Fork) | Mutually exclusive rule sets; Avalanche can’t reconcile. |
Diagram: Overlapping vs. Disjoint Validity Sets
Rollout Best Practices
- Classify proposals: parameter/policy vs. structural/consensus.
- Prefer compatibility bridges where safe (grace windows, dual acceptance).
- Use Avalanche signaling & supermajority thresholds for parametric upgrades.
- For hard forks: publish activation plan, testnet phases, and migration docs for wallets/exchanges.
- Communicate clearly: fork-free means no split for routine upgrades—not that forks are impossible.
One-Paragraph Summary
Fork-free upgrades let eCash evolve rapidly for policy/parameter changes under Avalanche pre-consensus. But when a change redefines validity in a way that old and new nodes cannot both accept—without a safe compatibility bridge—a hard fork is the clean, explicit mechanism. Avalanche can coordinate preference; it cannot make incompatible rule sets simultaneously valid.