> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tori.finance/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Pages whose paths begin with /zh-Hans/, /ja/, /ko/, /vi/, /id/, /hi/, /pt-BR/ or /es/ are machine translations of the English pages, provided for convenience only. They may contain errors or omissions and have no legal effect, and where one differs from the English page, the English page prevails. For anything that will be relied on, read and cite the English page at the same path without the language prefix.

# ロール、マルチシグ、タイムロック

> Toriのメインネットのコントラクトにおける特権ロール：各ロールにできること、保有者、24時間のタイムロックの対象

Toriは、オンチェーンのコントラクトと中央清算型の流動性の場との間をつなぐ必要があり、そのためには特権鍵が欠かせません。このページでは、Toriのメインネットのコントラクトにおける特権ロールについて、各ロールに何ができるか、誰が保有しているか、タイムロックの対象は何かを説明します。以下のすべてのロールは[検証済みのコントラクト](/ja/resources/contracts.md)上に存在し、すべての保有者はオンチェーンで確認できます。そのため、ここに記載している内容はすべてご自身で確かめることができます。

マトリクス全体には、2つの設計ルールが貫かれています。**最小権限**：どのロールも、その名前が示す1つの役割を超える操作はできません。そして、プロトコルの権限を*縮小*することしかできないロールこそが、最も迅速に動かせる鍵で保有されています。**拡大には遅延を**：新しい担保資産、新しいカストディ先、新しい実装など、プロトコルの対象範囲を広げる変更は、実行可能になるまで24時間、公開された状態で待機します。

## 鍵の保有方法

ロールの鍵をどのように管理するかは、意図的なリスク判断です。そのため、マトリクスではロールごとに管理方式を明記しています。

| 管理方式 | 意味 |
| - | - |
| **3-of-5 Safe** | Gnosis Safe v1.4.1。5人の署名者のうち3人の承認が必要で、この定足数はオンチェーンで強制され、誰でも確認できます |
| **MPCボールト** | 鍵はシェアに分割され、規制を受けたプロバイダーのインフラ全体に分散されています。プロバイダーを含め、いずれの当事者も単独では署名できません。承認の定足数はプロバイダーのポリシーエンジンで強制されます |
| **EOA** | Toriが運用する単一の署名アドレス |

EOAのロールを制約しているのは、鍵の管理方式ではなくコントラクトです。各ロールは構造上、権限が狭く限定されています。ユーザーがすでに署名した指示を実行するか、リストに書き込むだけであり、呼び出しのたびにプロトコル自身の上限と照合されます。各ロールが何に及ぶかは、以下のマトリクスで正確に示しています。

## ロールマトリクス

| ロール | コントラクト | 保有者 | 関数 | 備考 |
| - | - | - | - | - |
| **オーナー / 管理者** | trUSD, strUSD, Minting, Distributor, YT-Lock | 3-of-5 Safe | 対象コントラクトにおける運用ロールの付与と取り消し；`pause` / `unpause`；`setMaxMintPerBlock`、`setMaxRedeemPerBlock`；担保トークンの削除または無効化；`removeCustodianAddress` | オーナーと管理者は同じSafeです。オンチェーンでは別々のロールであり、コントラクトを変更せずに分離できます |
| **タイムロック管理者** | trUSD, strUSD, Minting, YT-Lock | タイムロックコントラクト | `_authorizeUpgrade`（コントラクトのアップグレード）；`addAllowedToken`、`enableAllowedToken`；`addCustodianAddress`；`setStablesDeltaLimit`；`setMinter` | キューに登録されたタイムロックのオペレーションを通じてのみ実行可能 |
| **タイムロック提案者** | Timelock | 3-of-5 Safe | オペレーションをキューに登録 | |
| **タイムロック実行者** | Timelock | 3-of-5 Safe | 遅延期間の経過後、キューに登録されたオペレーションを実行 | 実行には、キューに登録したときの承認から1日後に、それとは別の3-of-5の承認が必要です。2つの別々の判断です |
| **タイムロックキャンセラー** | Timelock | MPCボールト | キューに登録されたオペレーションを取り消す | キューに登録された変更を止めることはできますが、変更を行うことはできません |
| **ゲートキーパー** | Minting | MPCボールト＋外部の当事者 | `disableMintRedeem`；`removeMinterRole`、`removeRedeemerRole`、`removeCollateralManagerRole` | 権限を取り上げることしかできず、付与することはできません。保有者の一方はTori、もう一方は外部の当事者です |
| **ホワイトリスト管理者** | Minting | MPCボールト | `addToWhitelist`、`addToWhitelistBatch`、`removeFromWhitelist` | ミントと償還はコントラクトでホワイトリストによって制限されているため、そもそも誰が取引できるかをこのロールが決定します |
| **担保管理者** | Minting | MPCボールト | `transferToCustody` | 送付先は、タイムロックを通じてすでに登録されたカストディアンのアドレスに限られます |
| **ミンター** | Minting | 3つのEOA | `mint()` | ユーザーが署名したEIP-712注文を提出します。自ら注文を作成することはできません |
| **リディーマー** | Minting | 3つのEOA | `redeem()` | ミンターと同様 |
| **ブラックリスト管理者** | strUSD | Safe + EOA | `addToBlacklist`、`removeFromBlacklist`、およびそれらのバッチ版 | コンプライアンス上のスクリーニング |
| **リワーダー** | strUSD | Safe + Distributorコントラクト | `transferInRewards`、`reportLoss` | 保有者の一方は鍵ではなくコントラクトです |
| **リワード運用者** | Distributor | MPCボールト | 予定された分配を実行 | 金額は変更できません |

ミンターにできるのは、ユーザーが署名した注文を提出することだけです。ゲートキーパーは、マルチシグの定足数なしに、1回のトランザクションでそのロールを剥奪できます。

## 24時間のタイムロックの対象

タイムロックのアドレスは[`0xA952453E39F77108Ee37C1b92de593F1C59A6ef4`](https://etherscan.io/address/0xA952453E39F77108Ee37C1b92de593F1C59A6ef4)で、最小遅延時間は86,400秒です。タイムロックはコアコントラクトのタイムロック管理者ロールを保有しているため、次の4つの操作が人知れず行われることはありません。

* **コントラクトのアップグレード**。trUSD、strUSD、Mintingの新しい実装は、まず公開の場でキューに登録されます。
* **新しい担保資産**。追加はタイムロックの対象ですが、削除や無効化は即時に行われます。迅速に実行できる方向こそが、安全な方向であるべきだからです。
* **新しいカストディ先**。`addCustodianAddress`はタイムロックの対象です。入金された担保の行き先を決めるオペレーションであるため、最も注視すべきものです。
* **ステーブルコインのデルタ上限の引き上げ**。

キューはEtherscanで誰でも確認できます。予期せぬオペレーションがキューに登録された場合でも、実行可能になるまで丸1日公開されており、タイムロックキャンセラーの鍵があれば1回のトランザクションでそれを止めることができます。

## レート制限

ミントと償還には、コントラクトのレベルで、ブロックごと、資産ごと、そして全体の上限が設けられています。この上限は呼び出しのたびにチェックされ、どのような注文を渡されたかにかかわらず、ミンターとリディーマーのロールに適用されます。上限の変更はオーナーの関数であるため、3-of-5 Safeの承認が必要です。運用用の鍵が自ら上限を引き上げることはできません。

## ご自身で確認する

この表にあるロールの割り当てはすべてチェーン上で確認でき、いずれも当社の説明を鵜呑みにする必要はありません。

* **ロールの保有者**：コントラクトの`hasRole(role, address)`
* **Safeの定足数**：Safeの`getThreshold()`と`getOwners()`
* **タイムロックの遅延時間**：タイムロックの`getMinDelay()`
* **現在キューにあるもの**：Etherscan上のタイムロックのイベント

MPCのしきい値は、オンチェーンではなくカストディプロバイダーのポリシーエンジンで管理されています。現在、プロバイダーによる確認と独立したアテステーションを進めており、準備金証明のデータとあわせて公開する予定です。

> [!NOTE]
>
> **機械翻訳について**：このページは英語の原文を機械翻訳したもので、便宜のためにのみ提供しています。誤りや欠落を含む可能性があり、法的効力はありません。このページと英語版の内容が異なる場合は、英語版が優先します。このページの内容に依拠する前に、[英語の原文](/security/roles.md)をご確認ください。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.