Dynamic Rates
stubbrn opened this issue · 2 comments
It would probably be beneficial for both makers and takers to be able to define dynamic rates, or more specifically a fee variable (a percentage, like 1.025), that would be multiplied with the last fetched price of the concerned token.
A maker ideally doesn't want to recreate an offer each time the price fluctuates a few percents up or down.
A taker looking at an offer is probably not so much interested in the exchange rate itself, but how much he is paying over current market prices.
It is a tricky problem to know exactly what the end user might want. I'd come up with a full proposal on the desired behavior before implementing it. The offerID will change when you change the exchange rate, so what you really will be doing is removing the existing offer and adding a new one with the new rate. Would there need to be a barrier to prevent the maker's floating rate from dropping below some minimum value? We also might want to better understand how Chainlink is computing the price and if it is at all open to short term manipulation. We don't have an oracle for ERC20 token values, so this would have to only be for XMR/ETH swaps.
It is a tricky problem to know exactly what the end user might want.
That's true, at the same time this one seems kind of obvious;
If the only value that you can check is the exchange rate between XMR and ETH/Token of a certain offer, most users will probably end up manually calculating what's effectively the maker's fee by comparing it to the actual current exchange rate.
So at least in my mind it's about automating something that nearly all takers will end up doing because without that information you can't really evaluate how attractive the offer is.
Would there need to be a barrier to prevent the maker's floating rate from dropping below some minimum value? We also might want to better understand how Chainlink is computing the price and if it is at all open to short term manipulation.
If this could really be an issue I'm not sure about what would be the best way to go about it, maybe a minimum exchange rate parameter.
Set at something like -2% by default (from the initial exchange rate), if it dumps below this it either replace the rate with that minimum value, or delete the offer.
Or maybe some kind of moving average ?
We don't have an oracle for ERC20 token values, so this would have to only be for XMR/ETH swaps.
Maybe it would make sense to check uniswap's contracts to get the exchange rate between an ERC20 token and ETH (and then inferring the token/XMR with the ETH/XMR exchange rate). I think it's possible for both uniswap V2 and V3 to query a pool's exchange rate from the contracts.
Even in cases where the liquidity is greater on CEXs I would assume that there's a decently tight arbitrage between those and the uniswap pools.