Timelock pattern in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Timelock pattern

Start

↓

Request Action

↓

Set Timelock Expiry

↓

Wait Until Expiry

↓

Check Current Time >= Expiry?

No→Wait

Yes↓

Execute Action

↓

End

The Timelock pattern delays execution of an action until a set time has passed, ensuring a waiting period before the action runs.

Execution Sample

Blockchain / Solidity

uint public unlockTime;

function requestAction() public {
  unlockTime = block.timestamp + 1 days;
}

function executeAction() public {
  require(block.timestamp >= unlockTime, "Action is locked");
  // action code
}

This code sets a future unlock time when an action is requested, then only allows execution after that time.

Execution Table

Step	Action	block.timestamp	unlockTime	Condition	Result
1	Call requestAction()	1000000	1000000 + 86400 = 1086400	N/A	unlockTime set to 1086400
2	Call executeAction() at time 1005000	1005000	1086400	1005000 >= 1086400?	False - revert, cannot execute
3	Call executeAction() at time 1086400	1086400	1086400	1086400 >= 1086400?	True - action executes
4	Call executeAction() at time 1086500	1086500	1086400	1086500 >= 1086400?	True - action executes

💡 Execution stops if current time is less than unlockTime; action only runs after unlockTime.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
unlockTime	0	1086400	1086400	1086400	1086400
block.timestamp	N/A	1000000	1005000	1086400	1086500

Key Moments - 3 Insights

Why can't executeAction run immediately after requestAction?

Because unlockTime is set to a future timestamp (current time + 1 day). The execution_table row 2 shows the condition fails when current time is less than unlockTime.

What happens if executeAction is called exactly at unlockTime?

The condition block.timestamp >= unlockTime is true, so the action executes successfully as shown in execution_table row 3.

Does the unlockTime change after it is set?

No, unlockTime stays the same until requestAction is called again. The variable_tracker shows unlockTime remains constant after step 1.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of unlockTime after calling requestAction()?

A 1000000

B 1086400

C 0

D 1005000

💡 Hint

Check execution_table row 1 under unlockTime column.

At which step does the condition block.timestamp >= unlockTime become true for the first time?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

See execution_table Condition and Result columns for each step.

If the unlockTime was set to current time + 2 days instead of 1 day, how would step 2 change?

A Condition would still be false at step 2

B unlockTime would be less than block.timestamp

C Condition would be true at step 2

D executeAction would execute immediately

💡 Hint

Compare unlockTime and block.timestamp values in execution_table row 2.

Concept Snapshot

Timelock pattern delays actions until a set future time.
Set unlockTime = current time + delay.
Only allow execution if current time >= unlockTime.
Prevents immediate execution, adds security delay.
Common in blockchain governance and contracts.

Full Transcript

The Timelock pattern is a way to delay an action in a blockchain contract until a certain time has passed. First, when an action is requested, the contract sets a future unlockTime by adding a delay (like 1 day) to the current block timestamp. Then, when trying to execute the action, the contract checks if the current time is at or past the unlockTime. If not, the action is blocked. This ensures a waiting period before the action runs, adding security and transparency. The example code sets unlockTime in requestAction and requires the current time to be greater or equal in executeAction. The execution table shows that calling executeAction too early fails, but succeeds once the unlockTime is reached or passed. Variables like unlockTime stay fixed until reset. This pattern is useful to prevent sudden changes or actions in blockchain systems.

Practice

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