Currently pools such as stLuna-Luna use the stableswap pool. This is fine at the starting when they both are pegged close to 1:1. But as time goes on the value of assets such as stLuna increases when compared to the value of assets such as Luna and they depeg away from the 1:1 ratio.
Currently stLuna is worth 1.023652 Luna but it’s actually pegged to 1 Luna. What this means is that there is an automatic 2.37% arbitrage if the pool was balanced. But since there is a 2.37% arbitrage the pool is highly unbalanced as arbitragers are constantly buying stLuna from here.
The stLuna-Luna pool currently contains only 950K stLuna for 1.17M Luna. This pool is only going to get unbalanced as time goes on because the value of stLuna will always be increasing when compared to the value of Luna.
I suggest making a new type of pool for these types of assets. It will be using the standard XYK pool formula but with a lower fee. Currently I am suggesting a 0.1% fee out of which 0.05% goes to the LP and 0.05% to the Astro Assembly (the fee is subject to discussion). While this will provide worst swaps when compared to the stableswap pools (the liquidity is not as concentrated) the fees will still be lower than using the standard 0.3% XYK pool.
I think this is an overall positive change to the LP’s while also solving the current problem of using stableswap pools when one asset is increasing in value creating highly unbalanced pools.
you can tweak the stableswap formula for these types of assets.
in the example below i assume x represents the amount of stLuna and y the amount of Luna, and that their exchange ratio is 1 stLuna = 1.3 Luna. i replaced all ys in the original stableswap formula (the purple line) with 1.3y which results in a new curve (the black line) whose balance price is 1:1.3.
we can use an oracle to provide the desired balance price (1.3 in this example) and dynamically adjust the pool’s curve.
But they did say this 0.1% XYK pool might be a good temporary idea as the pool is already unbalanced and there is no ETA on their implementation currently but that it would be soon.
If their implemenation can work with other types such has Prism - xPrism, Luna - LunaX or the future Luna - STEAK it would be awesome. But from what I understand it would take some modification to use their implementation for other pools.
So I think having this 0.1% XYK pool is still a good idea. Until Astroport devs can implement this natively to work with all types of assets (I assume this will need good oracles so they probably have to wait till the launch of mainnet Chainlink oracles).
Yeah, as @Archkiwi already mentioned, we’re working on the pool for Astroport whose design is exactly what @larry described. The gist of it is that for each operation the conversion ratio is queried, so yes, the ratio is automatically adjusted naturally.
The main and very important difference here is that the query is made not to the oracle but to the Lido Hub contract since both the pool smart contract and Hub are placed on the same chain (we still can refer to it as “oracle” but the fully on-chain one). There is no way of using Chainlink oracle in this case. Chainlink oracle (or any other price feed) is ideally based on the market price. Adjusting the market price based on the market price is not the issue we are trying to solve. What we are trying to make is to adjust the market price closer to the real asset exchange rate and the real exchange rate in the stLuna case can be got from Lido Hub only. So we’re not blocked on the Chainlink feed deployment, and all necessary information is already available on-chain.
Talking about the pool’s usage for other assets with similar behavior: it’s definitely possible to use that pool for them. But since the query interface for getting the real exchange rate is different for each pair, the pool implementation either needs to be modified for each pair (only a single place where the query is made) or the pool can be designed the way where it uses a proxy contract that converts the query from the common interface to the specific one.
The design decision here is mostly on the Astroport team I think.
So by the chainlink/oracle impementation it was more of a suggestion for the Astroport’s team rather than talking about Lido’s implementation.
Also would love if you guys respond here again after assessing the risk of the current stLuna-Luna pool and maybe deploying a temporary solution if needed.
Thanks for raising this up, @Archkiwi. Given that auto-compounded staked token will be the standard in the near future, perhaps due to the taxable event-nature of providing additional tokens as yield, a solution like this should also be applied to pools like:
LunaX-Luna
xPrism-Prism
Mars-xMars
I’m assuming a feed will be required from the protocol directly, to get the price of the xToken vs token. However, since this will be subjected to smart contract risk, should we not consider a feed that approximates the current price with previous data points, rather than taking the current price as it is.
In this context, I don’t think sourcing the feed directly from the smart-contracts already deployed by each of these protocols incurs any additional risk: these exchange rates are measured by the Prism/Astroport/Stader contracts as Number of Staked Tokens / Total Tokens in Staking Pool (where rewards accrue) and are essential to the staking modules of each protocol. On the contrary, I think it’s actually easier and more precise to just query the exchange rate from the existing SC rather than spinning up a contract that estimates the exchange rate based on historical data, which would be susceptible to erroneous extrapolations.
In the case of liquidity pools, TWAP aims to flatten the fluctuations while the “real” exchange rates of discussed tokens are not volatile (by “real” exchange rate I mean the exchange rate from the point of a protocol itself). The main risk here is the faulty behavior of smart contracts but firstly it’s not something that can be fixed by any average calculation, secondly, such an error in token-related smart contracts leads to issues anyway. For e.g. if Lido smart contracts for some reason will be wrong in exchange rate calculation, any stLuna or bLuna pool is going to be imbalanced (in comparison with the “real” situation, whatever we define “real” situation since Lido contracts are broken) pretty soon with the help of arbitrageurs. So since Lido hub manages stLuna/bLuna tokens it’s okay to use it as a source of truth for the exchange rate. Same for any other token.
