SIP-153: LINK Wrappr

Simple Summary

NOTE: This SIP has been moved to rejected as there is a planned SIP to create a generic implementation of a wrapperfactory to support any wrapped assets.

Allow users to wrap LINK to mint sLINK

Abstract

This SIP proposes to deploy a new wrappr as per SIP-112 (ETHwrappr) that will accept deposits of LINK and mint sLINK.

Motivation

The Curve LINK/sLINK pool has deep liquidity but sLINK remains unbalanced in the pool causing sLINK to trade above par against LINK. sLink has been a top three Synth by open interest for most of this year so there is a significant positive skew that can be offset through the introduction of a LINKwrappr.

Specification

Overview

sLINK is minted whenever a user deposits LINK into the contract. The user can deposit any amount, however, this is subject to not exceeding the maxLINK configurable via SCCP. There is no duration, interest rate or collateralization ratio, as any user can at any time buy back LINK available in the contract by burning sLINK. Minters benefit as minting sLINK and burning sLINK are subject to a mintingFeeRate and burningFeeRate, both of which are paid to the fee pool after conversion into sUSD.

Rationale

Adding additional wrappr contracts to support new assets will help expand the total Synth supply, LINK is one of the most liquid ERC-20 tokens and is therefore a good wrappr candidate.

Technical Specification

Contracts

Two contracts are required to be deployed:

• LINKWrapper.sol which is able to mint sLINK against LINK deposited and release LIK against sLINK burned.

Interfaces

The entry points for users on LINKWrapper.sol implements the following interface.

interface LINKWrapper.sol {
    function mint(uint amount) external;
    function burn(uint amount) external;
}

Key Bounds

• The upper bound on the amount of Minting is determined with a helper function, capacity, defined by max(maxLINK, 0) with LINK being the amount locked in the contract. In case the user attempts to mint an amount greater than the upper bound, then capacity is minted and the residual is returned to the user (please refer to test cases for calculation specs).

• The upper bound on the amount of Burning is computed as LINK locked in the contract multiplied (1+burnFeeRate) (please refer to test cases for calculation specs).

• mintFeeRate and burnFeeRate are both bounded between 0% and 100%, inclusive.

Test Cases

• Given that a user has u amount of LINK and the contract has c amount of LINK in spare capacity
  • Given that u is larger than or equal to c
    • When the user attempts to deposit u LINK into the contract
      • ✅ Then it succeeds and the following take place:
      • c LINK is locked up in the contract
      • c(1-mintFeeRate) is minted into the user's wallet in sLINK
        • c*mintFeeRate worth of sLINK is sent to the fee pool in the form of sUSD
        • u - c worth of LINK is refunded back to the user
  • Given that u is strictly lower than c
    • When the user attempts to deposit u LINK into the contract
      • ✅ Then it succeeds and the following take place:
        • u LINK is locked up in the contract
        • u(1-mintFeeRate) is minted into the user's wallet in sLINK
        • u*mintFeeRate worth of sLINK is sent to the fee pool in the form of sUSD
• Given that the contract's capacity is zero, as maxLINK is locked in the contract
  • When the user attempts deposit LINK into the contract
    • ❌ Then the transaction reverts due to max capacity being reached
• Given that a user has u amount of sLINK and the contract holds c amount of LINK
  • Given that u is larger than or equal to c(1+burnFeeRate)
    • When the user attempts to draw out LINK from the contract by burning u sLINK and flagging withdrawal in LINK
      • ✅ Then it succeeds and the following take place:
        • c LINK is sent to the user
        • c sLINK is burned
        • c * burnFeeRate worth of sLINK is swapped to sUSD and sent to the fee pool
        • u - c(1+burnFeeRate) worth of sLINK is refunded back to the user
  • Given that u is strictly lower than c(1+burnFeeRate)
    • When the user attempts to draw out LINK from the contract by burning u sLINK and flagging withdrawal in LINK
      • ✅ Then it succeeds and the following take place:
        • u (1-burnFeeRate) worth of LINK is sent to the user
        • u * burnFeeRate worth of sLINK is swapped to sUSD and sent to the fee pool
        • u (1 - burnFeeRate) sLINK is burned
• Given that the contract's holds no LINK
  • When the user attempts draw out LINK from the contract
    • ❌ Then the transaction reverts due to the contract being out of LINK

Configurable Values (Via SCCP)

For the wrappr contract, the following values must be set:

• maxLINK the maximum amount of LINK held by contract.
• mintFeeRate the fee for depositing LINK into the contract.
• burnFeeRate the fee for burning sLINK and releasing LINK from the contract

It is expected that arbitrage will be capturd via flashbots once this new contract is deployed, therefore, to maximise the fees to stakers the following process is proposed for the deployment. Post deployment stage multiple pDAO transactions to progressively decrease fees and increase the cap in the following increments:

• maxLINK 0 - 2.5m LINK in 250k increments
• mintFeeRate 75bp - 25bp in 5bp increments
• burnFeeRate 5bp

Copyright

Copyright and related rights waived via CC0.