Why Are Passed Governance Proposals Delayed in Execution?

Voting approval does not mean automatic execution. After a proposal passes, it typically must go through three stages: a timelock waiting period, execution queue scheduling, and manual triggering by an executor. The 2025 Scroll DAO governance halt exposed the disconnect between governance voting and actual execution.

Step 1: Confirm the execution flow after a vote passes — the timelock delay window

What to do: Check the project's timelock contract parameters and determine whether the proposal must wait for the timelock period.

How to do it:

• After a governance proposal passes, it enters the Timelock queue rather than being executed immediately.

• Common timelock delays are 2–3 days. For example, Scroll DAO's governance design includes a 3-day timelock window; OpenZeppelin's TimelockController default delay is also usually set within this range.

• This period serves as a final review window for the community — if problems are found, participants can exit or launch opposition during this time.

When it's done: You have confirmed the proposal's estimated time of execution (ETA) and know how long you still need to wait.

Step 2: Check the timelock status using a block explorer

What to do: On Etherscan or a similar block explorer, use the "Read Contract" section to call query functions of the timelock contract.

How to do it:

• isOperationPending(id): Confirms whether the operation is still waiting.

• isOperationReady(id): Confirms whether the operation has reached its executable time.

• getTimestamp(id): Returns the exact timestamp when the operation becomes executable.

• Convert the returned timestamp to your local time to see the earliest time the proposal can be executed.

When it's done: You have found the proposal's status — "Pending", "Ready", or "Done".

Key reminder: A timelock status of "Ready" only means "it can be executed", not "it has been executed". Execution requires someone (usually the executor role) to manually call the execute function.

Step 3: Check whether the executor role is assigned and active

What to do: Confirm who has the permission to execute the proposal and whether that person or entity is still on duty.

How to do it:

• OpenZeppelin's TimelockController has two roles: PROPOSER_ROLE (proposer) and EXECUTOR_ROLE (executor).

• After a proposal passes, an address holding the EXECUTOR_ROLE must call the execute method.

• If the executor is a multisig wallet of the DAO, check whether the multisig is functioning normally. If the executor is the project team, check whether there is a dedicated person responsible for this operation.

• Scroll DAO case: After the governance lead left, even though votes passed, execution stalled — "who clicks the execute button" became the problem.

When it's done: You have identified who the current executor is and whether they are able and willing to execute.

Step 4: If the timelock status is "Done", verify whether execution succeeded

What to do: Look for the CallExecuted event to confirm whether the proposal was truly executed.

How to do it:

• In the event logs of the timelock contract, find the CallExecuted event — it records the execution time and the executor.

• If there is only a CallScheduled event but no CallExecuted, the proposal is still waiting for execution.

• If the proposal status shows "Done" but the intended action didn't take effect, the execute call may have succeeded on the timelock side, but the target contract call failed (e.g., due to changed preconditions).

When it's done: You have confirmed whether the proposal was actually executed or is stuck at some stage.

Prerequisites

Before tracing, make sure you know the timelock contract address and the operation ID corresponding to the proposal (usually found in post-vote announcements or on-chain logs).

Common causes of failure

• Executor did not act in time: After the timelock expires, execution is not automatic; it must be manually triggered by the executor. If the executor is on leave or forgets, the proposal remains stuck in "Ready".

• Executor resignation or role change: The Scroll DAO incident shows that after the governance lead left, passed proposals stalled because no one advanced them.

• Proposal depends on off-chain steps: Some proposals require both on-chain execution and off-chain coordination (e.g., updating the frontend, releasing documentation). Even if the on-chain part is done, users may feel it "hasn't been executed" if the off-chain part lags.

Risk reminders

• Fund risk: The timelock delay is a safety mechanism, but it's also a risk window — if the proposal content is dangerous, the delay gives time to exit but does not prevent execution automatically.

• Account risk: If a proposal shows "Ready" but remains unexecuted for a long time, the execution chain of governance may be broken. For projects with large assets, this break can affect fund management.

The sign that you have correctly understood: You called isOperationReady(id) on the timelock contract, or saw the corresponding CallScheduled and CallExecuted events. If you can clearly say whether the proposal is still waiting for the timelock to expire, stuck in "Ready" waiting for someone to click the button, or already executed — then you truly understand why a passed proposal "hasn't been executed yet".