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:
Time Check: Standard unlock time is checked first
Condition Check: If time hasn't passed, condition is checked
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:
0x3F400BaE5037474C3b8531CC61Cd177589093C9fMonad 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
Malicious Conditions: Could permanently lock funds
Admin Control: Centralization risk
Gas Griefing: Expensive condition checks
Oracle Manipulation: Price/data manipulation
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 viewGas Limits: Keep checks simple
Audited Conditions: Use verified contracts only
Best Practices
For Condition Developers
Keep
isUnlocked()simple and gas-efficientUse
viewmodifier (no state changes in unlock check)Handle edge cases gracefully
Implement proper access control
Add comprehensive events
Document all functions
Test thoroughly
For Users
Verify condition contract code
Understand the unlock logic
Check admin addresses
Test with small amounts first
Use time-based fallback as safety net
Monitor condition state
Testing Conditions
Related Documentation
Last updated
