Bird
Raised Fist0
Blockchain / Solidityprogramming~5 mins

Timelock pattern in Blockchain / Solidity

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction

The Timelock pattern helps control when certain actions can happen in a blockchain contract. It adds a waiting period before changes take effect, making things safer and more transparent.

When you want to delay important contract changes to give users time to react.
When you want to schedule a transaction to happen only after a certain time.
When you want to add a safety buffer before executing sensitive operations.
When you want to improve trust by making contract upgrades visible before they happen.
Syntax
Blockchain / Solidity
contract Timelock {
    uint public unlockTime;
    address public owner;

    constructor(uint _waitTime) {
        owner = msg.sender;
        unlockTime = block.timestamp + _waitTime;
    }

    function execute() public {
        require(block.timestamp >= unlockTime, "Too early to execute");
        // perform the action
    }
}

block.timestamp gives the current time in seconds since Unix epoch.

The require statement stops the action if the time is not reached yet.

Examples
This sets the unlock time to 1 day from now.
Blockchain / Solidity
uint public unlockTime = block.timestamp + 1 days;
This checks if the current time is past the unlock time before continuing.
Blockchain / Solidity
require(block.timestamp >= unlockTime, "Action locked");
This function lets you set a custom delay before the action can run.
Blockchain / Solidity
function scheduleAction(uint delaySeconds) public {
    unlockTime = block.timestamp + delaySeconds;
}
Sample Program

This contract sets a time lock when created. The execute function can only run after the unlock time. If called too early, it stops with an error.

Blockchain / Solidity
pragma solidity ^0.8.0;

contract SimpleTimelock {
    uint public unlockTime;
    address public owner;

    constructor(uint _waitTime) {
        owner = msg.sender;
        unlockTime = block.timestamp + _waitTime;
    }

    function execute() public view returns (string memory) {
        require(block.timestamp >= unlockTime, "Too early to execute");
        return "Action executed!";
    }
}
OutputSuccess
Important Notes

The Timelock pattern helps protect users by giving them time to react before changes happen.

Always test your time calculations carefully to avoid mistakes.

Remember that block timestamps can be influenced slightly by miners, so don't rely on exact precision.

Summary

The Timelock pattern delays actions until a set time, improving security and trust.

It uses the blockchain's current time to check if the delay has passed.

This pattern is useful for upgrades, sensitive transactions, and scheduled operations.

Practice

(1/5)
1.

What is the main purpose of the Timelock pattern in blockchain smart contracts?

easy
A. To delay certain actions until a specific time has passed
B. To speed up transaction processing
C. To encrypt user data
D. To reduce gas fees

Solution

  1. Step 1: Understand the Timelock pattern concept

    The Timelock pattern is designed to delay actions in smart contracts until a set time has passed.
  2. Step 2: Identify the purpose of the delay

    This delay helps protect users by preventing instant changes that could be harmful or unexpected.
  3. Final Answer:

    To delay certain actions until a specific time has passed -> Option A
  4. Quick Check:

    Timelock pattern = delay actions [OK]
Hint: Timelock means waiting before action happens [OK]
Common Mistakes:
  • Thinking it speeds up transactions
  • Confusing with encryption
  • Assuming it lowers gas fees
2.

Which of the following Solidity code snippets correctly enforces a timelock using block.timestamp?

function execute() public {
  require(__________, "Too early to execute");
  // action code
}
easy
A. block.timestamp >= unlockTime
B. block.timestamp < unlockTime
C. block.number >= unlockTime
D. block.difficulty > unlockTime

Solution

  1. Step 1: Understand the condition for timelock

    The action should only execute if the current time is equal or after the unlock time.
  2. Step 2: Choose the correct comparison

    Using block.timestamp >= unlockTime ensures the function runs only after the unlock time.
  3. Final Answer:

    block.timestamp >= unlockTime -> Option A
  4. Quick Check:

    Time check uses block.timestamp >= unlockTime [OK]
Hint: Use block.timestamp and >= for timelock checks [OK]
Common Mistakes:
  • Using < instead of >=
  • Using block.number instead of block.timestamp
  • Using unrelated block properties
3.

What will be the output of the following Solidity function call if block.timestamp is 1650000000 and unlockTime is 1650000100?

function canExecute() public view returns (bool) {
  return block.timestamp >= unlockTime;
}
medium
A. true
B. Revert with error
C. Compilation error
D. false

Solution

  1. Step 1: Compare block.timestamp and unlockTime values

    Given block.timestamp = 1650000000 and unlockTime = 1650000100, block.timestamp is less than unlockTime.
  2. Step 2: Evaluate the return statement

    The expression block.timestamp >= unlockTime evaluates to false.
  3. Final Answer:

    false -> Option D
  4. Quick Check:

    1650000000 >= 1650000100 = false [OK]
Hint: Compare timestamps carefully for true/false output [OK]
Common Mistakes:
  • Assuming >= means true when timestamp is smaller
  • Confusing block.timestamp with block.number
  • Expecting errors instead of boolean
4.

Identify the error in this Solidity timelock function and choose the fix:

uint256 public unlockTime;

function execute() public {
  require(block.timestamp > unlockTime, "Too early");
  // perform action
}
medium
A. Use block.number instead of block.timestamp
B. Change block.timestamp > unlockTime to block.timestamp >= unlockTime
C. Remove the require statement
D. Change unlockTime to block.timestamp

Solution

  1. Step 1: Analyze the require condition

    The condition block.timestamp > unlockTime disallows execution exactly at unlockTime.
  2. Step 2: Adjust condition to allow execution at unlockTime

    Changing to block.timestamp >= unlockTime allows execution starting from unlockTime.
  3. Final Answer:

    Change block.timestamp > unlockTime to block.timestamp >= unlockTime -> Option B
  4. Quick Check:

    Use >= to include unlockTime moment [OK]
Hint: Use >= to allow execution at unlock time [OK]
Common Mistakes:
  • Using > excludes unlockTime moment
  • Removing require loses protection
  • Using block.number causes wrong timing
5.

You want to create a timelock contract that allows an admin to schedule a withdrawal only after 1 day from scheduling. Which approach correctly implements this?

contract Timelock {
  address public admin;
  uint256 public unlockTime;

  constructor() {
    admin = msg.sender;
  }

  function scheduleWithdrawal() public {
    require(msg.sender == admin, "Not admin");
    unlockTime = block.timestamp + 86400; // 1 day
  }

  function withdraw() public {
    require(msg.sender == admin, "Not admin");
    require(block.timestamp >= unlockTime, "Too early");
    // withdrawal logic
  }
}
hard
A. Admin cannot schedule withdrawal
B. Withdrawal can happen immediately after scheduling
C. Correctly enforces 1-day delay before withdrawal
D. unlockTime is set incorrectly causing errors

Solution

  1. Step 1: Check scheduling sets unlockTime correctly

    The scheduleWithdrawal function sets unlockTime to current time plus 86400 seconds (1 day).
  2. Step 2: Verify withdraw enforces timelock

    The withdraw function requires current time to be at or after unlockTime, enforcing the delay.
  3. Final Answer:

    Correctly enforces 1-day delay before withdrawal -> Option C
  4. Quick Check:

    UnlockTime = now + 1 day, withdraw requires >= unlockTime [OK]
Hint: Add 86400 seconds and check block.timestamp >= unlockTime [OK]
Common Mistakes:
  • Not adding delay in schedule function
  • Using > instead of >= in withdraw
  • Not restricting functions to admin