Governance
T3tris vaults use role-based access control. Instead of one key doing everything, you grant specific permissions to specific wallets. This lets you run a vault alone or delegate to a team, without giving up full control. You manage this from the Governance tab.
The two admins
Every vault has two independent super-admin roles:
| Admin role | Controls |
|---|---|
| Vault admin | Most operating roles: settlement, fees, lifecycle, whitelists, identity, and more. Usually the vault owner. |
| Protocol governance | A small set of protocol-level roles: silos, treasury, NAV configuration. Held by the T3tris foundation, not transferable by you. |
The two are independent. The vault admin cannot touch protocol-governance roles, and the reverse is also true. As a curator, you operate through the vault admin and its operating roles.
Operating roles by area
Beneath the vault admin sit the day-to-day operating permissions, grouped by function:
| Group | Example permissions |
|---|---|
| Lifecycle | Open, close, pause, unpause, enable/disable end-of-fund. |
| Settlement | Settle, settle deposits, settle redemptions. |
| Fees | Claim fees, update the entry/exit/management/performance rates. |
| Deposit | Enable deposits, enable/set whitelist entries. |
| Operator | Update curator, fee recipient, oracle; sweep; manage shares. |
| Metadata | Set share name/symbol, set the content hash, enable transfers. |
| Silo | Update the sync/deposit/redeem silos. |
| Oracle | Set total assets (NAV) and the deviation bounds. |
You grant each operator only the permissions it needs.
Bootstrapping a new vault
A freshly deployed vault has no operating roles assigned. Only the owner can act until you bootstrap it. Two options:
Option A, Solo. Grant every operating role to one wallet, in one transaction. No admin power is left behind afterward. This is the fastest way to start operating alone.
Option B, Granular RoleSets. Define named permission bundles (RoleSets) and assign them to specific wallets. Example: a Settler RoleSet for the wallet that runs settlements, a Treasury RoleSet for the wallet that claims fees, a Curator RoleSet for strategy configuration. You pick the permissions, name the set, and list the wallets, all in one transaction. RoleSets are reusable, which keeps a multi-person operation organized.
Grant each wallet only what it needs. Use a hot wallet for routine settlement. Keep the vault admin on a more secure wallet, ideally a multisig.
Viewing and revoking roles
The Governance tab lists every wallet holding at least one operating role. For each wallet you can see its permissions, grant more (tick a role), or revoke them (untick a role), then apply the changes in one transaction. Super-admin and protocol-governance roles are shown but cannot be revoked here.
Transferring the vault admin
The vault admin role moves through a two-step transfer:
- The current admin initiates a transfer to a recipient address.
- The recipient accepts to complete it.
- The initiator can cancel any time before acceptance.
This prevents sending admin control to the wrong address by accident. The role only moves once the recipient accepts.
Whoever holds the vault admin can reconfigure the vault and reassign roles. Use a secure wallet, prefer a multisig for production vaults, and treat an admin transfer like moving funds.
The protocol governance transfer
The protocol-level super-admin also has a two-step transfer, but only the current operator or the pending recipient can see or use it. Vault owners and curators do not interact with it.
The metadata editor seat
A separate, off-chain metadata editor seat controls who can edit the vault's public identity: description, visibility, curator name. It defaults to the owner and transfers with a signature, no transaction needed. See Information.