> ## 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. # Roles, Multisig and Timelocks > The privileged roles on Tori's mainnet contracts: what each one can do, who holds it, and what sits behind the 24-hour timelock Tori has to reach between on-chain contracts and centrally-cleared liquidity venues, and that reach needs privileged keys. This page sets out the privileged roles on Tori's mainnet contracts: what each one can do, who holds it, and what sits behind the timelock. Every role below lives on a [verified contract](/resources/contracts) and every holder is readable on-chain, so each line here is something you can check for yourself. Two design rules run through the whole matrix. **Least privilege**: no role can do more than the one job it is named for, and the roles that can only ever *reduce* the protocol's powers are the ones held on the fastest keys. **Delay on expansion**: anything that widens the protocol's surface, a new collateral asset, a new custody destination, a new implementation, waits 24 hours in public before it can execute. ## How the keys are held A role's custody model is a deliberate risk decision, so the matrix names it per role. | Custody | What it means | | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **3-of-5 Safe** | Gnosis Safe v1.4.1. Three of five signers must approve, and the quorum is enforced on-chain where anyone can read it | | **MPC vault** | The key is split into shares across a regulated provider's infrastructure. No single party, including the provider, can sign alone; the approval quorum is enforced in the provider's policy engine | | **EOA** | A single signing address operated by Tori | What bounds the EOA roles is the contract rather than the custody arrangement. Each is narrow by construction: it executes instructions a user already signed, or writes to a list, and it is checked against the protocol's own limits on every call. The matrix below sets out exactly what each one reaches. ## Role matrix | Role | Contract | Held by | Functions | Notes | | ---------------------- | -------------------------------------------- | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | **Owner / Admin** | trUSD, strUSD, Minting, Distributor, YT-Lock | 3-of-5 Safe | Grant and revoke the operational roles on those contracts; `pause` / `unpause`; `setMaxMintPerBlock`, `setMaxRedeemPerBlock`; remove or disable a collateral token; `removeCustodianAddress` | Owner and Admin are the same Safe. They are separate roles on-chain and can be split without a contract change | | **Timelock Admin** | trUSD, strUSD, Minting, YT-Lock | The timelock contract | `_authorizeUpgrade` (contract upgrades); `addAllowedToken`, `enableAllowedToken`; `addCustodianAddress`; `setStablesDeltaLimit`; `setMinter` | Reachable only through a queued timelock operation | | **Timelock Proposer** | Timelock | 3-of-5 Safe | Queue an operation | | | **Timelock Executor** | Timelock | 3-of-5 Safe | Execute a queued operation after the delay | | | **Timelock Canceller** | Timelock | MPC vault | Cancel a queued operation | Can stop a queued change, never make one | | **Gatekeeper** | Minting | MPC vault + external party | `disableMintRedeem`; `removeMinterRole`, `removeRedeemerRole`, `removeCollateralManagerRole` | Can only take powers away, never grant them. One holder is Tori, the other an external party | | **Whitelister** | Minting | MPC vault | `addToWhitelist`, `addToWhitelistBatch`, `removeFromWhitelist` | Mint and redeem are whitelist-gated at the contract, so this role decides who can transact at all | | **Collateral Manager** | Minting | MPC vault | `transferToCustody` | Destinations are limited to custodian addresses already registered through the timelock | | **Minter** | Minting | 3 EOAs | `mint()` | Submits user-signed EIP-712 orders; cannot originate one | | **Redeemer** | Minting | 3 EOAs | `redeem()` | As Minter | | **Blacklist Manager** | strUSD | Safe + EOA | `addToBlacklist`, `removeFromBlacklist`, and their batch forms | Compliance screening | | **Rewarder** | strUSD | Safe + Distributor contract | `transferInRewards`, `reportLoss` | One holder is a contract, not a key | | **Reward Operator** | Distributor | MPC vault | Trigger a scheduled distribution | Cannot change the amount | The Minter can submit an order a user signed, and nothing else. The Gatekeeper can strip the role in a single transaction without a multisig quorum. ## What the 24-hour timelock gates The timelock is [`0x7af35ab3E5373dA511c5F1331f44335a36dA1A55`](https://etherscan.io/address/0x7af35ab3E5373dA511c5F1331f44335a36dA1A55) and its minimum delay is 86,400 seconds. It holds the Timelock Admin role on the core contracts, which means these four operations cannot happen quietly: * **Contract upgrades.** A new implementation for trUSD, strUSD or Minting is queued in public first. * **A new collateral asset.** Adding one is timelocked; removing or disabling one is immediate, because the fast direction should be the safe direction. * **A new custody destination.** `addCustodianAddress` is timelocked. This is the operation that decides where deposited collateral can go, so it is the one most worth watching. * **Raising the stablecoin delta limit.** Anyone can watch the queue on Etherscan. A queued operation that nobody expected is visible for a full day before it can execute, and the canceller sits on a key that can stop it in one transaction. ## Rate limits Mint and redeem are bounded per block, per asset and globally, at the contract level. The bound is checked on every call and applies to the Minter and Redeemer roles regardless of what order they were handed. Changing a limit is an Owner function, so it takes the 3-of-5 Safe; it is not something an operational key can widen for itself. ## Check it yourself Every role assignment in this table is readable from the chain, and none of it needs to be taken on trust: * **Who holds a role**: `hasRole(role, address)` on the contract * **The Safe quorum**: `getThreshold()` and `getOwners()` on the Safe * **The timelock delay**: `getMinDelay()` on the timelock * **What is queued right now**: the timelock's events on Etherscan MPC thresholds are held in the custody provider's policy engine rather than on-chain. We are having them confirmed by the provider and independently attested, which we intend to publish alongside our proof-of-reserves data.