A timelock is a smart contract that sits between the people who control a protocol and the protocol itself. Every sensitive change, such as an upgrade, a fee change or a new admin, is first scheduled publicly and can only be executed after a fixed delay, for example 48 hours. During that window anyone can see what is coming, and users who disagree can leave.
Why Use a Timelock?
- Trust: users do not have to trust that admins will behave; they can see every change before it takes effect.
- Protection against stolen keys: if an attacker gains control of an admin key or multisig, the delay gives the team time to notice and respond before the malicious change executes.
- Governance: in a DAO, the timelock executes proposals that passed a vote, after a waiting period.
How We Set It Up
- What goes through the timelock: upgrades, role changes, fee and parameter changes, and treasury movements above a threshold. Not everything needs a delay.
- What does not: an emergency pause should be fast. A separate guardian role that can only pause, not change anything, covers that.
- The delay: long enough for users and monitoring to react, short enough to fix urgent problems. 24 to 72 hours is a common range.
- Proposers and executors: usually a multisig proposes, and execution after the delay is open or restricted, depending on the setup.
- Monitoring: alerts on every scheduled operation, so your team and community see changes the moment they are queued.
We usually build on OpenZeppelin's TimelockController and wire it into your access control and upgrade setup.
Frequently Asked Questions about Timelock Contracts
Does a timelock slow down every action?
Only the actions you route through it. Day-to-day operations and emergency pauses can stay fast; the timelock is for changes that affect users' funds or rights.
Can a scheduled change be cancelled?
Yes. Accounts with the canceller role can cancel a queued operation before it executes, which is exactly what you need if a malicious or wrong change has been scheduled.
How long should the delay be?
That depends on how fast your users and team can react and on how urgent fixes typically are. We help you choose, and the delay itself can only be changed through the timelock.
Who owns the code?
Ownership of the source code is set out in the contract, and the code can be fully yours, including documentation and tests.
Part of our smart contract development services. Planning an audit? See smart contract audit support.
Make Changes Transparent
Tell us how your protocol is governed today. We will design a timelock setup that protects users without blocking your team.