light-client
light-client copied to clipboard
raiden-network
Fetch real time token exchange rates
Description
On #1494 , we introduced the rateToSvt config, which is required for receiving and monitoring transfers, and allows to set a conversion/exchange rate between the transfer token and the service token on which monitoring rewards are paid, so we can only sign/pay these rewards when economically viable (i.e. amount to lose if channel isn't updated upon closing is higher than service fee).
This was just the simplest approach possible for the feature. Of course, this isn't ideal, since these rates can fluctuate quite a lot at runtime or across sessions. Specially on mainnet, we must find a way to keep this up-to-date and not requiring manual user intervention (user intervention/config should be limited to fixed amount they're willing to pay for MS reward, config.monitoringReward, in SVT/RDN).
The proposal is to fetch this rate from open price oracles and/or dEXes, with a sane fallback for unknown/exotic tokens the user may be testing or on testnets. Preference for open smart contract based price oracles able to aggregate multiple DEXes prices on-chain. Fallbacks for unknown tokens could be either:
- Receive transfers in a best-effort basis, never send monitoring requests
- Let the user set rates by hand to whitelist a token for receiving/monitoring
- Setting it to 0 would make the token value nothing and receive but never send monitoring request
- Setting it to INF~=MaxUint256 would enable receiving and send monitoring request for any received transfer (user's call)
Dynamic exchange rate has a point which needs attention: if rate falls and new (smallish) transfers don't cross the worthy threshold, the effective monitoring request may be one sent previously, which may be outdated even though it would not be worth to be sent now. On this case, we may want to still sign and send a monitoring request to replace the old one.
Another option for this issue would be to interactively present the user the option to sign monitoring requests once they receive a transfer, showing the values to lose if not accepting, and letting the user decide if they want to pay it or not.
Acceptance criteria
- Exchange rates for mainnet tokens are fetched dynamically and reflect real time value of tokens of interest and RDN
- Automatically decide for monitoring requests, or request user decision, about received transfers, based on these up-to-date values
Tasks
- [ ]
Why do this?
This one is necessary if we want to set dynamic values for #1874.
Are we aware of any services we could use for that that are reliable?
@andrevmatos any suggestions on this?
We need to investigate, but I think Uniswap's contracts are a good default to fetch on-chain exchange rates, and would support all the tokens we need.