In reviewing the Morpheus documentation and other writings, as well as the smart contract implementations deployed to Ethereum and Arbitrum, I noticed an inconsistency with regard to what asset MOR will trade against for Protocol-Owned Liquidity.
In some places, the TCM bootstrapping model for Morpheus has its native token MOR trade against WETH; in other places - as well as in the smart contract implementations - it seems MOR will trade against wstETH (wrapped Lido Staked Ethereum).
It would be worth establishing which of these trading pairs is to be used, as some contributors may not be aware of the current implementation.
MOR/WETH or MOR/wstETH?
I believe MOR should trade against WETH, the wrapped ERC20 representation of ETH on Arbitrum. This is the asset of choice for most trading pairs on Arbitrum (see DEXScreener) as users can swap between ETH (the gas token on Arbitrum) and WETH by wrapping/unwrapping without having to worry about slippage. Additionally, since other assets are denominated in WETH, multi-part swaps (e.g. USDC->WETH->MOR) would be cheaper.
I do not see any strong reasons to pair MOR against wstETH, other than the fact the current smart contract implementation seems to support this.
It is worth nothing that there is considerable wstETH/WETH liquidity on Arbitrum, across both Uniswap (~$9.5m liquidity) and Balancer (~15m liquidity) so it would be possible for users to route MOR swaps either way.
Resolution(s)
If the Morpheus community confirms that MOR/wstETH is the preferred trading pair, then it would be enough to update and make consistent the Morpheus documentation and other writings (such as MRC 09: AMM Launch Process) to reflect this.
If MOR/WETH is the preferred pair, I believe modifications would need to be made to the smart contract implementation to enable this.
EDIT: I had assumed there would not be sufficient liquidity to swap wstETH for WETH on Arbitrum, and that it would be necessary to do so on mainnet (see below). However, it appears there is enough liquidity. Nevertheless, the L2TokenReceiver contract responsible for managing PoL does not seem optimized for these swaps. It could be worth adding a dedicated method for wstETH to WETH swaps and adding Balancer support.
For instance, a new function could be added to Distribution that would allow stETH yield to be converted into WETH when called by the Morpheus multisig. In course, the bridgeOverplus function would be modified to bridge WETH to Arbitrum.
To convert stETH into WETH, two methods could be used:
Swap via DEX
Unwrap via Lido
While swapping is near instant, it may result in slippage. As a result, it may be best to unwrap stETH directly via Lido, which takes 1-5 days. Although this seems like an inconvenience, it could be made part of a weekly signing schedule:
Claim stETH yield in Distribution
Begin unstaking stETH yield via Lido
Complete unstaking of last week's stETH yield (call claimWithdrawal)
Bridge received WETH to Arbitrum
Since the Distribution contract uses an upgradeability proxy pattern, and Capital is held in the Delegator contract, it should be possible to update the implementation contract and thus introduce these features without requiring Capital Providers to migrate.
tster
commented
5 months ago
In reviewing the Morpheus documentation and other writings, as well as the smart contract implementations deployed to Ethereum and Arbitrum, I noticed an inconsistency with regard to what asset MOR will trade against for Protocol-Owned Liquidity.
In some places, the TCM bootstrapping model for Morpheus has its native token MOR trade against WETH; in other places - as well as in the smart contract implementations - it seems MOR will trade against wstETH (wrapped Lido Staked Ethereum).
It would be worth establishing which of these trading pairs is to be used, as some contributors may not be aware of the current implementation.
MOR/WETH or MOR/wstETH?
I believe MOR should trade against WETH, the wrapped ERC20 representation of ETH on Arbitrum. This is the asset of choice for most trading pairs on Arbitrum (see DEXScreener) as users can swap between ETH (the gas token on Arbitrum) and WETH by wrapping/unwrapping without having to worry about slippage. Additionally, since other assets are denominated in WETH, multi-part swaps (e.g. USDC->WETH->MOR) would be cheaper.
I do not see any strong reasons to pair MOR against wstETH, other than the fact the current smart contract implementation seems to support this.
It is worth nothing that there is considerable wstETH/WETH liquidity on Arbitrum, across both Uniswap (~$9.5m liquidity) and Balancer (~15m liquidity) so it would be possible for users to route MOR swaps either way.
Resolution(s)
If the Morpheus community confirms that MOR/wstETH is the preferred trading pair, then it would be enough to update and make consistent the Morpheus documentation and other writings (such as MRC 09: AMM Launch Process) to reflect this.
If MOR/WETH is the preferred pair, I believe modifications would need to be made to the smart contract implementation to enable this.
EDIT: I had assumed there would not be sufficient liquidity to swap wstETH for WETH on Arbitrum, and that it would be necessary to do so on mainnet (see below). However, it appears there is enough liquidity. Nevertheless, the
L2TokenReceivercontract responsible for managing PoL does not seem optimized for these swaps. It could be worth adding a dedicated method for wstETH to WETH swaps and adding Balancer support.For instance, a new function could be added to
Distributionthat would allow stETH yield to be converted into WETH when called by the Morpheus multisig. In course, thebridgeOverplusfunction would be modified to bridge WETH to Arbitrum.To convert stETH into WETH, two methods could be used:
While swapping is near instant, it may result in slippage. As a result, it may be best to unwrap stETH directly via Lido, which takes 1-5 days. Although this seems like an inconvenience, it could be made part of a weekly signing schedule:
DistributionclaimWithdrawal)Since the Distribution contract uses an upgradeability proxy pattern, and Capital is held in the Delegator contract, it should be possible to update the implementation contract and thus introduce these features without requiring Capital Providers to migrate.