× 
Governance
Governance decides who holds privileged power over the protocol and how that power is constrained, delayed, and split.
These controls require an enumerated list of who can do what, and they constrain how those powers combine. No one person should hold a combination of powers that enables an exploit or creates an incentive to misuse it.
All privileged roles are documented, with their capabilities enumerated.
Roles follow least privilege. No single role can both modify parameters and move funds.
Role assignments are verifiable on-chain.
No actor holds duties whose overlap creates a perverse incentive.
No actor holds duties whose overlap creates an attack vector.
The holder of the upgrade authority can replace the program. Documentation must cover who holds that power, how it is exercised, and how users can confirm what is deployed. Multisig control and governance gating are scored separately, and a protocol may satisfy either or both.
The program upgrade authority is defined.
The upgrade authority is multisig-controlled.
The upgrade authority is governance-gated.
If the program is upgradeable, the upgrade path is documented and users can verify the deployed version through the verified builds API.
Authority transfer and revocation procedures are in place.
A timelock delays privileged actions long enough for users to exit and observers to object. The delay only protects users if bypass conditions are documented, scoped, and publicly auditable.
Privileged actions are subject to enforced on-chain timelocks, with duration proportional to impact.
Emergency bypass conditions are defined, documented, and scoped.
Timelock duration is publicly auditable.
Bypass history is publicly auditable.
Multisig strength depends on configuration details that are easy to leave undocumented, such as the threshold, who the signers are, how keys rotate, and how a signer is removed. Each must be written down, and no single entity may control a majority of keys.
The multisig threshold is documented.
The total signer count is documented.
The identity of each signer is documented.
The threshold follows m-of-n best practices relative to signer count.
Key rotation procedures are in place.
Signer removal procedures are in place.
No single entity controls a majority of keys.
Signer hardware wallets come from diverse vendors.
Collateral factors, liquidation thresholds, fees, and rate models change user outcomes directly. A carelessly changed parameter can liquidate positions that were never at risk. Parameter changes need the same governance as code changes, with defined owners, documented procedures, and a public record.
Collateral factors are governed by appropriate roles with documented change procedures.
Liquidation thresholds are governed by appropriate roles with documented change procedures.
Fee structures are governed by appropriate roles with documented change procedures.
Rate models are governed by appropriate roles with documented change procedures.
Parameter bounds and their downstream impact on users are specified.
Historical parameter changes are logged and publicly auditable.