THORChain Details 74-Vote Threshold for Upgrades and Fees

THORChain requires 74 votes from 111 active nodes to approve software upgrades and Mimir-managed economic changes, according to the explanation the project published Friday, Nov. 6 at 2:26 p.m. ET (19:26 UTC). The threshold represents two-thirds of the active set, rather than a majority measured by bonded RUNE.

The explanation said each active node had at least 300,000 RUNE bonded to it. THORChain put the voting rule plainly: each node “gets one vote regardless of bond size.” A larger commitment therefore does not create additional votes or influence.

Who controls protocol changes?

Developers and community members may propose software changes, but node operators decide whether to adopt them. THORChain stated that “RUNE holders are not voting members,” while the model has no central governance body or DAO.

That division separates technical input from control over implementation. The published account adds detail to earlier coverage of THORChain’s node-centered governance by specifying who may propose changes, who may vote and what level of support each category requires.

The explanation did not identify the 111 active operators or disclose whether some are affiliated, so node concentration cannot be calculated from the available information. It also supplied no voting history, implementation timetable or details about how quickly an approved software version would reach two-thirds adoption.

The practical result is simple: bonded RUNE does not increase a node’s voting power, while every operator receives one ballot.

How do approvals become effective?

Software upgrades require approval from two-thirds of active nodes. Approval does not itself activate the release: two-thirds of nodes must also adopt the new software version, after which the upgrade takes effect.

Economic changes managed through Mimir use the same two-thirds threshold, rounded up. Mimir lets node operators vote on network parameters. Some settings can override constants built into the software. Fees are an example of a covered setting.

At 111 active nodes, both approval paths require 74 votes, while software faces a separate adoption requirement. This creates a dual gate for code changes and a supermajority decision for covered economic parameters.

For software changes, permission alone is insufficient: the network must also reach broad operational adoption.

Can a small group change operational settings?

Operational Mimir settings follow a lower threshold. A value requires support from at least three active nodes and must receive more votes than each competing value, making a formal supermajority unnecessary for this category.

THORChain’s explanation also says four nodes can rescind an operational setting. Five nodes can counter that vote, although the account does not define the sequence, scope or timing of such a counteraction. That ambiguity limits any firm conclusion about how quickly a small group could reverse or preserve a parameter.

Routine settings can therefore move on a much smaller node base than major economic changes.

When does a solvency halt begin?

THORChain also operates an automatic solvency check. If at least one-third of active nodes report the same vault as insolvent, swaps and liquidity additions or removals stop on that chain. The halt lifts automatically once that vault becomes solvent again.

This trigger does not require the 74-vote approval threshold. The explanation frames the consequence at the chain level, not as an automatic shutdown across the entire network, and does not specify whether reporting on one vault affects activity involving another.

The account did not explain how nodes determine solvency, what evidence they consider or how quickly they must report. Those details matter because the halt follows a report from one-third of nodes rather than a financial test disclosed in the explanation.

For solvency events, the practical effect is immediate: qualifying reports stop activity on the affected chain until the vault recovers.

What should observers watch?

The rules give node operators substantial control over protocol evolution, fees and emergency circuit breakers, while excluding RUNE holders from direct voting. That structure makes operator identity and voting concentration more relevant than headline token ownership, although the published explanation quantified neither.

With no implementation deadline specified, the next observable test will be a recorded vote on an upgrade, fee change or operational setting, followed for software by evidence that two-thirds of nodes adopted the release.