[Sample] Who can upgrade our contracts today?

SAMPLE CONTENT — Placeholder for the Security Decisions series. This hypothetical write-up is for reviewing content and layout.

The decision

Who can upgrade our contracts today? Trace the live authorization path from each proxy or upgrade mechanism to the accounts, roles, and governance controls that can authorize a change.

When it arises

A protocol has launched and its team needs to verify that deployed permissions match its intended governance model.

Failure path

A project expects upgrades to pass through governance. A privileged account retains a separate upgrade route. Compromise of that account allows an implementation change outside the expected review process.

What to verify

Identify each deployed proxy, implementation, and upgrade authority. Check current owners and roles on chain. Review multisig signers and threshold, timelock delay and roles, emergency permissions, and any route that can bypass the intended path. Confirm that alerts and the response process cover authority changes.

Evidence to request

Contract addresses and chain identifiers, verified source, current role and ownership reads, multisig configuration, governance proposal flow, timelock settings, permission-change history, and a maintained owner register.

Scope and limits

This review describes the observed authorization structure at a stated block or time. It does not prove that signers, devices, or off-chain approval processes cannot be compromised.

Relevant example — hypothetical

The intended upgrade authority is a timelock, but an emergency role can upgrade directly. Documenting both paths changes the team's assessment of its actual control structure.

Related reading

OpenZeppelin Access Control: https://docs.openzeppelin.com/contracts/4.x/access-control

QuillAudits case studies: https://www.quillaudits.com/case-studies

Next step

Review deployed authority against the intended governance model and assign an owner for keeping the permission inventory current.