Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic Rates #497

Open
stubbrn opened this issue Jul 2, 2023 · 2 comments
Open

Dynamic Rates #497

stubbrn opened this issue Jul 2, 2023 · 2 comments

Comments

@stubbrn
Copy link
Contributor

stubbrn commented Jul 2, 2023

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.

@dimalinux
Copy link
Collaborator

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.

@stubbrn
Copy link
Contributor Author

stubbrn commented Jul 3, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants