SIP-366: Asyncronous Delegation

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 and minDelegationTime with relevant getter and setter methods for unit256 undelegateCollateralDelay, unit256 undelegateCollateralWindow, unit256 delegateCollateralDelay, and unit256 delegateCollateralWindow.
• requestDelegateCollateral(uint128 accountId,uint128 poolId,address collateralType,uint256 newCollateralAmountD18,uint256 leverage) should be added to the VaultModule. This should perform similar checks as delegateCollateral, but store the request (along with the block.timestamp) to a mapping in the Vault storage library.
• processDelegateCollateral(uint128 accountId,uint128 poolId,address collateralType) should be added to the VaultModule. 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 plus delegateCollateralDelay or undelegateCollateralDelay, and less than the current time plus the relevant delay value and the relevant window value.
• delegateCollateral can call requestDelegateCollateral or processDelegateCollateral as appropriate if collateral is being reduced and delegateDelay or undelegateDelay 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.