Governance
Torq governance roles, powers, timelocks, emergency fields, and upgrade process.
Governance is the system for changing sensitive Torq state without turning every operator into an unbounded administrator.
Governance covers permissions, timelocks, critical roles, oracle and IRM transitions, emergency fields, contract ownership, and upgrade or release processes.
Governed change
Sensitive changes move through permission checks, timelocks, execution, and observation
A role prepares a bounded change.
Permissions, entity scope, and route are evaluated.
Timelock applies when the route requires delay.
Wallet execution applies the approved operation.
Projected state confirms the final result.
Governance context
Aave public docs describe token-holder governance for protocol decisions. Morpho Vault V2 docs describe role separation such as owner, curator, allocator, and sentinel responsibilities. Torq governance is built into the operating action path: role, entity, action family, timelock route, wallet execution, and post-write projection all matter before a change is considered complete.
Governance roles
| Role | Power | Restriction |
|---|---|---|
| Protocol manager | Operates global protocol settings and inventories. | Bound by permissions, timelocks, and active contract authority. |
| Guardian | Performs protective and recovery functions. | Narrow safety mandate; not a general business administrator. |
| Council | Participates in governed transitions. | Limited to configured governed actions. |
| Vault owner | Fields vault-level authority where assigned. | Scoped to vault and acceptance flow. |
| Asset manager | Manages credit programs and related surfaces. | Scoped to managed entities and action routes. |
| NAV reporter | Signs or submits valuation reports. | Valuation authority only where configured. |
| Operations SRE | Reviews incident and governed-action state where surfaced. | Review authority does not bypass protocol permissions. |
| Release manager | Reviews release readiness and evidence state where surfaced. | Readiness review does not convert advisory evidence into release proof. |
Powers
| Power | Examples |
|---|---|
| Permission power | Grant, revoke, template, direct permission override, entity role assignment. |
| Market power | Create market, set access, set live/emergency state, set risk parameters. |
| Vault power | Deploy vault, set fees, market approvals, allocation, routing, ownership transfer. |
| Oracle power | Deploy or update feed/NAV/oracle adapters and safety settings. |
| IRM power | Deploy or transition interest rate models. |
| Emergency power | Recover critical roles, freeze unsafe actions, resolve emergency borrow freeze. |
| Incident review power | Review stakeholder incident reports, degraded-state context, and governed-action state. |
| Release review power | Review release readiness and evidence status without weakening release certification requirements. |
Timelocks
A timelock is a required waiting period before a sensitive change can execute. It gives affected parties time to observe pending changes and prevents instant execution of certain high-impact operations.
| Timelock state | Meaning |
|---|---|
| Queued | Operation exists but is not executable yet. |
| Ready | Required delay has elapsed. |
| Executed | Operation has run. |
| Cancelled | Operation was stopped before execution. |
| Expired or invalid | Operation cannot execute under current conditions. |
A governance action is not just "approved" because someone clicked a button. It can be queued, waiting, executable, executed, cancelled, or still invisible until indexed state catches up.
Emergency fields
Emergency fields are for protective or recovery situations, such as:
- recovering a critical role
- resolving expired emergency borrow freeze state
- pausing or blocking risk-increasing market behavior
- responding to stale oracle or NAV paths
- guiding operators through Incident Protection
Emergency actions still require authority. They are not a shortcut around the permission model.
Upgrade process
The manual does not assert a live production upgrade policy unless it is present in source. The source-backed process is:
- Identify affected contracts, configs, routes, APIs, schemas, and read models.
- Classify boundary governance impact.
- Map economic invariants and dependency-loss risks for value-affecting changes.
- Run required tests and checkers.
- Deploy through the configured release/deployment path.
- Reindex and verify application state.
- Update generated source maps and coverage reports.
For reviewers
Governance evidence is in config/boundary-governance-contract.json,
apps/web/config/functionRegistry.json, apps/web/config/roleFunctionCatalog.json,
ProtocolPermissionManager.sol, ScopedEntityAuthority.sol, ScopedWorkspaceTimelockExecutor.sol,
and TorqTimelock.sol.