Post in thread 'ANO Election and Demotion System - Amendment proposal' - Content history

Formatted Raw

  • 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. You need to have general bounds as you said

    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 comprised between [MIN ; 65]. Nothing more. Again, you need a minimum value. E.g. 5 ANOs is completely unacceptable.


    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 to audit Guide actions. And they don't follow governance rules then there is a demotion process.
    On the mid-term, yes an automated oracle would be nice.
Top