Distributed Is Not Decentralized

A product can be built around decentralization and still centralize the parts customers rely on day to day, including support, reliability, compliance, and accountability. That tradeoff showed up often in my crypto infrastructure work.

Distributed infrastructure gives you redundancy, fault tolerance, and better uptime. Decentralized infrastructure gives you independent control, censorship resistance, and protection against capture. Crypto often talks as if the first one implies the second. It does not.

I started thinking about this more seriously while working on Avalanche. The Primary Network has the kind of decentralization people usually mean, with many validators, independent operators, and shared consensus. But the Avalanche L1s built above it do not inherit that decentralization automatically. I worked on AvaCloud, the managed product for launching and operating Avalanche L1s, validators, RPC, gas relayers, and interchain messaging. After Avalanche9000 and ACP-77, L1s gained sovereignty by decoupling from the Primary Network's validator set. That decoupling was the point, and it meant each L1 had to be judged on its own validator set, operators, and supporting infrastructure.

Start with the base network

The base layer is the easiest part to talk about. Avalanche's node docs describe Primary Network validators as staking AVAX on the P-Chain and validating the P-Chain, C-Chain, and X-Chain. Those validators participate in Snowman and Snowman++ consensus, where nodes reach agreement through repeated random sampling rather than proof-of-work longest-chain selection or classical all-to-all BFT rounds. That lets Avalanche support a large validator set without treating scale and fast finality as mutually exclusive.

Avalanche starts with many independent operators at the base layer. The layers above it do not automatically inherit that structure. The break happens when validator responsibility, economic commitment, and control stop being shared with the base network.

What L1s stop inheriting

Etna, the Avalanche9000 upgrade that activated on December 16, 2024, made that break explicit. The upgrade focused on sovereignty, with cheaper L1 validation, custom validator management, reduced dependency on the Primary Network, and a cleaner path for application-specific chains. It made Avalanche L1s easier to create and operate.

Before ACP-77, launching a subnet meant every validator also had to qualify as a Primary Network validator. That meant staking 2,000 AVAX, validating the P-Chain, C-Chain, and X-Chain, and carrying the resource cost of the base network before even getting to the application chain. ACP-77 changed that. L1 validators no longer needed to validate the full Primary Network or meet the same 2,000 AVAX stake requirement. The Etna writeup describes the new model as a lightweight continuous fee, initially around 1.3 AVAX per month, with more than a 99.9% reduction in upfront cost.

The fee mattered, but control mattered more. ACP-77 moved validator-set management away from the P-Chain and toward the L1 itself, with each chain able to define its own validator logic through a ValidatorManager contract. That gives a chain more sovereignty. It can decide who validates it, what staking or permissioning rules apply, and how its validator set changes over time.

The catch is that a chain that controls its own validator set also takes on the risk that the set is centralized. The ACP itself notes that most subnets aimed to launch with at least eight validators. Eight validators may be enough for fault tolerance, uptime, and a customer's threat model. But a small validator set run by a handful of coordinated operators is not the same thing as the Primary Network's broader validator base. It is distributed infrastructure. Whether it is decentralized depends on who those validators are, who controls them, and how independent they are.

That is the tradeoff in Avalanche9000. Fault isolation and sovereignty were the goals, and they are important engineering improvements. They are also what breaks inherited decentralization.

What managed L1s centralize

AvaCloud is the managed product I worked on. It deploys and operates Avalanche L1 networks, with a portal for launching chains and automated infrastructure for managed validators, nodes, and upgrades. It also includes modules for interoperability, gas relaying, wallets, and other services around the chain. After ACP-77 made L1s cheaper and more configurable, chains still needed someone to run them.

ACP-77 gives an L1 the ability to manage its own validator set. A ValidatorManager contract can define the rules. A chain sponsor can choose its validators, run its infrastructure, widen its operator set, or hand off responsibility over time. But in a managed deployment, the provider may be the party making many of those decisions day to day. The customer may have the right to take control. The provider may still be running the system.

Most teams do not want to become validator infrastructure companies before they can test whether their game economy, marketplace, or DeFi primitive needs its own chain. They want working RPC, healthy nodes, chain upgrades, gas relaying, observability, support, and someone accountable when the system is down. Managed infrastructure makes the protocol usable by teams that need to ship.

If the customer never exercises the right to take control, day-to-day control still sits with whoever operates the system. If the validator set is small, the RPC layer is managed, the gas relayer is managed, and upgrades are coordinated through a managed service, then customers are relying on a centralized operator. The question is not whether the chain could be operated differently. The question is who holds the keys, who runs the machines, who gets paged, and who can keep the system alive when it breaks.

An RPC endpoint falls behind, a relayer needs funding, a validator needs patching, and the chain sponsor's authority on paper matters less than who can fix the system before customers notice.

"Sovereign" and "decentralized" should not be treated as synonyms. Sovereignty says the chain has the authority to choose. Decentralization asks how many independent parties participate in that choice. A managed L1 may be the right setup for the job. If the answer to most operational questions is one provider, then that should be named.

Interop depends on delivery too

Interchain Messaging adds the same question across chains. ACP-77 makes L1s more sovereign by decoupling their validator sets. That creates a many-chain world with separate L1s, separate validators, and separate operating assumptions. Those chains still need to talk to each other.

Avalanche's ICM docs describe cross-chain messages being verified through BLS multi-signatures over validator sets, with validator public keys and weights tracked by the P-Chain. A source chain's validators sign a message, those signatures are aggregated, and the destination chain can verify that enough validator weight attested to it. In that narrow sense, "trustless" is fair. The destination chain does not have to believe a random bridge operator about what happened on the source chain. It can verify a cryptographic proof against the source chain's validator set.

But verification is not the whole system customers depend on. Someone still has to notice the message, collect signatures, aggregate them, package the proof, and deliver a transaction to the destination chain. The ICM Relayer listens for Warp message events, queries source-chain validators for BLS signatures, combines them into an aggregate signature, and submits the message to the destination blockchain according to that VM's verification rules.

Verification protects safety. An invalid message should not be accepted just because a relayer says so. Delivery is about liveness. The message still has to be picked up, signed, aggregated, paid for, submitted, retried, monitored, and delivered in the time the application expects. A centralized relayer does not necessarily break the cryptographic guarantee. It can still break the customer's experience of the system.

Customers do not experience that distinction cleanly. If a bridge transfer, settlement event, or cross-chain instruction does not arrive, they do not say, "safety held but liveness failed." They say the system is broken. In production, the person on call for whether the message lands becomes part of the trust model, even if the protocol correctly rejects forged messages.

The same stack can contain a decentralized base network, sovereign-but-small L1s, managed validators, managed RPC, managed gas relayers, and managed interchain delivery. Any one of those choices can make sense. The mistake is compressing all of them into one word.

Centralization can be the right answer

None of this means the more decentralized architecture is always the better one. Production systems are built for customers, regulators, market windows, cost models, and failure modes someone is willing to accept.

A small validator set can lower coordination cost, simplify accountability, and make performance easier to reason about. A managed relayer gives the application a party responsible for delivery instead of hoping a volunteer ecosystem appears when the product needs reliability. A managed RPC layer gives customers a working endpoint, which they will value if the alternative is slow, stale, or down.

This matters for enterprise and regulated use cases, which were part of the ACP-77 motivation. Some organizations do not want anonymous permissionless validators touching their execution environment. Some cannot expose their execution environment to permissionless validation for compliance reasons. Some need known operators, contractual support, auditability, and clear incident ownership. For those customers, a smaller and more controlled principal set is not a compromise they failed to notice. It is the requirement.

Progressive decentralization can make sense. A system can start with a small, trusted set of operators because that is the only way to get the product live, then widen participation as the application proves demand and the operating model matures. That only works if the team is clear about the timeline and what control it is keeping centralized.

The problem is not centralization. The problem is calling something decentralized without saying which parts are still centralized. The point is to name which trust has been centralized and why.

Questions to ask

In Avalanche, the answer changes by layer. The base network can have many independent validators. An L1 can be sovereign but validated by a small group. The infrastructure can be distributed across machines but operated by one provider. The messaging protocol can be trustless for safety but centralized for liveness. None of those statements contradict each other. They describe different parts of the stack.

So when something is described as "decentralized," these are the questions I find useful.

1. Which layer is being described?
2. Which part is decentralized, such as validation, governance, operation, message delivery, data availability, or upgrade control?
3. How many independent operators actually control that part?
4. Who does the system depend on when something breaks?

The last question is where this becomes practical. Architecture diagrams describe the intended flow. Production incidents show who the system depends on. If one provider has to restart the validator, fund the relayer, rotate the key, patch the RPC node, coordinate the upgrade, or explain why the cross-chain message did not arrive, then that provider is part of how decentralized the system is. Maybe that is acceptable. Maybe it is desirable. But it is not neutral.

Nodes, validators, relayers, RPC endpoints, regions, and replicas all matter. But they do not answer the decentralization question by themselves. The question is who operates them, who controls them, and who the system depends on when something goes wrong.