Smart contract timelock
how to verify it actually protects you
A timelock forces a delay between a governance decision and its execution. A 48-hour delay is meaningful protection. A 5-minute delay is not. Here is how to find the timelock, read the delay, and verify that it covers what it claims to.
Scan a contractFree · No sign-up · Timelock resolution included
Every scan is powered by the XemaS Semantic Intelligence Platform · answers carry their evidence and coverage state
The reaction window between a change and its consequence
Without a timelock, a protocol change - a fee increase, a parameter adjustment, an upgrade to malicious code - takes effect in the same block it is submitted. The first users know about it is when it is already done.
A timelock creates a mandatory delay. When governance votes to change something, the transaction is queued but not yet executed. During that delay window, anyone can see exactly what is about to happen and act: withdraw liquidity, exit positions, cancel the proposal through a guardian, or organise community resistance.
Changes are instant. No warning possible for users or the community.
No protectionPractically speaking, most users cannot react within hours. Bots can; humans cannot.
InsufficientEnough for on-chain monitors and experienced users to detect and exit. Borderline.
Minimum viableStandard for serious DeFi protocols. Provides meaningful reaction time for the community.
GoodUsed by the highest-security protocols. Reduces emergency response capability but maximises user safety.
StrongHow timelocks fail to protect
Delay is too short to matter
A timelock with a 5-minute or 1-hour delay looks like security but provides none. A malicious change can be queued and executed before any human notices. Minimum meaningful delay: 24 hours.
Timelock controlled by a single key
If the timelock's proposer and executor roles are both held by a single EOA wallet, one key compromise gives an attacker full control. The timelock becomes a staged single-owner attack rather than a protection mechanism.
No timelock on upgrades at all
Many proxy contracts allow instant upgrades with no delay. The admin can swap in malicious code in a single block, faster than any block explorer alert or on-chain monitor.
Timelock bypassed via proxy admin
Some architectures put a timelock on protocol parameters but not on the proxy upgrade itself. A protocol that announces "all changes are timelocked" while the proxy admin remains instant-upgradeable is only partially protected.
Emergency bypass functions
Legitimate emergency functions (respond to exploits) sometimes include an instant-execute path that bypasses the timelock delay. If this path exists, confirm it is protected by a high-threshold multisig or governance vote.
How to verify a timelock
Find the contract's admin or governance address
The timelock sits between the owner/governance and the protocol. Start by identifying who controls the contract (proxy admin, governance token, owner address), then check whether that controller is itself a timelock contract.
Identify the timelock contract type
The most common implementation is OpenZeppelin's TimelockController. It has a minDelay function, PROPOSER_ROLE, EXECUTOR_ROLE, and CANCELLER_ROLE. Others include Compound's Governor Bravo and custom implementations - each has slightly different interfaces.
Read the minimum delay
Call minDelay() on the timelock contract. The result is in seconds. Divide by 86400 to convert to days. A value of 0 or anything under 86400 (24 hours) provides minimal real-world protection.
Check the proposer and executor roles
In OpenZeppelin's TimelockController, check who holds PROPOSER_ROLE and EXECUTOR_ROLE. If both are held by the same EOA wallet, the timelock is protected by only one key. If the executor role is held by address(0), anyone can execute queued transactions - which is actually safer (no concentrated key risk).
Verify whether ALL admin functions route through the timelock
A timelock that governs token parameters but not proxy upgrades provides partial protection. Check that the governance address on the proxy is the timelock (not a direct EOA or multisig), and that there is no backdoor bypass.
Free · No sign-up required
What to avoid assuming
Treating "timelock exists" as sufficient
The delay duration matters as much as the existence. A 60-second timelock is not a protection mechanism. Always read the actual delay value.
Not checking what the timelock covers
A timelock on governance votes does not protect against proxy upgrades if the proxy admin is separate. Verify that the timelock is in the execution path for the specific risk you care about.
Ignoring the CANCELLER_ROLE
Who can cancel queued transactions matters. If the team controls cancellation and the community controls execution, the team can cancel any transaction they do not like, making the governance process one-sided.