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 is0x7af35ab3E5373dA511c5F1331f44335a36dA1A55
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.
addCustodianAddressis 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.
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()andgetOwners()on the Safe - The timelock delay:
getMinDelay()on the timelock - What is queued right now: the timelock’s events on Etherscan