Open christianbrb opened 4 years ago
@christianbrb discuss with management which values should be used before we can make the code changes which is a simple change.
Trying to describe my process to make it reproducible
Process collecting the data:
DAItoSVT
like this -> DAItoSVT = DAItoUSD / RDNtoUSD
We have got the following possibilities if the rates are changing: a. If the ratetoSVT is going to be higher than the current value we run into the risk that the monitoring reward the user is paying is higher than the current capacity. b. If we the ratetoSVT is going to be lower than the current value we run into the risk that the user is losing more tokens than he would have to pay for the monitoring reward.
I would rather go with option a than b. Therefor I am going to add a quite high safety margin to the default as the values are fluctuating quite a lot.
Max/Avg | DAIratetoSVT | WETHratetoSVT |
---|---|---|
Max | 12,29518072 | 2106,736712 |
Average | 5,60189866 | 1426,450214 |
I would go with the following rates: DAI - ratetoSVT: 40 WETH - ratetoSVT: 8000
@andrevmatos Any thoughts or remarks? If not, you can go ahead and implement this.
Only needed if we don't implement the automated ratetoSVT #1513.
Description
Set ratetoSVT as a default for DAI, WETH and TTT
See the following sheet with historic rates: https://docs.google.com/spreadsheets/d/1U1vOtUQdavuEHAXQ33p9WyTuViaHzL4s9Dnd9ejJBhE/edit#gid=569930139
The DAI/WETH thresholds the python team is using can be found here: https://github.com/raiden-network/raiden/commit/041aa1bb2eb6adbeb150e4428a6dfd7f38d1a190#diff-14a4915b775dfbab039e080a28553d78L91
I think we can safely remove the approach implemented in #1705
Acceptance criteria
Tasks
Why do this?
Protects the client from having funds wasted by small transfers triggering monitoring rewards. In order to do a comparison the costs must be known.