Access Control, Upgrades and Governance
Introduction
This branch maps who can change protocol code, parameters, funds, or availability; how quickly; through which keys and contracts; and with what monitoring, escape, and recovery constraints.
Why It Matters
An “admin” is a bundle of protocol powers and operational risks. Upgradeability can patch defects but also introduces initialization, storage, authorization, capture, and permanent-control failure modes.
Mental Model
Draw an authority graph from human/key origin through multisig, governor, timelock, proxy admin, implementation, guardian, and pause mechanism to each protected transition. Treat delay and observability as security properties.
Questions This Branch Answers
- Which actor can perform each privileged transition, and when?
- What does an upgrade preserve, invalidate, or silently reinterpret?
- How are emergency powers bounded and eventually removed or reviewed?
Scope
Ownership/roles, separation of duties, multisigs, timelocks, guardians, governance lifecycle, bounded parameters, capture, proxy storage, initializers, UUPS/transparent/beacon patterns, and immutability tradeoffs.
Out of Scope
Governance-token valuation, legal entity design, universal voting recommendations, social-layer guarantees, and production multisig key ceremonies.
Dependencies
contract architecture, delegate calls and storage, and signature authority.
Candidate Note Roadmap
roles-ownership-and-separation-of-duties— Turn vague admin power into named, minimal capabilities.multisig-and-admin-key-risk— Model signer thresholds, compromise, loss, and execution ownership.timelocks-and-emergency-guardians— Combine delayed change with bounded incident controls.governance-lifecycle— Trace proposal, voting, queuing, execution, cancellation, and expiry.parameter-bounds-and-governance-capture— Enforce safe ranges and examine concentrated influence.proxy-storage-and-initializers— Inspect slots, initialization state, and implementation binding.uups-transparent-and-beacon— Compare upgrade authority and call-routing patterns.immutable-vs-upgradeable-deployments— Choose patchability, escape hatches, or immutability explicitly.
Future Project
A Governed Treasury with separated roles, multisig-originated proposals, timelocked execution, parameter bounds, a narrow guardian, and a storage-compatible educational upgrade.
Initial Invariants
Unauthorized proposals never execute; execution respects minimum delay; guardian actions remain within emergency scope; upgrades preserve declared storage/accounting properties; initialized components cannot be taken over again.
Initial Threat Model
Key compromise or loss, governance capture, quorum/flash-vote manipulation, malicious proposal payloads, initializer takeover, selector/storage collisions, upgrade rollback failure, and permanent or abusive pause.
Primary Sources
OpenZeppelin access/governance/upgrades documentation, relevant ERC/EIPs, and deployment-system references in SOURCES.md.
Connects to: security labs, rollup admin risk, and role monitoring.