How to View Pending Operations in a Timelock Contract

The core method for viewing pending operations in a timelock is: go to a block explorer (such as Etherscan), find the timelock contract, read its queuedTransactions mapping, or look for the CallScheduled event, and you will see all queued operations. The pending operations in a timelock are not pending transactions, but contract calls that have been approved, are counting down, and are waiting to be executed.

Step 1: Find the timelock contract address

Objective: Obtain the address of the timelock contract you want to query.

How to do it:

• If the project has publicly disclosed the timelock address, you can usually find it in official documentation or the governance page.
• If you don't know the address, check the admin or owner of the project's main contract (e.g., the proxy contract); many projects set the timelock as the admin.
• On Etherscan or BscScan, searching for the project name + "Timelock" may also find it.

Completion standard: You have obtained a contract address starting with 0x and have confirmed that it is a timelock contract, not a regular wallet.

Step 2: Go to the contract's "Read Contract" page

Objective: Open the timelock contract address on the block explorer and switch to the "Read Contract" tab under "Contract".

How to do it:

• After entering the address on Etherscan, click the "Contract" tab.
• If the contract has verified source code, you will see the "Read Contract" and "Write Contract" buttons.
• Click "Read Contract" to expand the list of all read‑only functions.

Completion standard: You have entered the read‑only function list page and can see various query methods.

Step 3: Call queuedTransactions or isOperation to query pending operations

Objective: Use the query functions provided by the timelock to find the IDs of operations that are currently queued.

How to do it:

• A standard timelock contract usually has a queuedTransactions mapping; input an operation ID (bytes32) and it returns true/false indicating whether that operation is in the queue.
• OpenZeppelin's TimelockController provides richer query functions:
  • isOperationPending(id): returns whether the operation is in a "pending" state (scheduled but not yet executed).
  • isOperationReady(id): returns whether the operation has reached its executable time (countdown finished).
  • getTimestamp(id): returns the timestamp when the operation becomes executable.
  • getMinDelay(): returns the current minimum delay of the timelock.
• You need to know the operation ID to query it; operation IDs can be obtained from the CallScheduled event.

Completion standard: You have successfully called the query function and received a true/false or timestamp return value.

Key reminder: Most timelock contracts have a queuedTransactions mapping of type mapping (bytes32 => bool), which can only check "whether a certain ID exists", not list all IDs. To get a list of all pending operations, you must reconstruct them using events.

Step 4: Use the "Events" tab to list all pending operations

Objective: Switch to the contract's "Events" tab and look for the CallScheduled event.

How to do it:

• On the contract details page, find the "Events" or "Event Logs" tab.
• In the event list, look for CallScheduled (or QueueTransaction, depending on the implementation version).
• This event is emitted every time an operation is scheduled in the timelock and contains key fields such as the operation ID (id), target contract (target), call data (data), predecessor (predecessor), and delay time (delay).
• After parsing the event logs, you can obtain a list of all operations that have ever been scheduled. Compare that with the ExecuteTransaction event (emitted after an operation is executed), and you can filter out the operations that have been scheduled but not yet executed.

Completion standard: You have obtained a list of pending operation IDs from the event logs, or confirmed that there are no pending operations currently.

Step 5: Use getOperationState to query the current state of an operation

Objective: If you are using OpenZeppelin's TimelockControllerEnumerable, you can directly query the state enum value of an operation.

How to do it:

• Some timelock implementations (such as the enumerable version by OpenZeppelin) provide a getOperationState(id) function that returns one of four states: Unset, Waiting, Ready, Done.
• Lido Finance's timelock tools also offer similar commands: get-operation-state, is-operation-pending, is-operation-ready, etc.

Completion standard: You can clearly determine which stage of the timelock lifecycle a given operation is in – whether it has just been scheduled, is in the countdown, is executable, or has been executed.

Prerequisites

Before proceeding, make sure you are using the correct blockchain explorer (Etherscan for Ethereum, BscScan for BSC). If the contract source code is not verified, the Read Contract function is unavailable, and you can only rely on event log analysis.

Common failure causes

• Cannot get the pending list: Standard timelock contracts do not have a function to "list all queued operations"; you can only reverse‑engineer them through event logs. This is a design limitation, not an operational error.
• Confusing the timelock's "pending operations" with regular "pending transactions": Operations in a timelock are contract calls, not wallet transfers. You need to query them using contract methods, not by looking at the "Transactions" list.
• The queuedTransactions query returns false, but you are certain there are operations queued: Check whether the ID you entered is correct. The operation ID is generated by keccak256(abi.encode(target, value, signature, data, eta)). Even a one-byte difference will cause a mismatch.

Risk reminder

• Account risk: Block explorer read‑only operations are safe; you do not need to connect a wallet. Do not use "Write Contract" to execute any operations unless you are certain you are the authorized executor.
• Fund risk: If a malicious operation is queued in the timelock (e.g., upgrading the contract to a vulnerable version) but the executable time has not yet been reached, you have the opportunity to exit or initiate opposition. Monitoring the CallScheduled event is a key method for detecting risks in advance.

Operation completion confirmation: You have successfully read the scheduling records from the timelock contract's CallScheduled event, or confirmed the pending state of an operation via isOperationPending. If you see a CallScheduled record but the corresponding ExecuteTransaction has not yet appeared, then it is a pending operation. Going forward, you can note the operation ID and estimated executable time, keep a close watch before that time arrives, and if the operation involves a contract upgrade or a fund transfer, assess whether any countermeasures are needed.