I would like to address a few inefficient points in the Sovryn protocol:
-Margin trading SOV rewards (ongoing for almost 2 years, noone knows or talks about it).
-Reduced BTC/XUSD AMM pool rewards, but it’s still used as the primary pool for margin trading.
-XUSD vs DLLR lending
-XUSD vs DLLR margin trading.
Margin trading has been subsidized with SOV rewards for a very long time. Hardly anyone talks about it, no one knows. Such rewards can make sense, if they are communicated well, if they are presented and advertised accordingly in the dapp, and if they are used. Hardly any of this is the case.
Furthermore, we have (rightly) scaled back the SOV rewards for the BTC/XUSD pool. The current strategy is all about DLLR. Nevertheless, the XUSD pool is used for lending and margin trading. The adjustments of the SOV rewards and the control of liquidity only make sense if DLLR is used consistently in the other parts of the protocol, namely lending pool and margin trading. Currently, we have increased slippage and costs in margin trading due to the reduced liquidity in the XUSD pool. At the same time, we have quite high margin trading interest rates due to the split lending pools.
The DLLR pool currently promises 0.4% apy with a liquidity of about 100k USD.
The XUSD pool promises 10% apy at just under 700k USD liquidity. The open margin trading positions might play a role here. DLLR could be used here instead of XUSD. This would create DLLR demand, exactly what is so urgently needed.
My suggestion:
Let’s use the great liquidity from the BTC/DLLR AMM pool for reduced slippage on margin trading. Let’s set up a BTC/DLLR margin trading pair on the front end and promote trading in this pair with (the already existing) SOV rewards. Let’s present and communicate this accordingly. Let’s boost trading on the dapp. This will create very strong demand for the DLLR lending pool (instead of the XUSD pool) with a DLLR APY that is second to none. The demand for DLLR will increase, the peg will hold better, the protocol would benefit.
This makes total sense. The focus on the DLLR needs to be consistent across the protocol, need to make sure that the DLLR pool is used for lending and margin trading as well, instead of XUSD.
There are separate issues here - that need to be addressed separately.
The XUSD pool is splitting dollar liquidity. Ideally, we would migrate and merge XUSD into DLLR. A first step to doing this would be for Babelfish to swap out ZUSD for DLLR - depositing their ZUSD into Mynt.
The next step is more complicated, and it is the transfer of the margin positions held with XUSD to DLLR. This would allow for XUSD pool to be wound down.
Margin trading is a different issue. Here the issue is slippage. The constant product curve AMM - which is the basis for all AMMs, means high slippage. The only way to correct for this is extremely deep liquidity. There is no know solution to this using an AMM.
This is ok for regular swaps - but is very often problematic for Margin trades. Those are larger and more sensitive to slippage.
To reduce slippage significantly, we need trading that is not AMM based. We are currently looking into a number of alternatives.
The other issue with Margin Trading is the need for a much more complex UI and additional order types. This is a significant development overhead. It makes sense to undertake this overhead after we have have taken care of the rest of the UI migration, and only if we have a viable solution for slippage.
But can we at least get the normal trading over to .app soon? even if margin trading takes a long time. I really don’t like to trade “!in the dark” with the swap tool at all. I really need a chart next to me have limit orders etc. and I am sure I am not alone.
To reduce slippage significantly, we need trading that is not AMM based. We are currently looking into a number of alternatives
Yago, could you elaborate on some of these alternatives? AFAIK the main obstacle is RSK scalability and throughput, regardless of model used.
Dont mean to dismiss ideas simply being explored, but without raising the glass ceiling, whether by roll ups, or any other network-level means, what really can be done to optimise the trading app? - Or put differently, wont a change of model from AMM to any other alternative just end up meeting the same glass ceiling and, whether optimised for slippage or not, ultimately be unable to bring meaningful traction to the margin trading app until the scalability for that traction is achievable, again at the network level?
Ultimately we will indeed need an orderbook and that means greater throughput. However, there is a large potential design space which can provide better trading even without that. One option being looked into is Request for Quote - similar to what 0X and Airswap are doing. A similar method is Cowswap, which creates an off-chain orderbook.
Thanks. Happy to hear there are some optimisations that can be made with just what we have today. At a glance both protocols seem very interesting especially Request for Quote. Would love to hear more about that
