I think I may not have expressed myself well enough.
So, my suggestion is to maintain our current MAX as a constant, which is 65, then to have a variable number that defines the current equilibrium target.
That is my proposal.
Using MIN/MAX ANO spots cannot describe that equilibrium very well.
The MIN and MAX are just the general bounds, whatever the price is. We need to have general bounds.
is to do our best to establish an equilibrium where the size of the authority set is large enough to ensure decentralisation whilst, at the same time,
The question is: what minimum value is needed to be decentralised enough? I have been proposing 25 ANOs.
This target could be lower than, equal to, or greater than the current size of the authority set. Where it is lower than the current size of the authority set, any ANO that is demoted would not be replaced by an applicant. Where it is equal to the current size of the authority set, ANOs that are demoted are then replaced by applicants. Where it is higher, we can promote new applicants without the demotion of anyone within the current authority set.
The target you mention are the ones I am proposing. We may agree or not on the exact value but I think this corresponds to what you say. I think my post was not clear on this...
To be clear, my proposal was to set a target based on the price. This target being generally comprised between [MIN ; 65]. Nothing more. Again, you need a minimum value. E.g. 5 ANOs is completely unacceptable.
An example of my proposal :
The weekly values of the FCT price has been over 10$ (based on an Oracle to be defined) during 6 months and for some weeks over 15$. Then automatically the number of slots is set at MIN+10 (i.e. 35 if MIN is set at 25).
And then 2 cases:
- if there are only 32 ANOs currently in the pool, then there are 3 new slots available;
- if we already have more than 35 ANOs => nothing changes except that during a next ANO demotion, no new ANO would be elected.
As an aside, if my reading of Doc 105 is correct, we have actually limited ourselves by only being able to maintain the size of the authority set or expand it. We should have the option to add no new ANO if another is demoted. I will bring this up on the thread.
Yes and no - If no candidates has enough standing to integrate the ANO pool after an ANO demotion then the Guides could decide to lower the number of slots available during week 5 or week 31.
Our goal here is to try to limit the power that Guides have when defining the target size of the authority set. Fetching the value of USD from Coinmarketcap places the Guides in the role of price oracle. Fortunately, we now have a decentralised price oracle in the form of PegNet, so my preference would be to pull price values directly from the PegNet chain.
If clear criteria are stated, it is easy to audit Guide actions. And if they don't follow the governance rules then ANOs can start a demotion process.
On the mid-term, yes an automated oracle would be nice. PegNet would be cool if it works as expected.