Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/reserve-protocol/reserve-index-dtf/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

The UnstakingManager contract handles time-delayed withdrawals from StakingVaults. When a user withdraws from a vault with an unstaking delay, their tokens are held in this contract until the unlock time, after which they can be claimed.

​
Key Features

  • Time-Locked Withdrawals: Holds tokens until unlock time
  • Cancel Option: Users can cancel and re-stake before unlock
  • Simple Lock Management: Each withdrawal creates a numbered lock
  • Immutable Configuration: Tied to specific vault and token

​
Lock Structure

​
user
address
Address that owns the lock
​
amount
uint256
Amount of tokens locked
​
unlockTime
uint256
Timestamp when lock becomes claimable
​
claimedAt
uint256
Timestamp when lock was claimed (0 if unclaimed)

​
Functions

​
Create Lock

Create a new time-locked withdrawal (called only by vault).
​
user
address
Address that will own the lock
​
amount
uint256
Amount of tokens to lock
​
unlockTime
uint256
Timestamp when tokens become claimable
UnstakingManager.sol
function createLock(
    address user,
    uint256 amount,
    uint256 unlockTime
) external
Only the associated StakingVault can call this function. It’s automatically called during vault withdrawals.

​
Claim Lock

Claim tokens from an unlocked withdrawal.
​
lockId
uint256
ID of the lock to claim
UnstakingManager.sol
function claimLock(uint256 lockId) external
Anyone can call this function, but tokens are always sent to the lock’s original owner. The lock must be past its unlock time and not already claimed.

​
Cancel Lock

Cancel a lock and re-stake the tokens back into the vault.
​
lockId
uint256
ID of the lock to cancel
UnstakingManager.sol
function cancelLock(uint256 lockId) external
This deposits the locked tokens back into the vault on behalf of the user. This is useful if the user changes their mind about unstaking or wants to avoid the waiting period.

​
View Functions

​
Get Lock Details

Retrieve information about a specific lock.
UnstakingManager.sol
function locks(uint256 lockId) external view returns (
    address user,
    uint256 amount,
    uint256 unlockTime,
    uint256 claimedAt
)

​
Target Token

Get the token being managed.
UnstakingManager.sol
function targetToken() external view returns (IERC20)

​
Vault

Get the associated StakingVault.
UnstakingManager.sol
function vault() external view returns (IERC4626)

​
Events

​
LockCreated
event
Emitted when a new lock is createdParameters:
  • lockId - Unique identifier for the lock
  • user - Address that owns the lock
  • amount - Amount of tokens locked
  • unlockTime - Timestamp when claimable
​
LockCancelled
event
Emitted when a lock is cancelled and tokens are re-stakedParameters:
  • lockId - ID of the cancelled lock
​
LockClaimed
event
Emitted when a lock is claimedParameters:
  • lockId - ID of the claimed lock

​
Errors

​
UnstakingManager__Unauthorized
error
Thrown when caller is not authorized for the operation
​
UnstakingManager__NotUnlockedYet
error
Thrown when trying to claim before unlock time
​
UnstakingManager__AlreadyClaimed
error
Thrown when trying to claim or cancel an already-claimed lock

​
Usage Flow

​
Standard Unstaking

// 1. User withdraws from vault (creates lock)
vault.withdraw(1000e18, receiver, owner);
// Lock created with ID = 0

// 2. Wait for unlock time
// ...

// 3. Claim tokens
unstakingManager.claimLock(0);
// Tokens sent to user

​
Cancel and Re-stake

// 1. User withdraws from vault
vault.withdraw(1000e18, receiver, owner);
// Lock created with ID = 0

// 2. User changes mind before unlock time
unstakingManager.cancelLock(0);
// Tokens deposited back into vault
// Lock deleted

​
Security Considerations

The UnstakingManager is automatically deployed by the StakingVault during initialization. The vault address is immutable and set in the constructor.
Locks cannot be transferred or traded. They are permanently tied to the original user address.

​
Lock ID Sequence

​
nextLockId
uint256
Counter that increments for each new lock, starting at 0
Lock IDs are sequential starting from 0 and increment with each new lock creation. Once a lock is claimed or cancelled, its ID is not reused.

Build docs developers (and LLMs) love

Get started for freeTalk to us