What Makes THORChain Decentralized

Decentralization is one of those words that gets used constantly in crypto, but I do not think people always stop to ask what it actually means.
A project will say that it runs on a blockchain or point to the number of validators it has, and that is supposed to settle the question. To me, that is not enough. What matters is who controls the system, who can change it, and how many people would need to come together before they could stop it from operating.

In this article, I want to reflect on what meaningful decentralization looks like in practice, where centralization can remain hidden within a protocol’s stack, and why decentralization inevitably involves economic and technical trade-offs.
I will also explain how THORChain distributes authority between developers and nodes, and why I believe its governance and validator design give the network a strong foundation for resisting control.

The hidden points of control

Decentralization is one of the most widely used terms in crypto, but it is often discussed without examining what it means in practice.

For me, the most important principle is that a system is only as decentralized as the most centralized component in its stack. A project can operate on a blockchain and still be highly centralized if its infrastructure, APIs, validators, governance, or development process depends on a small number of people.

A good example is a social network that stores its data onchain but depends on an API operated by the original development team. The project can say that users own their data and that everything is stored on a blockchain, but the team still controls the main way that people access the information. They can filter what is shown, restrict access, or turn the API off entirely. The underlying data may be decentralized, but the actual product is still dependent on that team.

The same problem appears in validator networks. A chain may claim to have hundreds of validators, but that number means very little if most of them are operated by the same entities, hosted in the same data centers, or selected through a closed process.

The first question should not be how many validators a network has. It should be who controls them, whether they are genuinely independent, and whether a new participant can become a validator without first receiving permission from an existing group.

Governance creates another source of hidden centralization. Many protocols allow proposals to pass based on a majority of the votes cast. That can appear democratic, but participation is often very low. In such a scenario, a proposal may pass simply because the founder, who owns a large share of the token supply, votes in a particular direction.

In my opinion, decentralization should therefore be assessed across the entire system. This includes validator participation, infrastructure, governance, access to data, control over contracts, and the ability to implement protocol changes.
A protocol cannot compensate for a centralized component simply by pointing to the decentralized parts of its design. This is one of the key principles that I believe should be kept in mind when designing a crypto project.

How THORChain distributes control

The main reason I consider THORChain decentralized is simple. The nodes have the final say. Developers can write code and propose changes, but they cannot force the network to accept them. Most code updates and governance proposals require support from two-thirds of the nodes before they can be adopted.

Development itself is not decentralized, and I do not think it needs to be. There is no software project in the world where thousands of unrelated people independently contribute to a single coherent codebase. Bitcoin and Ethereum also rely on relatively small groups of developers to research problems and propose solutions. The more important question is not whether the development team itself is decentralized, but whether that team can unilaterally decide what the network runs.

In THORChain, it cannot. Developers can produce a patch, but the nodes still have to review and adopt it. That process can take time, which can be frustrating when there is a problem, and people want the network fixed immediately. However, that delay is also evidence that no single person can press a button and decide what happens.

Whenever a supposedly decentralized network goes down and comes back online an hour later, I think it is reasonable to ask who restarted it, how that decision was made, and how many people were actually involved. A genuinely decentralized system will sometimes move more slowly because authority is distributed across independent participants. That friction is part of the trade-off.

Decentralization requires trade-offs

A larger validator set can make a network more decentralized by spreading control across more participants. However, the number alone does not tell us whether those validators are independent, economically sustainable, or concentrated behind the same operators and infrastructure.

For THORChain, expanding the node set also means dividing protocol income among more operators and increasing the coordination required to reach consensus. The network could use inflation to subsidize a much larger validator set, but that would transfer value away from existing RUNE holders. Instead, node participation is allowed to respond to the income generated by the protocol.

The goal is therefore not to maximize the number of nodes at any cost. It is to maintain enough independent operators to prevent any individual or group from controlling the network while preserving the incentives and performance needed for those nodes to operate reliably.

For me, this is what meaningful decentralization looks like. Developers can propose changes, but nodes decide whether to accept them, and most decisions require support from two-thirds of the network.
The strength of the system comes not from a single headline number, but from ensuring that control cannot become concentrated in one part of the network. That is what I currently see in THORChain: a sufficiently decentralized network that makes certain trade-offs while continuing to function effectively.