Time-Based Condition

Documentation for the TimeBasedCondition contract, a simple example condition contract that allows custom unlock logic based on timestamps.

Contract Address

  • Monad Testnet: 0x3F400BaE5037474C3b8531CC61Cd177589093C9f

Overview

The TimeBasedCondition contract demonstrates how custom unlock conditions can be implemented. It allows an admin to set specific unlock timestamps for individual locks, providing more granular control than the standard time-based unlocking in the locker contracts.

Key Features

  • Admin-controlled unlock timestamps

  • Per-lock granular control

  • Safe fallback behavior

  • Simple example for custom conditions

ILockCondition Interface

All condition contracts must implement the ILockCondition interface:

interface ILockCondition {
    /**
     * @dev Checks if a lock should be unlocked
     * @param locker Address of the locker contract
     * @param lockId ID of the lock to check
     * @return bool True if the lock can be unlocked
     */
    function isUnlocked(
        address locker,
        uint256 lockId
    ) external view returns (bool);
}

Functions

setUnlockTimestamp

Sets the unlock timestamp for a specific lock (admin only).

Parameters:

  • locker: Address of the locker contract (V2 or V3)

  • lockId: ID of the lock

  • unlockTimestamp: Unix timestamp when the lock should be unlocked

Requirements:

  • Only callable by admin (deployer)

  • Unlock timestamp must be in the future

Example:


isUnlocked

Checks if a lock should be unlocked based on the condition (view function).

Parameters:

  • locker: Address of the locker contract

  • lockId: ID of the lock to check

Returns:

  • true if current timestamp >= unlock timestamp

  • false otherwise (or if no timestamp set)

Example:


unlockTimestamps

Public mapping of unlock timestamps (view function).

Usage:


admin

Returns the admin address (immutable).


Usage Examples

Creating a Lock with Time Condition

Checking Unlock Status


Integration Example

Complete Workflow


Creating Custom Conditions

You can create your own condition contracts by implementing ILockCondition. Here are some examples:

Example 1: Price-Based Unlock

Example 2: Governance Vote Condition

Example 3: Multi-Signature Condition


Best Practices

For Condition Developers

  1. Fail Safely: If your condition reverts, the locker will fall back to time-based unlock

  2. Gas Efficiency: Keep isUnlocked() view function gas-efficient

  3. State Changes: Only modify state in setter functions, not in isUnlocked()

  4. Access Control: Implement proper access control for setter functions

  5. Testing: Thoroughly test all edge cases

For Users

  1. Verify Condition: Always verify the condition contract before using it

  2. Understand Logic: Make sure you understand how the condition works

  3. Fallback: Remember that time-based unlock still applies if condition fails

  4. Admin Trust: Be aware of who controls the condition contract

  5. Use Known Conditions: Prefer using well-tested, verified condition contracts


Security Considerations

Risks

  1. Malicious Conditions: A malicious condition could prevent unlocking

  2. Admin Control: Condition admin has significant power

  3. Condition Bugs: Bugs in condition logic could lock funds

  4. Gas Griefing: Expensive condition checks could make unlocking costly

Mitigations

Try/Catch Protection: Locker contracts wrap condition calls in try/catch blocks

Time-Based Fallback: Standard unlock time still applies

Optional Usage: Conditions are completely optional


Error Reference


Events

The TimeBasedCondition contract does not emit custom events, but you can add them in your own condition contracts:


Gas Estimates

Function
Gas Cost

setUnlockTimestamp()

~45,000

isUnlocked() (view)

~5,000


Last updated