ANO Election and Demotion System - Amendment proposal

Following a brief discussion with David (see quote below), I am opening this new thread.

I agree with you. Specific criteria should be determined and codified so that it can be automated in the future. However, I ask that we make that a separate thread and we either amend this document in the future or have it be a separate document referenced by this one in the future. Determining the exact criteria will be a bit of an undertaking. Would you like to lead that initiative?
CONTEXT:
Doc 005 defining the ANO Election and Removal process is a massive step forward in our governance processes. As stated several times by the co-sponsors, it is a first iteration and improvement of this mecanism is an on-going process.
I have raised 2 concerns/improvement proposals about the current document shared by some parties. I propose to discuss one of them in this thread and to find a consensus before proposing a new ratification/amendment process.

PROPOSAL:
- The improvement proposal is about defining the number of ANOs spots available. Currently, Doc 005 leave it to the discretion of the Guides twice a year. Not to have specific/objective criteria is not satisfying for 2 main reasons:
First, we need such criteria to automate a maximum of actions within our governance processes. The more we can define such criteria, the easier it is to automate these actions.
Second, Guide role is originally here to facilitate processes. Not to exercise control over them. I personally think we should stick to that vision as much as practically feasible.

QUESTIONS TO BE ANSWERED:
Criteria to be used to define the number of ANO spots available :
1. What should be the MIN/MAX number of ANO spots available?
2. What should be the trigger criteria for increasing/decreasing that number between these 2 bounds?


Here some ideas:
- [MIN] It could seem obvious but the number of spots available needs to be at least equal to the number of ANOs currently in operation;
- [MIN] The Min bound should be set in order to an appropriate level of decentralisation. This is highly subjective; I propose at least 25 ANOs;
- [MAX] The Max bound is already defined in our main governance document : 65;
- [TRIGGER] One of the proposed options is to define increase or decrease based on FCT price;

Here is one proposal:

The number of ANO spots would be revised every 6 months (as in the original proposal) ; The price values considered could be the weekly ones from CoinMarketCap (https://coinmarketcap.com/currencies/factom/); FCT weekly prices should stay above the following prices (see below) during 6 consecutive months (26 points) to trigger a change in the number of ANOs slots ; Considering weekly values would make difficult the manipulation of the prices for governance reasons ;

>0$ : MIN ANOs spots
>5$ : MIN+5 ANOs spots
>10$ : MIN+10 ANOs spots
>15$ : MIN+15 ANOs spots
>20$ : MIN+20 ANOs spots
>25$ : MIN+25 ANOs spots
>30$ : MIN+30 ANOs spots
>35$ : MIN+35 ANOs spots
>40$ : MIN+40 ANOs spots (using MIN=25, => 65=MAX )

3. What document should be amended? Doc 001 or Doc 005?
In my opinion some information should be in Doc 001 such as MIN and MAX number of ANOs and some others into Doc 005 such as the trigger criteria based on FCT price;
 
I think the idea of changing the number of ANO spots based on the price of FCT is correct. The value of FCT inflation in terms of USD determines the maximum output that can be financed using inflation. So it makes sense to use the value of that inflation in USD to derive the size of the authority set.

I don't think that describing the availability of ANO positions in terms of a minimum and maximum is sufficient for our needs. Our goal here, I think, 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, being small enough to ensure the grant pool continues to receive ample funding. Using MIN/MAX ANO spots cannot describe that equilibrium very well.

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. 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.

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.

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.

Supposing we get that in place, then the remaining challenge is to establish the correct algorithm to determine the current target size.
 
Thanks Alex for starting the discussion!

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.
EDIT: I have read again the doc and you are right : "decide if the number of default ANO positions will stay the same or increase ".

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.
 
Last edited:
First, we need such criteria to automate a maximum of actions within our governance processes. The more we can define such criteria, the easier it is to automate these actions.
Second, Guide role is originally here to facilitate processes. Not to exercise control over them. I personally think we should stick to that vision as much as practically feasible.
I certainly agree with your first point, but the second is not entirely true. From governance 001:

  1. Guides are charged with maintaining the orderly operation of the protocol network and facilitating the relationships between standing parties and the community.
  2. Guides will be responsible for overseeing the application of the protocol governance to the operation of the protocol. To be fair, everyone involved are responsible for adhering to governance, but in practice, the Guides will be in the best position to provide guidance.
  3. Maintaining the orderly operation of the network includes ensuring an adequate number of applicants to run a large enough pool of servers to ensure 65 servers are always available for the Authority Set. The guides will be in close communication with the Testnet, and monitor the performance of members of the Testnet Authority Pool.
Guides really are in charge of making sure we have 65 servers in the auth set as well as the expansion of standing parties (as defined elsewhere in the same governance). It is one of the reasons we have guides in this whole process of course.

Yes the more we can do objectively the better. The more we can automate the better.

But price alone for instance is not a good metric. We also have to take into account efficiencies. If everybody would go to 0% efficiency at 5 dollars for instance and our objective criteria would say we should be at X ANOs we are doomed as a protocol.
Guides are massaging entities into moving to higher efficiencies and doing more work from grants because of better oversight and better consensus on what, when and with what price. So my suggestion would be to tackle this thread in a broader discussion about the future roles of ANOs, as that will allow us to better define these objective criteria for ANOs.
 
I certainly agree with your first point, but the second is not entirely true. From governance 001:
Yes Guides have a management/coordination role. These principles do not define by themselves the mecanics to apply this coordinnation role such how much standing, what decision can they precisely take... and this is what we are discussing and definings through all our governance discussions.


Guides really are in charge of making sure we have 65 servers in the auth set as well as the expansion of standing parties (as defined elsewhere in the same governance). It is one of the reasons we have guides in this whole process of course.
I am fine and agree with that. Again I was speaking about decreasing the number of ANOs. Which is something with new potential risk and consequences for the protocol.


But price alone for instance is not a good metric. We also have to take into account efficiencies. If everybody would go to 0% efficiency at 5 dollars for instance and our objective criteria would say we should be at X ANOs we are doomed as a protocol.
Guides are massaging entities into moving to higher efficiencies and doing more work from grants because of better oversight and better consensus on what, when and with what price. So my suggestion would be to tackle this thread in a broader discussion about the future roles of ANOs, as that will allow us to better define these objective criteria for ANOs.
Let us discuss this now ! :)
About your particular example, I was actually about to mention the proposal by Alex and Mike to consider efficiency in the calculation of the Standing. This would clearly resolve this issue. I did not make it to actually... separate the different topics.
What weight should the efficiency have?
 
Last edited:
That is certainly a point of view and not consensus. We have this saying in the Netherlands. "The butcher testing his own meat", meaning you need others judging and counter balancing. Just like we have seen people heavily opposed to the sponsors of the current ANO election/demotion process for various reasons, we have also seen that getting things done in this ecosystem has become worse and worse over time. The fact we only still have one standing type (besides guides), for various reasons, certainly hasn't helped in decision making, lack of oversight, the need to perform etc. But yes let's leave this for what it is right now, as this thread will close in a few hours anyway.


---
edit:
Crap, now I have threads mixed up :p
 
While I'm in favor of holding ANOs accountable, and making sure ANOs are performing and contributing to the ecosystem, I'm very much against automated reduction of ANO slots based on anything other than performance, especially price. Sometimes companies need to fire good performing employees for the health of the company during off times, but these are decided during the critical times, rather than automated. If the demotion doc gets approved, then we'll have a means by which we can all collectively decide, that we have too many ANOs and we need cut some. Loss of Standing would occur and we can collectively decide the painful process of removing PERFORMING ANOs. If you cut a performing ANO because of an automated process, and the price swings back to open up another slot, in all likelihood you will not get that ANO back. Lets be honest, we don't have huge numbers of well qualified candidates pounding on the door to become ANOs. If you think we have non-performing ANOs, we can get rid of them with the new demotion doc (assuming its approved), if you still feel after removing non-performing ANOs we have too many ANOs, then lets all collectively decide we cannot afford that many ANOs and make the cuts. Automating the process is just a way of avoiding those painful decisions or washing our hands of the dirty work that may be necessary.
 
I don't think anyone has suggested cutting performing ANOs with an automated system. What i proposed was to have a variable target for the size of the authority set, which can be less than the current size of the authority set. If that target were lower than the current size of the authority set, then ANOs who fall out of the authority set would not be replaced.
 
- [MIN] It could seem obvious but the number of spots available needs to be at least equal to the number of ANOs currently in operation;
I have started my thread with this statement.
So of course no automated demotion. As Alex said, if we go for a pool size lower than the current number of ANOs in operation then it does not change anything except when next demotion occurred. The spot is then not filled again.

Does this clarify/answer your point @Michael Lam ?

(Sorry, I think I have done a terrible job to express my point in this thread)
 
@Alex @Matthias Fortin Your clarifications on intent help, but when I hear "maximum ANO slots" and the number of ANOs are over that, I automatically think demotion has to happen. And unless I missed it, your original post doesn't actually clarify that automatic demotions don't happen if we are over the 'maximum' slots.

In this sense, your proposal is a way to decide when to grow the authority set, rather than the current proposed doc, which I believe the guides set? or when someone achieves 90% support. I'm assuming the 90% support would still exist even with your proposed amendment, in which case, this just removes the decision making from the guides and places it in an automated fashion, correct?
 
Any system we implement should be flexible enough to allow an entity of importance to join the authority set despite a very low price. Price is only a small part of any equation we should use. If the pledges or the name is/are big enough giving 350 FCT per month to such an entity is a very small price to pay.

We can automate most of it but we'll need to keep the governance flexible enough to allow the unlikely cases where a potential ANO wants to join the authority set and bring a lot of value like :
- Powerhouse name (IBM/etc)
- Big university
- Big pledges (core developers, etc ?)

Although I agree with the general idea that we should not overtax the grant pool by prematurely adding ANO for the sake of decentralization, we should not have hard cap based on something like prices floor. That hard cap should be lifted anytime a star team wants to commit.
 
this just removes the decision making from the guides and places it in an automated fashion, correct
That's correct.
It's a discussion about what criteria should be used to move the number of available slots in an automated way if possible.

Following Miguel post, there are certainly other parameters than price to consider: efficiency, reputation of the candidate/pledges...

I need to think a bit more about this but I am sure there is a solution flexible enough and still automated in some ways.
 
Last edited:
We thought about the issue @Miguel Proulx describes in the current document up for ratification and there is a solution implemented already.

If an applicant gets 90% support they get directly elected and an ANO spot created for them.... So if a big university or IBM shows up there is a viable pathway to get these elected more or less instantly.
 
We thought about the issue @Miguel Proulx describes in the current document up for ratification and there is a solution implemented already.

If an applicant gets 90% support they get directly elected and an ANO spot created for them.... So if a big university or IBM shows up there is a viable pathway to get these elected more or less instantly.
I knew and liked that clause in the document. Wasn't sure if what Matthias was proposing would be superceeding it, thus my comment. I am a big fan of the constant election and not having hard caps based on prices. If someone wants to join in and is bringing way more value than it is costing the protocol, they should be allowed to, no matter the token price.
 
Such an automated system is possible to implement. What are we saying here?

- we want to elect the best ANOs candidates
- we want to preserve the grant pool
- we want to be able to keep slots open whatever the price is in case a massive opportunity (a famous organization) submit its candidacy.

Such a system is possible. It just needs a better refinement than my initial proposal.

=> The solution: the hard caps based on price initially proposed in this thread could be overpassed when a particularly high level support is reached, then becoming soft caps.
(This level of support could also be tied to the FCT price but this could overcomplexify everything. So let's leave that aside).

Example:
This particular level could be as high as 80% (or even 90%). In case a massive organization submit its candidacy this level of support would be easily reached.
The demotion level would still be at 40% as the current proposal.

This way we would have a system:
- which is partially based on price to preserve the grant pool by limiting the number of slots available (soft caps);
- which is flexible enough not to miss an opportunity to onboard a massive name in our ecosystem;
- which is even more a constant election ; you do not even need to wait for week 5 or 31 before increasing the number of ANOs; we could onboard as fast as possible a famous organization;

Of course to do so, we also need to define the transition process when we'll go over 32 ANOs.

I think this proposal answer most of the relevant points raised in this thread. What do you think? :)
 
In this proposal, criteria are defined in advance to overpass the cap on the slots, then they are more transparent making it easier for new candidates to onboard (they know what they need to achieve).
And last but not least it enables the system to be automated and then to have constant election without waiting for the Guide decision on week 5 or 31.
Does that make sense?
 
Last edited:
We need to be creating processes like Matthias is trying to do here for the good of the protocol.

I believe it's vital that these kind of rules are made ahead of time in an open and transparent manner.
Otherwise, its another situation where anyone looking at the protocol can say "Well they make slots available for people as and when they please."
 
Top