Make large create/redeems more expensive, by moving price dynamically à la Uniswap.
When the system is underwater and needs funding (FUM buyers), make the FUM price decline over time.
With these changes, I’m actually pretty enthusiastic about this stablecoin design, and we’re going to try to get it into production! Collaborators/feedback welcome, see the post. The dream here is a very simple, easy-to-use, reliably-pegged stablecoin that’s truly permissionless/ownerless, in the way Uniswap is, so our whole ecosystem doesn’t end up built on top of semi-permissioned infra like USDT/USDC. (Though if the market goes to DAI that works too!)
I am wondering how the mint_burn_adjustment and fund_defund_adjustment work when there is a big price change that is only reflected by the oracle after some time.
After the change, arbitragers take advantage of the discrepancy and buy/sell until the adjusted price is equal to the real price. When the oracle comes with the updated price, does that mean that the price is out of equilibrium again and the arbitragers have another opportunity?
This could be solved by changing the adjustments when the oracle updates the price, such that the on-chain price is unaffected. We still need to slowly reduce the adjustments to make sure the on-chain price cannot drift away from the real price.
You also might want to implement the front-running remedy proposed in here:
It’s true that a significant risk is the oracle falling behind live exchange prices, allowing fast traders to front-run the system, and potentially drain it over time. The Uniswap-like “sliding prices” mechanism introduced in post #2 above is intended to mitigate this… We’ll have to see whether an on-chain oracle can be accurate enough to resist these exploits.
To your specific question about the adjustments, the short answer is that they only move one side of the market, not both - effectively widening bid-ask. Eg, buying makes further buys more expensive; it doesn’t make sells cheaper. So no, when the oracle’s price catches up with reality, that shouldn’t introduce another arbitrage opportunity. Example:
Real-time price is $400, oracle price is $400, both mint_burn_adjustment and fund_defund_adjustment = +0% (no adjustment)
Real-time price drops to $390, oracle still $400. Trader takes the opportunity to mint (aka sell ETH for USM) at $400.
Because of the “sliding-price” mechanism, this selling pushes mint_burn_adjustment to $390 / $400 = -2.5%. At this point, users can sell ETH (mint) for $400 - 2.5% = $390, or buy ETH (burn) for $400 + 0% = $400.
Oracle price catches up to RT price: both $390. So now, users can sell ETH for $390 - 2.5% = $380.25, or buy ETH for $390 + 0% = $390. Neither of these opens up an arbitrage.
Over the next period (few minutes?) without trading, mint_burn_adjustment gradually shrinks back to +0%, so that soon the sell price has tightened back to $390 - 0% = $390. Buy price is still $390.
An additional possible mitigation is to make our oracle support a distinction between buy price (the price buyers pay) and sell price. Eg, the buy price could be the highest price from a few other oracles, and the sell price the lowest. This would create an extra safety gap between the two, and cause the gap to widen when markets were volatile, which seems healthy.
And yes, the adjustments closely resemble Vitalik’s “virtual quantities” scheme, widening one side (but not the other) on trades. I believe I read that post when it came out but tbh I’d forgotten about it - but maybe it influenced me subconsciously. Or perhaps I was influenced by some Bitcointalk forum post from 2011
