THORChain operates a node-based governance system in which 111 active nodes, each bonded with at least 300,000 RUNE, decide how the network evolves. Every node receives one vote regardless of the amount of RUNE committed, and most major decisions require approval from two-thirds of active nodes.
Proposal and voting process
According to THORChain, developers and community members can propose changes to the network's underlying software. These proposals move through public discussions before reaching nodes for approval. The governance process starts with THORNode, the software each network node runs, and suggestions are discussed openly on Discord, where participants review and refine ideas before developers turn them into code.
Once a proposed change is ready, nodes decide whether to adopt the next software version. At least two-thirds of active nodes must approve the upgrade. With 111 active nodes, this requires at least 74 votes.
Mimir parameter adjustments
THORChain also gives nodes control over network parameters through Mimir, a mechanism that allows operators to adjust settings without requiring a full software upgrade. Economic decisions, including fee changes, require approval from two-thirds of nodes. Operational decisions, particularly those involving security, follow a lower voting threshold: just three node votes can approve an operational Mimir setting.
Reversing these decisions follows a separate process. Four nodes can vote to rescind an operational Mimir setting, and five votes can then counter that decision, creating a changing threshold for subsequent reversals. This structure separates major economic decisions from operational adjustments and allows nodes to respond to security concerns without waiting for broader governance approval.
Automated network actions
Not every THORChain decision requires a node vote. Some network processes follow predefined rules that automatically trigger specific actions. One example is node rotation, which happens during each churn period. Churning occurs approximately every three days, when THORChain removes two nodes from the network: the oldest active node and the node with the highest number of slash points. Slash points track penalties accumulated by nodes for failing to meet network requirements, helping maintain operational standards and encouraging reliable behavior.
THORChain also has an automatic safeguard against insolvency. If the network detects that its assets and liabilities no longer balance, it halts swapping activity. This measure prevents users from continuing swaps while the protocol faces a potential solvency problem, and unlike governance proposals, the safeguard does not require node approval before activation.
Together, these mechanisms give THORChain a combination of community-driven governance, operator voting, and automated protections. The distinction matters because network upgrades, economic adjustments, and emergency responses require different levels of approval. THORChain does not rely on RUNE holdings alone to determine governance power; each active node receives one vote, while predefined rules handle certain operational and security decisions automatically.
