SIP-112: ETH Wrappr
Author | bojan, kaleb |
---|---|
Status | Implemented |
Type | Governance |
Implementor | TBD |
Release | TBD |
Discussions-To | https://research.synthetix.io/ |
Created | 2021-02-15 |
Simple Summary
Allow users to wrap ETH or WETH and get sETH
Abstract
We propose to deploy a new contract that accepts deposits in ETH or WETH and in return mints sETH in the user's wallet. After successful ETH or WETH deposit, users' ownership is transferred to Synthetix protocol. Wrappr is a conditionally bidirectional contract, meaning that if it holds WETH in its reserve, it will accept deposits in sETH and releases WETH or ETH back to the user. WETH or ETH can be withdrawn from the contract at any point by anyone after the corresponding amount of sETH is effectively burned.
Motivation
We are experiencing a chronic shortage of Synths which is reflected on the market where Synths are being constantly traded above their peg since mid-2020 as can be seen here on CRV. Even with the introduction of Multi-Collateral Loans in SIP-97, problems with the peg persisted. One explanation is that those loans are relatively capital inefficient since they require over-collateralization and thus are not effective tools for arbitrage and bringing synths to peg.
Specification
Overview
sETH is freshly minted whenever a user deposits ETH or WETH into the contract. The user can deposit any amount desired however, this is subject to not exceeding the maxETH
configurable via SCCP.
There is no duration, interest rate or collateralization ratio, as any user can at any time buy back WETH or ETH available in the contract by burning sETH.
Minters benefit as minting sETH and burning sETH are subject to a mintingFeeRate
and burningFeeRate
, both of which are paid to the fee pool after conversion into sUSD
.
The contract supports both ETH and WETH, and automatically handles wrapping/unwrapping ETH for the user.
Rationale
The main purpose of this proposal rests on the following points:
- Allowing ETH holders to easily enter and exit Kwenta with the least amount of friction possible. This venue is more efficient than trading ETH for synths on an AMM, due to the slippage. In addition, the current loan program bears collateralization as mentioned previously which cannot be lowered due to the collateralization and interest rate levied being undifferentiated across different borrowing options.
- The contract would release sETH during times of surging demand and absorb extra synth supply when that demand recedes. Therefore it would automatically act as a peg balancing layer that allows arbers to enter and exit with the least friction possible, helping align the different pegs. One arb example, would be to mint sETH against ETH and swap the sETH for ETH on CRV.
- The debt pool would be mostly neutral initially as the increase in sETH supply would be offset by the increase in ETH locked in the wappr contract. However, as users swap the freshly minted sETH to other synths, this would lead to a reduction in the sETH skew as ETH locked acts as a counter-weight against the long sETH position, as the total debt calculation would be reduced by the amount of ETH locked in the contract. Hence, the need to incentivize farmers to assume a short sETH positions would be decreased.
- The minting and burning fees effectively create a new revenue stream for minters who would effectively be getting a cut from the profit generated by actors arbitraging points of inefficiency.
- The pressure to fix the peg by reducing the collateralization ratio (increasing the solvency risk on minters) is somewhat reduced by having this contract at the spartan's council disposal, as another tool to help steer the peg towards parity (by changing the minting & burning fee as well as the
maxETH
parameter). - Supporting WETH makes the contract compatible with L2, specifically the Optimism OVM (OVM doesn’t support native ETH, instead contracts can use a native WETH deployment), as well as reduces interaction complexity for users coming from DeFi, where WETH is the norm.
Technical Specification
Contracts
Two contracts are required to be deployed:
EtherWrapper.sol
which is able to mintsETH
against WETH deposited and release WETH againstsETH
burned.NativeEtherWrappr.sol
which is a thin wrapper aroundEtherWrapper.sol
, that supports interacting with native ether on L1.
Interfaces
The entry points for users on IEtherWrapper.sol
implements the following interface.
interface IEtherWrapper.sol {
function mint(uint amount) external;
function burn(uint amount) external;
}
The NativeEtherWrapper
has a similar interface. The contract calls into EtherWrapper
for mint
and burn
, converting sent ETH into WETH for the mint
function, and received WETH
into ETH
for the burn
function.
interface INativeEtherWrapper {
function mint() external payable;
function burn(uint amount) external;
}
L2 Specification
NativeEtherWrapper
is not deployed for L2, as using native ETH opcodes (callvalue
, balance
) in the OVM will revert.
Key Bounds
-
The upper bound on the amount of Minting is determined with a helper function,
capacity
, defined by max(maxETH
-WETH
, 0) withWETH
being the amount locked in the contract. In case the user attempts to mint an amount greater than the upper bound, thencapacity
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
WETH
locked in the contract multiplied(1+burnFeeRate)
(please refer to test cases for calculation specs). -
mintFeeRate
andburnFeeRate
are both bounded between 0% and 100%, inclusive.
Test Cases
-
Given that a user has
u
amount of ETH andu
WETH and the contract hasc
amount of ETH in spare capacity- Given that
u
is larger than or equal toc
- When the user attempts to deposit
u
ETH into the contract- ✅ Then it succeeds and the following take place:
c
ETH is wrapped into WETH and is locked in the contractc(1-mintFeeRate)
is minted into the user's wallet in sETHc*mintFeeRate
worth of sETH is sent to the fee pool in the form of sUSDu - c
worth of ETH is refunded back to the user
- ✅ Then it succeeds and the following take place:
- When the user attempts to deposit
u
WETH into the contract- ✅ Then it succeeds and the following take place:
c
WETH is locked up in the contractc(1-mintFeeRate)
is minted into the user's wallet in sETHc*mintFeeRate
worth of sETH is sent to the fee pool in the form of sUSDu - c
worth of WETH is refunded back to the user
- When the user attempts to deposit
- Given that
u
is strictly lower thanc
- When the user attempts to deposit
u
ETH into the contract- ✅ Then it succeeds and the following take place:
u
ETH is wrapped into WETH and is locked in the contractu(1-mintFeeRate)
is minted into the user's wallet in sETHu*mintFeeRate
worth of sETH is sent to the fee pool in the form of sUSD
- ✅ Then it succeeds and the following take place:
- When the user attempts to deposit
u
WETH into the contract- ✅ Then it succeeds and the following take place:
u
WETH is locked up in the contractu(1-mintFeeRate)
is minted into the user's wallet in sETHu*mintFeeRate
worth of sETH is sent to the fee pool in the form of sUSD
- ✅ Then it succeeds and the following take place:
- When the user attempts to deposit
- Given that
-
Given that the contract's capacity is zero, as
maxETH
is locked in the contract- When the user attempts deposit ETH or WETH into the contract
- ❌ Then the transaction reverts due to max capacity being reached
- When the user attempts deposit ETH or WETH into the contract
-
Given that a user has
u
amount of sETH and the contract holdsc
amount of WETH- Given that
u
is larger than or equal toc(1+burnFeeRate)
- When the user attempts to draw out ETH from the contract by burning
u
sETH and flagging withdrawal in ETH- ✅ Then it succeeds and the following take place:
c
WETH is unwrapped to ETH and is sent to the userc
sETH is burnedc * burnFeeRate
worth of sETH is swapped to sUSD and sent to the fee poolu - c(1+burnFeeRate)
worth of sETH is refunded back to the user
- ✅ Then it succeeds and the following take place:
- When the user attempts to draw out WETH from the contract by burning
u
sETH and flagging withdrawal in WETH- ✅ Then it succeeds and the following take place:
c
WETH is sent to the userc
sETH is burnedc * burnFeeRate
worth of sETH is swapped to sUSD and sent to the fee poolu - c(1+burnFeeRate)
worth of sETH is refunded back to the user
- ✅ Then it succeeds and the following take place:
- When the user attempts to draw out ETH from the contract by burning
- Given that
u
is strictly lower thanc(1+burnFeeRate)
- When the user attempts to draw out ETH from the contract by burning
u
sETH and flagging withdrawal in ETH- ✅ Then it succeeds and the following take place:
u (1-burnFeeRate)
worth of WETH is unwrapped to ETH and is sent to the useru * burnFeeRate
worth of sETH is swapped to sUSD and sent to the fee poolu (1 - burnFeeRate)
sETH is burned
- ✅ Then it succeeds and the following take place:
- When the user attempts to draw out WETH from the contract by burning
u
sETH and flagging withdrawal in WETH- ✅ Then it succeeds and the following take place:
u (1-burnFeeRate)
worth of WETH is sent to the useru * burnFeeRate
worth of sETH is swapped to sUSD and sent to the fee poolu (1 - burnFeeRate)
sETH is burned
- ✅ Then it succeeds and the following take place:
- When the user attempts to draw out ETH from the contract by burning
- Given that
-
Given that the contract's holds no WETH
- When the user attempts draw out ETH or WETH from the contract
- ❌ Then the transaction reverts due to the contract being out of WETH
- When the user attempts draw out ETH or WETH from the contract
-
Given that a user attemps to mint with
WETH
andmsg.value
is greater than zero then the following takes place:- ❌ The transaction reverts due to the user minting with both
WETH
andETH
- ❌ The transaction reverts due to the user minting with both
Configurable Values (Via SCCP)
For the wrappr contract, the following values must be set:
maxETH
the maximum amount of ETH held by contract.mintFeeRate
the fee for depositing ETH into the contract.burnFeeRate
the fee for burning sETH and releasing ETH from the contract
Proposed Initial Values
The following values are proposed as an initial configuration:
maxETH
5,000mintFeeRate
5 bpburnFeeRate
5 bp
Copyright
Copyright and related rights waived via CC0.