THORChain uses a node-based governance system to decide how its network evolves, and the project has now laid out exactly how those decisions are made — from software upgrades to fee adjustments. THORChain is a decentralized cross-chain swapping protocol, so the mechanics described here determine how its software, its fees, and its security controls can change. The protocol currently has 111 active nodes, each holding at least 300,000 RUNE in bonded collateral that secures the network. Every node receives one vote, regardless of how much RUNE it commits, and most major decisions require approval from two-thirds of active nodes. Decisions are made directly on the blockchain, giving network operators direct control over upgrades, economic parameters, and certain security measures.

Not every network decision follows the same voting requirements, however. While software upgrades and economic changes pass through node votes, a separate set of predefined rules automatically triggers specific actions on operational and security matters.

How THORChain Governance and Node Voting Work

The governance process starts with THORNode, the software that each network node runs. Developers and community members can propose changes to the protocol's underlying software through open discussions on Discord. Participants review these ideas and refine them 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 an upgrade — with 111 nodes active, that means a minimum of 74 votes. Because the two-thirds rule is measured against the number of active nodes, the vote count needed to pass a change moves whenever the size of the active node set does.

That one-node-one-vote model also sets THORChain apart from the token-weighted governance used widely across the crypto industry, where influence typically scales with how many tokens a holder commits to a proposal. THORChain instead places upgrade decisions with node operators who have bonded capital committed to securing the network itself.

The official THORChain X account described the process in a post on November 6, 2026:

On THORChain, decisions are made directly on the blockchain. For an important change to be accepted, ⅔ of its nodes have to vote for it. Right now, 111 nodes are active. They all bond at least 300,000 RUNE, put up as collateral to secure the network. Each node has one vote, no…

— THORChain (@THORChain) November 6, 2026

Parameter Changes Through Mimir

Nodes also control network parameters through Mimir, a mechanism that allows operators to adjust settings without requiring every change to involve a full software upgrade.

Voting thresholds differ by decision type. 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.

The tiered structure means changes with broad economic impact must win consensus across the node set, while time-sensitive operational measures can move forward with only a few votes.

Reversing those 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 any subsequent reversals.

This separation allows nodes to respond to security concerns without waiting for broader governance approval, while keeping major economic decisions subject to wider consensus.

Automatic Network Actions Under Security Rules

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 takes place 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. The mechanism helps maintain operational standards and encourages node operators to behave reliably. That roughly three-day cadence also gives the network a recurring checkpoint at which its active node set — and with it, the two-thirds vote math — can shift.

THORChain also maintains an automatic safeguard against insolvency. If the network detects that its assets and liabilities no longer balance, it halts swapping activity. The measure prevents users from continuing swaps while the protocol faces a potential solvency problem. Unlike governance proposals, the safeguard does not require node approval before activation.

A Mix of Node Voting and Automated Protections

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, which in turn means different things to watch as changes move through: two-thirds votes for upgrades and fee changes, three-vote operational settings, and automated safeguards that act without a vote.

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.