From Passive Upgrades to Active Governance on Stellar

In the previous post, we argued that decentralization is not just about the number of validators on a network. It is about whether the network can keep serving users when the real world applies pressure.

That brings us to the practical question: if mission alignment, security, and geo-political resilience really matter, what should the ecosystem prioritize to reduce risk?

The answer starts by being honest about where decisions are actually made.

In any blockchain system, there is a practical question hiding underneath a lot of governance language: who is actually making the decision when the network changes, and how visible is that decision to everyone else?

In proof-of-work systems, that decision often happens implicitly through deployment. Operators upgrade, and the network moves.

In proof-of-stake systems where validators themselves control the stake, the story is often similar: deployment is still effectively the vote.

In delegated proof-of-stake systems, things get murkier. Validators may still be the ones deploying the change, but they are not necessarily aligned with token holders or end users.

That comparison matters because it highlights both the problem and the opportunity for Stellar.

Validator operators are not just passively running software. When they agree to a change to network settings, they arm their nodes to affirm it, thereby exercising judgment on behalf of a network that other people rely on. Instead of treating that reality as something implicit or leaving it hidden behind deployment mechanics, Stellar has an opportunity to do much more than most systems do today: make those decisions more explicit, more transparent, and more accountable.

That is not a weakness of the model. It is one of the opportunities created by a system where trust and identity are part of how agreement forms.

This becomes most obvious when the network has to change course under pressure.

Imagine a network outage caused by a bug.

The path to resolution sounds simple on paper: identify the issue, make a code change, review it, build it, deploy it, and restore quorum. In reality, those moments are messy. Distributed systems fail in complicated ways, and the pressure to act quickly is intense.

That is when bad shortcuts appear.

Review may be compressed. Changes may happen in places that are harder for the public to observe. Operators may feel pushed to follow the crowd rather than exercise independent judgment. The result may solve the immediate problem, but at the cost of transparency and trust.

But there is an equal and opposite failure mode.

A network can also hide behind a simplistic reading of “code is law” and treat obviously bad outcomes as untouchable just because the software produced them. That may sound principled, but from an end-user point of view it often is not. If a bug, exploit, or broken component pushes the network into behavior that nobody actually wants, pretending that those outcomes must simply stand is not neutral. It is still a choice.

That is not a sustainable model either.

Users should not have to fear decentralization because it makes crises slow to resolve, nor should they have to accept opaque coordination or passive fatalism as the price of acting quickly.

The better approach is to give the ecosystem clearer, more transparent ways to respond under stress.

If the network needs better ways to respond under stress, the next question is what that looks like in practice.

The first point is that this is a next step for the ecosystem, not a description of a finished model.

Today, when validator operators decide whether to arm their nodes for a vote, they often rely heavily on SDF to explain changes and frame the decision in front of them. That works for straightforward changes, but not every decision is purely technical. Some choices depend on business priorities, ecosystem impact, and the broader purpose of the network.

That is not something SDF can or should decide alone.

So one clear next step is to involve validators earlier and on more topics.

That should start with network settings, where the tradeoffs are often easier to understand: change a parameter here, and certain consequences follow over there. It should then extend to protocol changes, where the stakes are higher and the judgment required is broader.

The goal is to build the habit of active judgment across the validator set before the next crisis arrives.

That is what opinionated governance means here. Not endless debate, and not centralizing authority, but asking validators to take a more explicit, informed role in shaping how the network changes and how it responds when something goes wrong.

This also points to another important next step: expanding the set of tools available for transparent coordination.

Today, the existing onchain commands mostly fit into two buckets: code upgrades and settings updates.

That may not be enough for the full range of situations the network can face.

Some incidents call for more targeted tools. Quorum Freeze (CAP-77)—currently included in Protocol 26 “Yardstick” that validators will vote on May 6, 2026—is a useful example because it formalizes something validators have already had to do in practice: stop transactions from interacting with certain ledger entries in response to an emergency. That has already happened more than once, for very different reasons, including a protocol bug in October 2025 and a DeFi protocol exploit in February 2026. What CAP-77 adds is not a new category of intervention so much as a better way to carry it out: validators can vote faster, in a way that is fully transparent and auditable, to achieve the same containment outcome. It is not a complete answer to emergency response, but it points toward a broader idea.

Those tools matter not only because they can be used during a crisis, but because designing them ahead of time moves some of the hardest debate into periods where there is time to think carefully. The ecosystem can argue in advance about scope, limits, safety, and legitimacy. Then, when time is critical, the focus can shift from inventing a response under pressure to using already understood tools to contain and resolve the issue as quickly and efficiently as possible.

The important point is not any single mechanism. It is that these actions should be explicit, governable, and contestable.

Finally, active governance also means improving how validators participate in decisions. That should be part of the discussion going forward: how to evolve the way validators vote so that entities can be fully engaged on the topics they care most about, while being less involved in others.

The goal is not less accountability. It is a model of governance where engagement is more deliberate, more meaningful, and better matched to the decisions being made.

If the ecosystem gets this right, it gets something valuable in return.

It becomes possible to handle a wider range of scenarios with more transparency and less improvisation.

That includes obvious cases like critical bugs in the core protocol. But it may also include harder ecosystem situations, where slowing or pausing certain activity for a time is better than letting damage spread unchecked while the relevant actors scramble to react.

That is the real promise here.

Not governance for its own sake. Not emergency powers for their own sake. But a more mature form of decentralization: one where the network can move, judge, contain, and recover in ways that are fast enough to protect users and transparent enough to remain worthy of trust.

That is where Stellar is going next.