How a network upgrades itself, and who actually decides

Protocol rules change through software, and software changes when the people running it install a new version. Every governance arrangement in this field, formal or informal, is ultimately a way of deciding what goes into that release and when it activates. The decisive power sits with whoever chooses to run the code, which is a less tidy answer than either the token-voting or the developer-authority story.

Off-chain governance: proposals, clients, activation

The dominant pattern on the largest networks has no on-chain vote at all. A change is written up as a numbered improvement proposal describing the mechanism and its rationale, it is argued over in public forums and developer calls, it is implemented in the independent client implementations, it is tested on a testnet, and it is activated on mainnet at an agreed block height or epoch as part of a bundled upgrade. Ethereum has run this process repeatedly, including EIP-1559 in 2021, which replaced first-price fee auctions with an algorithmic base fee that is destroyed, and the 2022 Merge, which switched consensus from proof of work to proof of stake without interrupting the chain.

Nothing in that process is a vote in the ordinary sense, and the informal parts are where the real influence lives. Whoever maintains a widely used client decides what the release contains. Whoever funds those maintainers has standing. Whoever operates large amounts of stake or hash power decides whether a change that requires their cooperation can activate. This is genuine governance; it is simply not written down in the protocol.

On-chain governance: token voting

Other networks put the decision on the ledger. Holders of a governance token vote on proposals, a quorum requirement guards against decisions made by a handful of participants, and passing proposals may execute automatically after a timelock delay that gives users a window to exit before the change takes effect. The appeal is legibility: the rules for changing the rules are themselves code, and the outcome is verifiable.

The mechanism has documented weaknesses that should be stated rather than glossed. Voting power is proportional to holdings, so a concentrated distribution produces concentrated control regardless of how many wallets exist. Participation is often low, which lowers the effective threshold for control. Vote weight can sometimes be borrowed rather than owned, and combining borrowed weight with an automatic execution path is the core of a governance attack. Where a protocol treasury holds significant assets, control of the vote is control of those assets, which raises the stakes of every weakness above.

Who can actually stop a change

Several parties can stop a change in practice, and they are not the same in every network.

• Operators of full nodes, who can decline to upgrade and will then reject blocks that use the new rules. In a contested hard fork this is how a chain splits rather than changes.
• Miners or validators, whose cooperation is required for activation mechanisms that depend on producer signaling, and who have direct financial exposure to changes affecting their income.
• Exchanges and custodians, which decide which chain retains the original ticker after a split, and thereby which side inherits the name and most of the liquidity.
• Application developers and large users, who determine where activity goes and can make a technically successful upgrade commercially irrelevant.

A soft fork shifts this balance because it is backward compatible: non-upgraded nodes accept the new blocks, so the change can proceed without their explicit consent. That is why the choice between soft and hard fork is itself a governance decision, not merely a technical one.

The sharpest historical illustration of where authority actually sits came in 2016, when Ethereum hard forked to reverse the effects of an exploit against a large contract holding user funds. The change was implemented, activated, and adopted by most participants, and a minority continued running the unmodified rules; that minority chain persists as a separate network with its own asset. Two facts follow from the episode, and they point in opposite directions. A sufficiently coordinated group can change outcomes that had already been recorded, and a group that declines to follow cannot be compelled to, because the software on their machines is the only thing that decides what they accept.

Foundations, funding and the awkward part

Most large networks have a foundation or equivalent entity holding assets and funding development. This is usually necessary — protocol work has to be paid for — and it concentrates practical influence in a body that no formal governance process elected. Comparable questions arise wherever an upgrade path exists at all: a system whose contracts can be replaced by a key holder has upgradeability risk, meaning the rules a user relied on can be changed by a party the user did not choose. That risk is not a defect of any particular project; it is the price of being able to fix things, and the honest treatment is to document who holds the keys and what delays apply.

What to look at when researching a network's governance

Formal documents describe the intent; distribution and activity describe the reality. Node count and the Nakamoto coefficient indicate how many independent parties would have to agree for a change to stick. Validator count indicates the size of the producer constituency. Development activity figures such as recent commits and contributor counts indicate whether maintenance rests on a broad group or on a few people, which is one of the more durable governance facts about any codebase. All of these are estimates with published methods, and none of them is a quality score.

The last lesson in this track covers systems built on top of a base chain, where the governance questions above reappear in a sharper form. Scheduled upgrades and activation dates are listed on the calendar, and the risk pages cover upgrade keys and concentration in more detail.