Skip to main content
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 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. 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

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 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.