That is my proposal.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.
The MIN and MAX are just the general bounds, whatever the price is. We need to have general bounds.Using MIN/MAX ANO spots cannot describe that equilibrium very well.
The question is: what minimum value is needed to be decentralised enough? I have been proposing 25 ANOs.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 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...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.
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.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.
If clear criteria are stated, it is to audit Guide actions. And they don't follow governance rules then there is a demotion process.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.