Distributed Is Not Decentralized

A team can build a product around decentralization and still centralize the parts customers rely on every 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, and it does not.

I started to think about this more seriously at Avalanche. The Primary Network has the kind of decentralization people usually mean, with many validators, independent operators, and shared consensus. But the Avalanche L1s above it do not inherit that decentralization automatically. I worked on AvaCloud, the managed product that launches and operates 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 means you now have to judge each L1 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 say Primary Network validators stake AVAX on the P-Chain and validate the P-Chain, C-Chain, and X-Chain. Those validators reach agreement through repeated sub-sampled voting, where each node asks a small random subset of validators for their preference. They do not select a proof-of-work longest chain, and they do not run classical all-to-all BFT rounds, which is what lets Avalanche run a large validator set and still finalize quickly.

Avalanche starts with many independent operators at the base layer, but the layers above it do not inherit that structure automatically. The break happens when an L1 stops sharing validator responsibility, economic commitment, and control 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: it made L1 validation cheaper, let chains manage their own validators, reduced dependency on the Primary Network, and opened a cleaner path for application-specific chains.

Before ACP-77, every subnet validator also had to qualify as a Primary Network validator, which meant staking 2,000 AVAX and validating the P-Chain, C-Chain, and X-Chain. The ACP put the arithmetic plainly: most subnets aimed to launch with at least eight validators, so the stake alone came to 16,000 AVAX, or about $560,000 when it was written. All of that came before the application chain did anything.

ACP-77 changed the model. L1 validators no longer had to validate the full Primary Network or meet the 2,000 AVAX requirement. The Etna writeup describes a lightweight continuous fee instead, initially around 1.3 AVAX per month, which cut the upfront cost by more than 99.9%.

The fee mattered, but control mattered more. ACP-77 moved validator-set management away from the P-Chain and toward the L1 itself, so each chain can now 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 which controls its own validator set also takes on the risk that the set is centralized. Eight validators may be enough for fault tolerance, uptime, and a customer's threat model. But a handful of coordinated operators is not the same thing as the Primary Network's broader validator base. That is distributed infrastructure, and whether it is also decentralized depends on who those validators are and how independent they are of each other.

Fault isolation and sovereignty were the goals of Avalanche9000, and they are real 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, giving customers a portal to launch 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 lets an L1 manage its own validator set, and a ValidatorManager contract defines 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 often makes many of those decisions day to day, so the customer may hold the right to take control while the provider actually runs 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 lets teams that need to ship actually use the protocol.

If the customer never exercises the right to take control, day-to-day control still sits with whoever operates the system. And if the validator set is small while one provider manages the RPC layer, the gas relayer, and the upgrades, then customers are relying on a centralized operator. The useful questions are who holds the keys, who runs the machines, who gets paged, and who keeps the system alive when it breaks.

An RPC endpoint falls behind, a relayer runs out of funds, a validator needs a patch. In those moments the chain sponsor's authority on paper matters less than who can fix the system before customers notice.

So do not treat "sovereign" and "decentralized" as synonyms. Sovereignty says the chain has the authority to choose, while decentralization asks how many independent parties participate in that choice. A managed L1 may well be the right setup for the job, but if one provider is the answer to most operational questions, say so.

Interop depends on delivery too

Interchain Messaging raises the same question across chains. Because ACP-77 decouples validator sets, it creates a many-chain world with separate L1s, separate validators, and separate operating assumptions, and those chains still need to talk to each other.

Avalanche's ICM docs describe how a destination chain verifies a cross-chain message, through BLS multi-signatures over validator sets, with the P-Chain tracking validator public keys and weights. A source chain's validators sign a message, a relayer aggregates those signatures, and the destination chain checks 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 verifies a cryptographic proof against that chain's validator set instead.

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. The ICM Relayer listens for Warp message events and queries source-chain validators for BLS signatures. It then combines them into an aggregate signature and submits the message in the form the destination VM's verification rules require.

Verification protects safety, so a destination chain should not accept an invalid message just because a relayer says so. Delivery is about liveness. Someone still has to pick the message up, sign it, aggregate it, and pay for it, then submit it, retry it, monitor it, and land it in the time the application expects. A centralized relayer does not necessarily break the cryptographic guarantee, but 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 though the protocol still rejects forged messages correctly.

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 to compress 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. You build production systems for customers, regulators, market windows, cost models, and the failure modes someone will accept.

A small validator set can lower coordination cost, simplify accountability, and make performance easier to reason about. A managed relayer gives the application one party responsible for delivery, where the alternative is 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.

ACP-77 names the regulated case directly. Its motivation section points out that entities barred from validating a permissionless, smart-contract chain like the C-Chain could not launch a Subnet at all. They had no way to opt out of Primary Network validation. That blocker kept a whole cohort of real-world-asset issuers off Avalanche. Past that specific problem, some organizations simply need known operators, contractual support, auditability, and clear incident ownership. For those customers, a smaller and more controlled validator set is the requirement.

Progressive decentralization can make sense. A system can start with a small, trusted set of operators, because that is often the only way to get the product live. It can widen participation later, as the application proves demand and the operating model matures. That only works if the team says what the timeline is and which controls it keeps.

None of that requires an apology for centralization. It requires you to say which parts are centralized, and why you chose it that way.

Questions to ask

In Avalanche, the answer changes by layer. The base network can have many independent validators, while an L1 above it can be sovereign but validated by a small group. The infrastructure can spread across machines but run under one provider. The messaging protocol can be trustless for safety and centralized for liveness. None of those statements contradict each other; they describe different parts of the stack.

So when someone describes a system as "decentralized," I ask four questions.

1. Which layer are you describing?
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 show the intended flow; incidents show who the system actually depends on. One provider may have to restart the validator, fund the relayer, and rotate the key. It may also patch the RPC node, coordinate the upgrade, and explain why the cross-chain message did not arrive. That provider is part of the answer. It may be acceptable, or even the right design. Just say so, instead of letting one word cover it.