SIP-347: Collateral Delegation Cooldown
Author | |
---|---|
Status | Rejected |
Type | Governance |
Network | Ethereum, Optimism & Base |
Implementor | TBD |
Release | TBD |
Created | 2023-10-25 |
Simple Summary
This SIP proposes the implementation of a cooldown mechanism for accounts wishing to exit or decrease their delegated collateral in a given market. It introduces a configurable cooldown duration (cooldownDuration
), that a user must await after signaling his intent to decrease his delegated liquidity to a given market. The undelegation action can only be executed when the block time is within a configurable cooldown window cooldownWindow
(after the cooldownDuration
lapses). Failure to execute the action within the window, results in the expiration of the intent, requiring users to run a new intent of undelegation.
An account who signaled his intent to decrease his delegation on a given market cannot increase his delegated liquidity to that market during the cooldownDuration
period. However, the account can signal multiple decreases of staked collateral on different markets simultaneously. Once a user signals his intention to reduce his delegated collateral on a specific market, he cannot schedule another reduction on that same market until the previous intent is executed or is expired.
In case a users' collateral is liquidated, all the accounts' cooldown intents are revoked.
The cooldownDuration
and cooldownWindow
are both configurable per market. Markets that do not require this intent/execute pattern can have this feature disabled by setting cooldownDuration
to zero.
Note that a user can signal an intent, but cannot execute that intent, if the minDelegateTime
specified in SIP-320 had not lapsed.
Motivation
In Perp V3, differences in the liquidation speeds of margin and positions could lead to deterministic profit/loss impacts. To ensure fair compensation for liquidity providers and prevent taking advantage of these determinisms, a cooldown period is proposed when undelegating liquidity from a market.
Rationale
This functionality aims to introduce friction in removing or decreasing a user's delegated collateral to discourage taking advantage of deterministic changes in profit/loss impact from liquidations.
Technical Specification
cooldownDuration
: A configurable duration in seconds, representing the minimum time before an intent can be executed.setCooldownDuration(int128)
: An addition to theIMarketManager
interface, allowing markets to associate a cooldown duration.cooldownWindow
: A configurable duration in seconds, determining the maximum time an intent can be executed after thecooldownDuration
lapses.setCooldownWindow(int128)
: An addition to theIMarketManager
interface, enabling markets to associate a cooldown window.
Test Cases
- Setting the
cooldownDuration
to 12 hours,cooldownWindow
to 6 hours- When a random account, with delegated liquidity to the perp super market attempts to signal an intent to undelegate his liquidity
- ✅ Then the transaction succeeds
- After the
cooloffDuration
andminDelegateTime
lapse- the user attempts to execute the intent in the
cooldownWindow
- ✅ Then the transaction succeeds and the users' delegated liquidity is reduced
- the user attempts to execute the intent after the
cooldownWindow
lapses- ❌ Then transaction reverts, as the
cooldown
intent had expired
- ❌ Then transaction reverts, as the
- the user attempts to execute the intent in the
- Before the
cooloffDuration
lapses- the user attempts to execute the intent
- ❌ Then transaction reverts, as the
cooloffDuration
had not lapsed
- ❌ Then transaction reverts, as the
- the user attempts to execute the intent
- The user attempts to delegate more collateral to the perp supermarket
- ❌ Then transaction reverts, due to a cooldown intent being signalled by the user
- The user attempts to undelegate more collateral from the perp supermarket
- ❌ Then transaction reverts, due to a cooldown intent already being signalled by the user
- The user gets liquidated before the
minDelegateTime
andcooloffDuration
has lapsed- ✅ Then the transaction succeeds and the
cooloff
intent is revoked
- ✅ Then the transaction succeeds and the
- After the
cooloffDuration
lapse but before theminDelegateTime
has lapsed- the user attempts to execute the intent in the
cooldownWindow
- ❌ Then transaction reverts, due to the
minDelegateTime
not having lapsed
- ❌ Then transaction reverts, due to the
- the user attempts to execute the intent in the
- After the
- ✅ Then the transaction succeeds
- When a random account, with delegated liquidity to the perp super market attempts to signal an intent to undelegate his liquidity
Configurable Values (Via SCCP)
Please refer to technical specification for definitions of the below configurable values:
cooldownDuration
cooldownWindow
Status changed to rejected, as per the authors' request.
Copyright
Copyright and related rights waived via CC0.