Protocol changes on a network with no owner require voluntary adoption by independent operators, which is where most of the difficulty lies.
Proposal processes
Most networks have a formal improvement proposal process with defined stages.
Which produces a public specification that implementers can build against.
Proposals are numbered, publicly archived and discussed openly, which makes the process traceable.
Backwards-compatible changes
Changes that tighten rules can be adopted incrementally, since old nodes still accept new blocks.
Which allows gradual deployment without a coordinated switch.
Old nodes lose full validation without noticing, which is the trade-off.
Breaking changes
Changes that loosen or alter rules require all nodes to upgrade or the network splits.
Which demands coordination across exchanges, wallets, miners or validators, and infrastructure providers.
Activation is generally scheduled by block height or timestamp with substantial notice.
Testnets
Changes are deployed to test networks first, sometimes several in sequence.
Which has repeatedly caught issues that would have been serious on the main network.
Testnet failures during upgrade rehearsals are a normal and useful part of the process.
Shadow forks
Testing against copies of real network state rather than synthetic test data.
Which surfaces issues that only appear at real scale and with real contract deployments.
Client implementations
Multiple independent implementations must each implement the change identically.
Which is a strength for resilience and a source of consensus bugs when they diverge.
Differences in edge case handling have caused chain splits on major networks.
Who actually decides
Node operators, by choosing what software to run.
Which is why developer proposals are not commands and why contentious changes fail.
Exchanges and large infrastructure providers have disproportionate practical influence because of the users they represent.
What users should do
Self-custodied assets generally require no action, since keys are unaffected.
Node operators must upgrade before activation.
Which is the main practical requirement, and announcements of an upgrade requiring users to move funds are a reliable indicator of fraud.
Activation mechanisms
Some upgrades activate at a fixed height, others require signalling by a proportion of block producers.
Which changes who effectively holds a veto.
Signalling mechanisms have produced standoffs where activation stalled for extended periods.
User-activated approaches
Where node operators enforce a rule regardless of producer signalling.
Which has been used to break deadlocks and demonstrated that economic nodes hold real power.
It carries chain split risk if adoption is partial.
Exchange handling
Venues generally suspend deposits and withdrawals around activation.
Which is standard practice and is announced in advance.
Trading generally continues, and this is the point at which most users notice an upgrade at all.
Post-upgrade monitoring
Block times, participation rates and client error reports are watched closely for hours afterwards.
Which has caught issues requiring rapid client patches on more than one occasion.
What can go wrong
Client bugs causing consensus divergence, insufficient adoption, and unforeseen interactions with deployed contracts.
All three have occurred on major networks and were resolved through coordinated response.
Governance models
Some networks vote on protocol changes on chain with automatic execution.
Which resolves coordination faster and concentrates decision-making among token holders.
Others deliberately keep the process off chain and social, arguing that formalising it creates capture risk.
Contentious splits
Where a substantial minority rejects a change, both chains can persist.
Which has produced lasting separate networks with separate communities.
Exchanges deciding which chain retains the original ticker is a consequential and informal power.
Replay protection
Preventing a transaction valid on one chain from being replayed on the other.
Which is a specific technical requirement in a split.
Its absence has caused user losses in past events and is now standard practice.
Developer funding
Who pays for protocol development varies between foundations, grants, protocol treasuries and commercial sponsors.
Which affects independence and priorities in ways that are worth being aware of.
Funding arrangements are generally public.
For most users
Upgrades are invisible, and the only genuine risk is acting on fraudulent instructions claiming otherwise.
Scams around upgrades
Messages instructing users to migrate tokens or validate wallets ahead of an upgrade.
Which are fraudulent without exception.
Genuine upgrades require nothing from holders of self-custodied assets, and this is worth stating plainly.
Following an upgrade
Official client repositories and protocol foundations publish schedules and requirements.
Which are the sources worth reading, since coverage elsewhere is frequently inaccurate.
Infrastructure readiness
Node providers, indexers and wallet backends must all be updated alongside the network.
Which is where most user-visible disruption originates rather than from the protocol itself.
Applications relying on a single provider inherit that provider's readiness.
Historical record
Major networks have executed substantial upgrades without loss of funds, which is a meaningful engineering achievement.
For anyone holding assets in their own custody, the correct action during an upgrade is generally nothing at all, and any message suggesting otherwise should be treated as fraudulent.