Service fee market price knowledge for PaymentAdjuster

Background: Concerning the PaymentAdjuster, there is a future issue that can be foreseen. At the time of putting this module together it wasn’t easy but was done eventually which required going through a thorny passage where the various criteria Calculators had to be tuned up. Each Calculator is dedicated to a single parameter and has its Formula, a set of computations that can take a certain parameter of a Payable as an input (the units may differ) and produce a u128 number by applying the computation on it. This is later known as a partial criterion, one of possibly multiple, which when sum up together makes the final weight to be given to the particular payable account, with its debt size and age, which are the only parameters that come into the first implementation but might be broaden by more parameters eventually.

While it mightn't be so hard to invent unrelated formulas per a parameter, the challenge must be understood there where we try to synchronise the partial criterions and combine their values into a single all-embracing weight while each input among these parameters can be considered on a different scale of sensitiveness and therefore the conversion mechanism inside the Formula must reflect the danger of separation these criterions from each other, living each in different magnitude and whose sum wouldn't tell much, respectively, it would let one dominate the other, maybe completely shade the other one's impact, denying the effort to classify the payable intelligently by all the relevant knows about it and decide this way how much out of the available consuming wallet balance we want to provide for this account now when we're trying to form an affordable set of payments that will hopefully succeed after dispatched.

Example: One second has a different importance than one wei, both used as base units in the first implementation. While weis can feel somewhat insignificant easily up to 1 gwei (1,000,000,000 wei), we must pay attention to the seconds already at some 86,400 (1 day). This demonstration shows how important is to give the mechanism a proper tuning that will ensure the value of the calculated partial criterion of one parameter will make sense in the context of the other parameter, also represented by a single number. This tuning isn't particularly easy to be done if you want to be serious about it (and I think we should because otherwise it would considerably lower the value of PaymentAdjuster as the Node's component ) and that led me to a series of thinkings on how I could complete the functionality and leave it in a state where it we would have to touch the tuning (done through many constants I declared) as little times as possible.

I had to brush off my math knowledge from colleague to be able to think of something what I see as the right tuning and what more, to put it into math expressions, and last but not least, into code. I wish it hadn’t been but it was quite scientific. Anyway, later on, my concerns begun be serious. I knew that if nobody pokes in the formulas all should go on with the right trajectory. The issue is not touching it is not enough. While time will always be simply time, the urgency of a certain balance is likely to change as the price of our service fee changes fluctuates. Small changes until 10% might not cause to smash the tuning but bigger changes should be probably addressed. This is a big issue because we need the tuning to persist unchanged, we cannot afford having to adjust it manually every so often. Therefore we will have to keep track of the price change and incorporate it into the tuning. How to do that?

I'm going to create an anchor, price that matches the time when I did the last tuning. (This is important to stress, because every time somebody decides to interfere with the it they will have to change the value of this price anchor again.). With its help, put next to the actual price at a time in the future, a calculation provides a new parameter, a multiplier. At the moment I'm actually talking about a multiplier (or divisor respectively) of the partial criterion from the Balance formula. That will eliminate the factor of an evolving market price, over time, the sync of the age and the balance would be out of danger.

Considerations:

This all can be done. The question I’m pondering is if the team can help me with some decision making and the actual design of how we would approach the token price tracking. Rephrased, at the minimum, before we go further, I’d like to check on any support for giving Node this knowledge. One important thing to consider: Until now, we communicate with only one API, used for the blockchain services. I don’t think we would be able to ask this information of the same provider. Therefore we might have to end up adding another one. Is that an issue?

More questions:

How often would we try refreshing on the information? Which actor would get this in its agenda? (Probably also BlockchainBridge?) Where exactly would we put this step in all the steps of the sequence during paying bills. (Do we want to do it only once at the start-up? Do we want to do it every time the payable scan is ordered, despite we yet mightn't know if the PaymentAdjuster is going to be called at all? Do we want to do it less frequently and so asynchronously to the scan cycles?)

My current design is planned to use this information in a structure called PaymentAdjusterCalibrator whose purpose is to bring in any kind of numbers that would help us keep the tuning in a good condition. Each parameter taking a role in the adjustment will have its own calibration coefficient by which I will multiple the numeric products of the criterion Formulas. That means some of the parameters will probably always have this coefficient just 1 but it's going to be ready for any action in this direction in the future. I want the engagement for all parameters instead of making the calibrator an exclusive thing devised just for the Balance or whatever other parameter.

We can also give some more thoughts on other potential usages for current token price as the only purpose being with the PaymentAdjuster might feel a bit vague. .

MASQ-Project / MASQ-Node-issues

Service fee market price knowledge for PaymentAdjuster #773