How a Protocol Upgrade Actually Ships

Upgrade coverage tends to jump from “proposed” to “activated” with little in between. The intermediate stages are where timelines actually get set, and they are all public.

The stages

Proposal. A specification is published in the network’s improvement process. On Ethereum these are EIPs; other networks have equivalents. At this stage a proposal is an idea with a number.

Discussion and revision. Core developers review, raise objections, and the specification changes. Most proposals never leave this stage, which is the process working rather than failing.

Inclusion in an upgrade. Networks group changes into named upgrades. Inclusion in the scope of an upgrade is the first meaningful commitment, and scope is frequently cut as the date approaches.

Client implementation. Each independent software implementation writes the change. Multiple clients are a security property and a scheduling constraint, since the upgrade proceeds when all of them are ready.

Testnet deployment. The upgrade activates on test networks first, usually in sequence. Problems found here routinely delay the mainnet date.

Mainnet activation. Specified as a block height or a timestamp. Node operators must update before it. Those who do not are left on a chain the rest of the network has abandoned.

Where delays come from

Almost always client implementation or testnet results. A testnet activation that produces a consensus failure resets the timeline by weeks.

Scope reduction is the usual response to schedule pressure. A proposal that was “in the next upgrade” for a year and is now “under consideration for the one after” has been cut, and the announcement of that is usually quieter than the announcement of its inclusion.

What to watch instead of headlines

The specification repository shows status. Client release notes show what is implemented. Testnet activation dates are published and are the most reliable leading indicator of a mainnet date.

Anyone wanting an honest timeline should read those three rather than coverage, which reports the optimistic version at every stage.

What upgrades mean for holders

Usually nothing. A holder using a wallet or an exchange takes no action. Infrastructure operators update; users do not notice.

Occasionally, action is required. If you run a node, you must update before activation. Wallet users may need an application update to support a new transaction type.

Rarely, a chain splits. When a change is contested and a meaningful minority continues running the old rules, two chains exist afterwards. This is uncommon and well telegraphed when it happens.

The reliable rule for an ordinary holder

Assets held at a venue are handled by the venue. Assets in self-custody generally need nothing beyond keeping wallet software current.

Where an upgrade does require user action, exchanges publish notices in advance and typically suspend deposits and withdrawals for a short window around activation. Platforms serving retail customers, including retail venues covering the pair, post these notices before the event, and reading them is the entire preparation required.