Decentralization Isn't All-or-Nothing

Decentralization has become one of the most important ideas in blockchain. But I've been thinking about a question we don't always ask: Does every system need to be fully decentralized, or does the answer depend on what we're building?

I believe we need to look beyond the idea that more decentralization is always better. We should examine how a system distributes power, what it needs to achieve, and what happens when something goes wrong.

Canton Network offers an interesting case study.

Decentralization Is More Than a Label

When we describe a network as decentralized, what do we actually mean?

Are we talking about who operates its infrastructure? Who makes decisions? Who can participate? Who develops and maintains the software? Or how much influence one organisation has over the system's future?

These are different questions, and their answers may not be the same.

A network can distribute transaction ordering across multiple operators while keeping participation permissioned. It can have collective governance while relying heavily on a small number of technical contributors.

Therefore, counting validators alone doesn't tell us the whole story. We need to understand how independently they operate and how power is distributed among them.

What Canton Teaches Us

Canton uses distributed consensus across Super Validators to support its Global Synchronizer. Its governance arrangements also require collective participation in important decisions.

At the same time, participation in its MainNet infrastructure is permissioned. Organisations cannot simply join the consensus infrastructure without following the network's onboarding process.

This creates an interesting balance: distributed infrastructure and collective governance coexist with controlled participation.

Neither feature tells us everything about Canton's decentralization. Instead, they show why we need to evaluate the network across several dimensions.

The broader ecosystem also includes more organisations than the infrastructure node identities listed in Canton's public MainNet configuration. This distinction matters because being associated with the Super Validator ecosystem is not necessarily the same as operating an independent consensus node.

The important question is not simply how many participants a network has. It is how much independent control those participants actually exercise.

The Digital Asset Question

Digital Asset is an important contributor to Canton and operates two node identities in the public MainNet configuration.

However, the published governance process requires a collective threshold for relevant decisions. Digital Asset's two identities alone are not enough to meet the current nine-of-thirteen threshold.

This distinction matters. Being a major contributor is not the same as having unilateral authority over every network decision.

But another question deserves attention: What would happen if Digital Asset disappeared tomorrow?

The network's multi-operator architecture and available open-source software provide a plausible path to continued operation. Yet continued operation is not the same as uninterrupted development, maintenance, and incident response.

The departure of a major technical contributor could create challenges even if the network's other operators remained active.

We should therefore avoid two extremes: assuming Canton would immediately collapse without Digital Asset, or assuming its departure would make no meaningful difference.

The more useful question is how effectively the network could continue operating, making decisions, and evolving without depending on any single organisation.

Does Financial Infrastructure Need Maximum Decentralization?

Consider the requirements of financial infrastructure.

Privacy, security, accountability, regulatory compliance, and operational reliability can all be important. In some cases, identifying participants and controlling access are deliberate design choices.

These requirements do not automatically make decentralization impossible. Nor do they mean centralization is always preferable.

Instead, they create trade-offs that must be considered carefully.

A system can distribute critical powers among independent organisations while maintaining permissioned access. It can establish accountability without giving one organisation unchecked control

The goal should be to understand which powers need to be distributed, which responsibilities require oversight, and what safeguards prevent excessive concentration.

The Question We Should Be Asking

Perhaps the debate shouldn't be about whether a system is completely centralized or completely decentralized.

Perhaps we should ask:

• Who has the power to make important decisions?
• How independently do the participants operate?
• Can one organisation exercise disproportionate influence?
• What happens if a major participant leaves?
• Can the system continue to operate and evolve without depending excessively on one contributor?

These questions tell us more than a label ever could.

Canton is an interesting example because its design combines distributed consensus with permissioned participation and institutional involvement. Understanding that combination gives us a more useful picture than trying to place the network at one extreme or the other.

I don't believe every system needs maximum decentralization in every dimension. I believe every system needs a deliberate distribution of power that fits its purpose, with accountability, resilience, and safeguards against unnecessary dependence.

Decentralization isn't all-or-nothing.

It's a design choice. What matters is how that choice is made.