Overview
FHERC20 introduces a new permission model called operators that replaces the traditional ERC20 allowance system. Instead of approving specific amounts (which would leak information about balances), FHERC20 uses time-based operator permissions that grant full access until an expiration timestamp.Privacy Preserving
No amount-specific approvals means no information leakage about how much you’re willing to let others spend.
Time-Based Expiration
Operators have automatic expiration using Unix timestamps, reducing the need for explicit revocation.
Full Access
Operators can move any amount of tokens (up to your balance) without needing separate approvals for each transaction.
Simple Management
One function to grant, extend, or revoke operator permissions with intuitive timestamp-based control.
Why Operators Instead of Allowances?
The Problem with Traditional Allowances
Standard ERC20 uses theapprove() function to grant spending permissions:
- ❌ Reveals how much you’re willing to let someone spend
- ❌ Requires updating allowances frequently
- ❌ Can leak information about your balance
- ❌ Doesn’t work well with encrypted amounts
The Operator Solution
FHERC20 operators grant permission without revealing amounts:- ✅ No amount information revealed
- ✅ Time-based expiration is automatic
- ✅ Simple on/off permission model
- ✅ Works perfectly with encrypted values
Setting Operators
Function Signature
operator: Address to grant operator permissions tountil: Unix timestamp when the permission expires (uint48 supports dates until year 8921556)
Basic Usage
Checking Operator Status
Function Signature
holder: Address of the token holderspender: Address to check operator status for
trueifspenderis currently an authorized operator forholderfalseif not authorized or permission has expired
Usage Examples
Using Operator Permissions
Once granted operator status, an address can useconfidentialTransferFrom() to move tokens:
Complete Example
Internal Implementation
Storage
Operators are stored in a mapping with their expiration times:Setting an Operator
Checking Operator Status
Transfer From Check
Before allowing aconfidentialTransferFrom, the contract verifies operator status:
Operator Patterns
Pattern 1: Short-Lived Permissions
Grant operator permissions for specific transactions:Operator vs Allowance Comparison
| Feature | ERC20 Allowance | FHERC20 Operator |
|---|---|---|
| Privacy | ❌ Reveals approved amount | ✅ No amount revealed |
| Expiration | ⚠️ Manual revocation required | ✅ Automatic time-based |
| Flexibility | ✅ Can approve specific amounts | ⚠️ All-or-nothing access |
| Gas Efficiency | ⚠️ Multiple approvals costly | ✅ Single approval sufficient |
| Complexity | ✅ Simple amount-based | ✅ Simple time-based |
| Use with FHE | ❌ Doesn’t work with encryption | ✅ Designed for FHE |
Security Considerations
Operator Has Full Access
Operator Has Full Access
- Use short expiration times when possible
- Only authorize trusted contracts or addresses
- Monitor operator grants in your UI
- Consider implementing additional checks in contracts
Time-Based Expiration
Time-Based Expiration
Operator permissions automatically expire based on blockchain timestamp:Advantages:
- Automatic cleanup
- No gas cost for revocation
- Predictable expiration
- Block timestamps can vary slightly
- Account for clock skew in time calculations
- Use buffer time for critical operations
Front-Running Protection
Front-Running Protection
Operator changes are atomic and immediate:Unlike ERC20’s approve/transferFrom race condition, operator changes are safe from front-running because:
- No amount is specified
- Permission is binary (yes/no)
- Time-based expiration is deterministic
Multiple Operators
Multiple Operators
A holder can have multiple operators simultaneously:Consider:
- Each operator has full access
- Permissions are independent
- Track all active operators
- Implement operator limits if needed
Related Topics
- Learn about FHERC20 Permit for signature-based operator approval
- Explore Transfer Callbacks for safe operator transfers
- Review Best Practices for secure operator management