DeFi governance: who can execute, upgrade or pause the protocol?

A successful governance vote answers whether a proposal passed its voting rules. It does not, by itself, reveal who can change the protocol, how long they must wait or whether another administrator has a separate route to the same result.

The practical way to read governance is to trace an important action from decision to execution. Which contract changes? Which function performs the change? Which account may call it? What other account can grant that permission or replace the code? This produces a map of powers that a voting dashboard alone cannot supply.

Follow the proposal into the transaction

OpenZeppelin's governance guide describes a proposal as concrete actions: target addresses, encoded function calls and any ETH sent with them. The written description explains intent, but those transaction details define the requested operation. A proposal that says it updates a parameter should be checked against the actual target and encoded value.

In its Governor-plus-timelock design, a successful proposal is queued before execution. The timelock needs to hold the relevant assets or permissions because it makes the eventual call. Merely deploying a voting contract does not transfer authority over another contract to it. Ask where that authority is actually assigned.

A timelock delays a specified path

The TimelockController API separates scheduling from execution. A proposer schedules an operation; an executor submits it once it is ready; a canceller can stop a queued operation. The operation's data identifies what may execute. Where execution is open to anyone, that openness does not let everyone invent a new operation or skip its delay.

A hypothetical operation scheduled at Monday 12:00 with a 48-hour delay becomes eligible no earlier than Wednesday 12:00, assuming the relevant chain timestamp follows that timeline. It does not automatically execute then. Someone still has to submit a valid transaction, and prerequisites must be satisfied. Eligibility, successful execution and the resulting state are separate observations.

The same API requires changes to the minimum delay to be called by the timelock itself through a scheduled operation. That is a property of this implementation, not a universal rule for anything called a timelock. A protocol can also have authorities outside it. A delay only governs actions that actually pass through that controller.

Map administrator, upgrade and emergency powers

OpenZeppelin AccessControl assigns an administrator role to each role. That administrator can grant and revoke the associated permission. Consequently, a supposedly narrow current permission set is incomplete without knowing who may expand or reassign it. The default administrator is especially consequential unless the contract deliberately changes the role hierarchy.

Upgrade rights add another layer. The proxy documentation distinguishes transparent proxies, whose administration is handled through a ProxyAdmin, from UUPS implementations that define authorization through _authorizeUpgrade. Reviewing today's business functions is insufficient if another account can replace their implementation. The relevant question is which authorization protects that replacement and whether it follows the advertised governance process.

Emergency controls also need function-level reading. OpenZeppelin's Pausable module only affects functions to which its pause checks are applied. A pause label alone cannot tell you whether deposits, withdrawals, transfers or all three are stopped. Identify both the pause authority and the resume authority, plus their respective delays. Different scopes can produce very different outcomes for a user trying to leave.

Build a permissions worksheet

Start from the verified deployment and follow contract ownership or role assignments until the controlling mechanism becomes clear. If that controller is a multisig, record the signing threshold and how its owners can change; multisig control and recovery explains why the threshold is only part of the picture.

OpenZeppelin's access-control guide notes that base AccessControl does not enumerate all members on-chain. Role-grant and role-revocation events may be needed to reconstruct membership. Record the chain and block of the check: a historic audit or deployment diagram may describe permissions that have since changed.

Finally, assess whether the advertised response window is usable. A timelock can provide notice, but the presence of a timer does not prove that withdrawal liquidity or an unpaused exit will be available. That is an inference to test against the product's separate exit rules. When reviewing an incident, the same permissions map helps identify the authority used by the transaction, complementing evidence-based security incident analysis.