Timelock

The governor decides, the timelock owns

In the reference architecture the governor runs the vote and queues the winning call somewhere else. OpenZeppelin states the ownership rule flatly: with a timelock extension in place, proposals are executed by the external timelock contract, so it is the timelock that has to hold the assets being governed.¹ The governor holds no funds.

That split is the point. OpenZeppelin describes TimelockController as a module that, set as the owner of an Ownable contract, enforces a delay on all owner-only maintenance operations, giving users of the controlled contract time to exit before a potentially dangerous operation is applied.¹ If your governor owns the treasury directly and a timelock sits beside it as decoration, you have the delay without the protection. Check which address holds the admin keys before you trust the diagram.

The delay is a window with two edges

Compound's Timelock.sol is the implementation most protocols forked, and its constants are worth reading rather than paraphrasing. GRACE_PERIOD is 14 days, MINIMUM_DELAY is 2 days, MAXIMUM_DELAY is 30 days. Queuing sets an execution timestamp at least one delay out, and execution reverts below that timestamp or above it by more than the grace period, with the message that the transaction is stale.²

So the delay is not a floor with open sky above it. A passed proposal nobody executes inside those 14 days dies and goes back through the vote. That is an operations failure rather than a security one, and it catches teams who treat the vote as the finish line. Somebody owns execution. Write it down next to who owns proposing.

Roles are the part that gets misconfigured

OpenZeppelin's TimelockController splits one admin into three roles. PROPOSER_ROLE schedules operations, EXECUTOR_ROLE executes them once due, CANCELLER_ROLE kills a scheduled operation before it lands. The constructor grants CANCELLER_ROLE to every address it grants PROPOSER_ROLE, so the two sets are identical unless you change them after deployment.³

Two consequences follow. Executor can be granted to the zero address, making execution permissionless, so anyone can push a due operation through and no single operator can quietly sit on it. And updateDelay only accepts a call from the timelock itself, so shortening the delay is a proposal that has to serve the current delay first.³ A timelock that can shorten its own delay on demand is not a timelock.

OpenZeppelin's own docs flag the risk in stacking proposers: because proposers have a say over every operation, they can cancel operations they disagree with, including one that would remove them.¹ Redundancy on that role is not free.

What the delay does not do

We went looking for a documented case in which a delay window was the recorded mechanism that let a community spot and cancel a malicious proposal, with a proposal identifier attached. We did not find one. Every source describing this benefit describes it as design intent.

That gap matters because a delay only works if somebody is watching the queue. Publishing calldata to an audience of nobody is not a control. With no monitoring on scheduled operations and no standing channel that reaches holders inside the delay, the mechanism is present in the contract and absent in practice.

Choosing the number

The delay should be at least as long as it takes your slowest relevant party to notice a queued change and act. For a lending market that means the largest borrower unwinding a position, not a Discord message getting read. Two days is the floor in the widely forked implementation.² Across the projects we have worked on, one flat delay for every action is usually the wrong shape: a parameter tweak and an implementation swap do not carry the same blast radius.

Then connect it back to the business. A long delay is a promise that users can leave before you change the rules on them, and that promise is worth something to the counterparties deciding whether to put size in your protocol. A short delay says you expect to move faster than your users can react. Pick deliberately, publish the reasoning, and treat any emergency path around the delay as a governance surface of its own.