SIP-366: Asyncronous Delegation
Author | |
---|---|
Status | Approved |
Type | Governance |
Network | Ethereum, Optimism & Base |
Implementor | TBD |
Release | TBD |
Proposal | Loading status... |
Created | 2024-03-04 |
Simple Summary
This SIP proposes adding functionality such that markets can require liquidity providers to first request a change in their delegation of collateral and the process it after a configurable delay.
Abstract
As an improvement over the Minimum Collateral Delegation Duration (per SIP-320), this SIP proposes to replace the concept of a minimum delegation time with a pattern in which liquidity providers call a requestDelegateCollateral
function, wait a delegateCollateralDelay
or undelegateCollateralDelay
(depending on whether their delegated collateral is increasing or decreasing), and then have anyone call a processDelegateCollateral
function within a delegateCollateralWindow
or undelegateCollateralWindow
to apply the change.
Motivation
This functionality allows markets to prevent adversial dynamics between liquidity providers. For example, if a liquidity provider is able to anticipate a large increase or decrease of debt to a pool—without this feature enabled—they could quickly exit or enter the pool such that other liquidity providers assume the change. This is a effectively a concern of "just-in-time liquidity".
Note that this functionality would be implemented in addition to the Core System Precautionary Security Features (per SIP-316).
Rationale
It would be possible to have governance or pool owners configure these values—rather than having market builders decide on the configuration—but this would complicate liquidity provisioning for all integrators, as this makes delegation non-atomic. Further, because the opportunities of adversarial liquidity provisioning are specific to a market's implementations, it makes sense to configure these values in this way.
Technical Specification
- Replace
setMarketMinDelegateTime
andminDelegationTime
with relevant getter and setter methods forunit256 undelegateCollateralDelay
,unit256 undelegateCollateralWindow
,unit256 delegateCollateralDelay
, andunit256 delegateCollateralWindow
. requestDelegateCollateral(uint128 accountId,uint128 poolId,address collateralType,uint256 newCollateralAmountD18,uint256 leverage)
should be added to theVaultModule
. This should perform similar checks asdelegateCollateral
, but store the request (along with theblock.timestamp
) to a mapping in theVault
storage library.processDelegateCollateral(uint128 accountId,uint128 poolId,address collateralType)
should be added to theVaultModule
. This should confirm that the collateralization ratio of the position will not drop below the issuance ratio if the delegation change is processed. It can be called permissionlessly, such that anyone can process an open request. It should confirm that a corresponding request exists in storage, that the stored timestamp is greater than the current timestamp plusdelegateCollateralDelay
orundelegateCollateralDelay
, and less than the current time plus the relevant delay value and the relevant window value.delegateCollateral
can callrequestDelegateCollateral
orprocessDelegateCollateral
as appropriate if collateral is being reduced anddelegateDelay
orundelegateDelay
is set.
Test Cases
Relevant tests will be developed during implementation.
Configurable Values (Via SCCP)
N/A
Copyright
Copyright and related rights waived via CC0.