THORChainはノードベースのガバナンスシステムを通じてネットワークの進化の方向性を決めており、プロジェクトは現在、ソフトウェアアップグレードから手数料調整に至るまで、これらの決定がどのように行われるのかを詳しく説明した。THORChainは分散型クロスチェーンスワッププロトコルであるため、ここで説明される仕組みは、そのソフトウェア、手数料、セキュリティ管理がどのように変更されうるかを左右する。プロトコルには現在111のアクティブなノードがあり、各ノードはネットワークを保護する担保として最低30万RUNEをボンドしている。各ノードはコミットしたRUNEの量に関係なく1票を持ち、ほとんどの重要な決定にはアクティブノードの3分の2の承認が必要である。決定はブロックチェーン上で直接行われ、ネットワーク運営者はアップグレード、経済パラメータ、一部のセキュリティ対策を直接管理する。

ただし、すべてのネットワーク決定が同じ投票要件に従うわけではない。ソフトウェアアップグレードや経済的な変更はノード投票を経る一方、運用およびセキュリティに関する事項については、別の定義済みルールのセットが特定のアクションを自動的に実行する。

THORChainのガバナンスとノード投票の仕組み

ガバナンスプロセスは、各ネットワークノードが実行するソフトウェアであるTHORNodeから始まる。開発者やコミュニティメンバーは、Discord上での公開ディスカッションを通じて、プロトコルの基盤ソフトウェアへの変更を提案できる。参加者がこれらのアイデアを検討・改善した後、開発者がコードに落とし込む。

提案された変更が準備できたら、ノードが次のソフトウェアバージョンを採用するかどうかを決定する。アップグレードにはアクティブノードの少なくとも3分の2の承認が必要で、111ノードがアクティブな場合、最低74票を要する。3分の2ルールはアクティブノード数を基準に計測されるため、変更の承認に必要な票数はアクティブノードの数が変わるたびに変動する。

この1ノード1票のモデルは、暗号資産業界で広く採用されているトークン保有量に比例したガバナンスともTHORChainを区別するものだ。トークン型ガバナンスでは、影響力は通常、保有者が提案にコミットするトークン量に応じて拡大する。THORChainは代わりに、ネットワーク自体を保護するためにボンド資本を提供しているノード運営者にアップグレードの決定を委ねている。

THORChainの公式Xアカウントは、2026年11月6日の投稿でこのプロセスを次のように説明した:

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

Mimirによるパラメータ変更

ノードはMimirを通じてネットワークパラメータも管理している。Mimirは、すべての変更に完全なソフトウェアアップグレードを必要とせずに、運営者が設定を調整できる仕組みである。

投票要件は決定の種類によって異なる。手数料変更を含む経済的な決定にはノードの3分の2の承認が必要だ。運用上の決定、特にセキュリティに関わるものは、より低い投票要件に従い、わずか3票で運用系のMimir設定を承認できる。

この階層構造により、経済的な影響の大きな変更はノード全体の合意を得る必要がある一方、時間的に緊急性の高い運用措置は少数の票で前進できる。

これらの決定の取り消しは別のプロセスに従う。4つのノードが投票すれば運用系のMimir設定を取り消すことができ、その後5票でその決定に対抗できるため、以降の取り消しには変動する要件が生じる。

この分離により、ノードはより広範なガバナンス承認を待たずにセキュリティ懸念に対応できる一方、重要な経済的決定はより幅広い合意の対象に保たれる。

セキュリティルールによる自動的なネットワークアクション

THORChainのすべての決定にノード投票が必要なわけではない。一部のネットワークプロセスは、定義済みのルールに従い、特定のアクションを自動的に実行する。

一例が、各チャーン期間に行われるノードローテーションである。チャーンは約3日ごとに発生し、THORChainはネットワークから2つのノードを除外する: 最も古いアクティブノードと、スラッシュポイント数が最も多いノードである。スラッシュポイントは、ネットワーク要件を満たさなかったことによってノードに蓄積されるペナルティを追跡する。この仕組みは運用基準の維持に役立ち、ノード運営者に信頼性の高い動作を促す。この約3日ごとのサイクルは、アクティブなノードセット、ひいては3分の2の投票計算が変化しうる、定期的なチェックポイントともなっている。

THORChainはまた、資産不足に対する自動的なセーフガードも備えている。ネットワークが資産と負債のバランスが崩れたことを検知すると、スワップ活動を停止する。この措置は、プロトコルに潜在的な支払能力の問題が発生している間、ユーザーがスワップを継続するのを防ぐ。ガバナンス提案とは異なり、このセーフガードは発動前にノードの承認を必要としない。

ノード投票と自動保護の組み合わせ

これらの仕組みにより、THORChainはコミュニティ主導のガバナンス、運営者による投票、自動化された保護を組み合わせている。この区別は重要である。ネットワークアップグレード、経済的な調整、緊急対応にはそれぞれ異なる承認レベルが求められ、それに応じて注目すべきポイントも異なるからだ。アップグレードと手数料変更には3分の2の投票、運用設定には3票、そして投票なしで作動する自動セーフガードがある。

THORChainは、ガバナンス上の権限をRUNEの保有量だけで決定しているわけではない。各アクティブノードが1票を持ち、一部の運用およびセキュリティの決定は定義済みルールが自動的に処理する。