Some more thoughtful comments on this vs my initial take -
Two of the main concerns here I think are -
-
cost of oracle manipulation
-
oracle correctness for liquidations and minting IST
Oracle Correctness
Let’s take a hypothetical scenario:
$ATOM is trading at $10 and the redemption rate is 1.2stATOM/ATOM. stATOM is trading at par, $12. A bug is exploited in the Stride contracts and users flood to redeem stATOM for ATOM and sell on exchanges. The redemption rate is still quoting 1.2stATOM/ATOM but the market is quoting 0.6stATOM/ATOM.
- Oracles that should be forcing liquidations will not be, as the 1.2stATOM/ATOM quote does not breach the threshold.
- If ATOM/USD also drops, and vaults were already set to liquidate at say $11 stATOM, the auctions might go below par. Vaults may be on the losing end, depending on the discount, but overall the descending price auction mechanism should still allow the collateral to safely liquidate.
(a fixed liquidation discount rate would not have this benefit) - A user buys a bunch of $6 stATOM, and mints $IST at an $11 rate. When they need to pay back their debt, the oracle is still quoting $11 so there is no loss for the protocol. If they abandon the vault, and the max LTV is 60%, the depeg needs be to greater than 40% (6.6 IST per stATOM) to be profitable for the attacker (assuming IST holds its peg).
In a less severe scenario, the ~20 day unbonding period may cause a delta between the market price and redemption oracle. This may create some arbitrage opportunities when opening and closing vaults, but the spread may not be materially significant. The main concern really just seems to be a prolonged/permanent depeg from the underlying.
Oracle Manipulation
Alternatively, one could consider the risk of depeg to be lower and instead find oracle manipulation risk to be a greater concern. Here, potential attack vectors open when pools do not have a lot of liquidity. Euler has a tool for quantifying the cost of manipulating the Uniswap TWAP oracle which is interesting for those intereseted.
If we are able to quote the more widely available ATOM, there will be less oracle manipulation risk. It also seems like it may allow for a higher deposit cap.
Harbor Protocol Oracle Incident
Two weeks ago there was an issue with the stATOM price oracle on the Comdex Harbor Protocol. The incident report states an average of prices from three sources - Coingecko, Osmosis, and cSwap - and an incorrect data pull from ShadeSwap caused the Coingecko price to drop to $0.02.
This is worth noting since we may also come to leverage the Coingecko oracle. ShadeSwap seems to have caused 3 big blips on the stATOM price on Coingecko. They are not currently listed as a source in Markets, but may come online again and further affect the oracle.
More notably, @dtribble joined us at developer office hours last week and explained how this would work with Agoric’s implementation of the Chainlink FluxAggregator design. This takes the median of values, instead of the simple average, so 10+10+0.02 would result in a quote of 10 instead of 6.67. This was great to hear, and worth sharing for folks who may not be aware.
Takeaway & Next Steps
These are some tradeoffs I see, but it seems like there are viable solutions for quoting stATOM. I am curious to hear back from @francescoSimply or other oracle network providers on venue capabilities and any visibility we can provide to protocol users about the composition of our final price quotes.
Some more discussion may need to take place, but I wanted to touch on next steps for when it’s time.
I imagine we should have some sort of signaling - perhaps a poll in this thread will suffice if we can get a high enough turnout. And if that’s successful, we will need to fill out the onboarding template. @John_Galt - if you’re open to taking the lead on this as a Stride community member, that would be greatly appreciated. I am also willing to help compile answers for some of the questions and imagine @RedRabbit would be happy to pitch in as well!