Timelock pattern in Blockchain / Solidity - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to declare a public variable named 'delay' of type uint.

Blockchain / Solidity

uint public [1];

Drag options to blanks, or click blank then click option'

Alock

Btime

Cdelay

Dduration

Attempts:

3 left

💡 Hint

Common Mistakes

Using a variable name that does not describe the delay.

Forgetting to make the variable public.

The variable delay holds the time delay for the timelock. It must be declared as public and of type uint.

2fill in blank

medium

Complete the function signature to set a new admin address.

Blockchain / Solidity

function [1](address newAdmin) external onlyAdmin { admin = newAdmin; }

Drag options to blanks, or click blank then click option'

AupdateAdmin

BsetAdmin

CchangeAdmin

DmodifyAdmin

Attempts:

3 left

💡 Hint

Common Mistakes

Using a function name that is too vague or uncommon.

Not using a verb that clearly indicates setting a value.

The function to set a new admin is commonly named setAdmin to clearly indicate its purpose.

3fill in blank

hard

Fix the error in the require statement to check if the current time is past the unlock time.

Blockchain / Solidity

require(block.timestamp [1] unlockTime, "Timelock not expired");

Drag options to blanks, or click blank then click option'

A==

B<

C<=

D>=

Attempts:

3 left

💡 Hint

Common Mistakes

Using '<' instead of '>=' causing premature execution.

Using '==' which is too strict and may block valid calls.

The require statement should check if the current time is greater than or equal to the unlock time to allow execution after the delay.

4fill in blank

hard

Fill both blanks to create a mapping that stores queued transactions and a function to queue a transaction.

Blockchain / Solidity

mapping(bytes32 => bool) public [1];

function [2](bytes32 txHash) public onlyAdmin { queuedTransactions[txHash] = true; }

Drag options to blanks, or click blank then click option'

AqueuedTransactions

BpendingTx

CqueueTransaction

DaddTransaction

Attempts:

3 left

💡 Hint

Common Mistakes

Using inconsistent names between mapping and function.

Choosing vague names that do not describe their purpose.

The mapping is named queuedTransactions to store transaction hashes. The function to add a transaction is queueTransaction.

5fill in blank

hard

Fill all three blanks to implement the executeTransaction function with checks for queued status, timelock, and deletion after execution.

Blockchain / Solidity

function [1](bytes32 txHash) public onlyAdmin {
    require(queuedTransactions[txHash], "Transaction not queued");
    require(block.timestamp [2] unlockTime, "Timelock not expired");
    queuedTransactions[txHash] = [3];
    // execute transaction logic here
}

Drag options to blanks, or click blank then click option'

AexecuteTransaction

B>=

Cfalse

Dtrue

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect comparison operators in the require statement.

Not marking the transaction as executed (false) after running.

The function is named executeTransaction. It checks if the current time is greater than or equal to the unlock time, then sets the queued transaction to false after execution.

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