Conditional Unlocks

Advanced guide to implementing and using conditional unlock mechanisms in RealSafe.

Overview

Conditional unlocks allow you to create custom logic for when positions can be unlocked, beyond simple time-based locks. This opens up powerful use cases for DeFi protocols, DAOs, and advanced liquidity management strategies.

Table of Contents


Understanding Conditions

What is a Condition?

A condition is a smart contract that implements the ILockCondition interface:

When a lock has a condition set:

  1. Time Check: Standard unlock time is checked first

  2. Condition Check: If time hasn't passed, condition is checked

  3. Either/Or: Lock can be unlocked if EITHER condition is true

How Conditions Are Used

Key Benefits

  • Flexibility: Unlock based on any on-chain logic

  • Composability: Combine multiple conditions

  • Safety: Falls back to time-based if condition fails

  • Transparency: All logic is on-chain and verifiable


Built-in Conditions

TimeBasedCondition

Simple admin-controlled unlock timestamps.

Deployment Addresses:

  • Monad Testnet: 0x3F400BaE5037474C3b8531CC61Cd177589093C9f

  • Monad Testnet: 0x3F400BaE5037474C3b8531CC61Cd177589093C9f

Use Case: Admin wants fine-grained control over individual lock unlock times.


Custom Condition Examples

1. Price-Based Unlock

Unlock when an asset reaches a target price.

Usage:


2. TVL-Based Unlock

Unlock when protocol TVL reaches a threshold.


3. Multi-Signature Unlock

Require multiple signatures to unlock.

Usage:


4. Governance Vote Condition

Unlock based on DAO vote outcome.


5. Milestone-Based Unlock

Unlock when project milestones are achieved.


Advanced Patterns

Composite Conditions

Combine multiple conditions with AND/OR logic.


Security Considerations

Risks

  1. Malicious Conditions: Could permanently lock funds

  2. Admin Control: Centralization risk

  3. Gas Griefing: Expensive condition checks

  4. Oracle Manipulation: Price/data manipulation

  5. Reentrancy: If condition calls external contracts

Mitigations

  • Try/Catch Wrapper: Locker wraps condition calls

  • Time-Based Fallback: Standard unlock always available

  • View Functions Only: isUnlocked() should be view

  • Gas Limits: Keep checks simple

  • Audited Conditions: Use verified contracts only


Best Practices

For Condition Developers

  1. Keep isUnlocked() simple and gas-efficient

  2. Use view modifier (no state changes in unlock check)

  3. Handle edge cases gracefully

  4. Implement proper access control

  5. Add comprehensive events

  6. Document all functions

  7. Test thoroughly

For Users

  1. Verify condition contract code

  2. Understand the unlock logic

  3. Check admin addresses

  4. Test with small amounts first

  5. Use time-based fallback as safety net

  6. Monitor condition state


Testing Conditions


Last updated