Ratified Doc 005 - ANO Election and Demotion System

Public: Only invited members may reply

  • Viewed Bedrock Solutions Bedrock Solutions Blockchain Innovation Foundation Blockchain Innovation Foundation Blockrock Mining Blockrock Mining Brian Deery Canonical Ledgers Canonical Ledgers Consensus Networks Consensus Networks CryptoLogic CryptoLogic Cube3 Cube3 DBGrow DBGrow De Facto De Facto Factable Solutions Factable Solutions Factom Inc Factom Inc Factomatic Factomatic Factomize Factomize Factoshi Factoshi Federate This Federate This Go Immutable HashQuark HashnStore HashnStore Kompendium Kompendium LayerTech LayerTech Luciap Luciap Matters Matters Multicoin Capital Multicoin Capital Nic R Niels Klomp Nolan Bauer PrestigeIT PrestigeIT Quintilian RewardChain RewardChain Stamp-IT Stamp-IT The Factoid Authority The Factoid Authority VBIF VBIF
  • Not Viewed None

Should the document be ratified or amended as specified by the thread type?


All votes are in

  • Total voters
    33
  • Poll closed .

Timed Discussion

Discussion ended:

Status
Not open for further replies.
Dear community,

Factomize LLC, Centis BV and The 42nd Factoid AS are co-sponsoring an ANO Election and Demotion System and hereby put the associated governance document up for ratification by the Factom Standing Parties.

The suggested document has been quite extensively discussed already in this thread and the Legal Working Group has also provided valuable input (thank you).

We believe that the system described in this document will vastly improve many aspects of the Factom ecosystem, and will put us on a course to properly implement the standing system as envisioned and described in the Factom Governance Document (Doc 001).

It will also be the first step towards a proper on-chain governance framework, where standing parties have digital identities and can signal their support on-chain which would be interpreted by a reworked daemon on the system backend on the protocol forum.

The document up for ratification is available here: Doc 005 - ANO Election and Demotion System.

Some of the proposed changes requires additional changes to Doc 001 and Doc 003, and these documents will be put up for amendment approval at a later time as this ratification progresses.

All the best,
- Centis BV (Guide)
- Factomize LLC (ANO)
- The 42nd Factoid AS (Guide)
 
Last edited:

Chappie

Factomize Bot
This thread is a Document Ratification/Amendment Timed Discussion and I am designed to help facilitate efficient communication.

Guides and ANOs may take part in this discussion and vote. Unless this discussion is ended early or extended, it will end in 8 days after which a vote will take place. After 18 hours from the start of the thread or any point up until 24 hours are left in the discussion, you can make a motion to end the discussion immediately or extend the discussion beyond it's initial time frame by selecting the pertinent button at the top of this thread. If someone "seconds" your motion, a poll will take place which requires a majority of Standing Parties to vote one way or the other.

At the end of the discussion period, Guides will vote first and 4 must vote yes otherwise the process ends. If 4 do vote yes, ANOs then vote and if 60% vote yes, the document is successfully ratified or amended.
 
In section 2.11, these sentences confound me:

"Candidate ANOs can automatically be promoted directly to ANO status by obtaining 90% support of the Standing Parties even if an ANO spot has not become available through ANO demotion or by Guides making more ANO slots available.
Note: This does not apply if the Authority Set is at its temporary maximum limit of 32 ANOs. "

If no ANOs are demoted, and the guides don't add space for more ANOs, where does a candidate with 90% standing go to if there isn't a spot? Is a new spot automatically created and the ANO is added there? If so i think the wording needs to change to say that the ANO capacity grows by one and then the ANO is added to that spot. It already sort of implies this as the only thing that makes sense, but since the whole document is so specific about exactly what happens, it seems to me that it needs to be clearly spelled out.
 
Also:
"A promoted ANO is expected to have successfully completed the procedure described in Doc 204 within 14 days of being promoted to ANO status. "
This seems tight. If you are hanging out on the 'waiting list' to be come an ANO, and you are suddenly out of the blue told you need your servers and such up in 14 days (which includes getting feedback from existing ANOs on whether your settings are correct), I think its a rush. Especially if you are on vacation when you get the news or its the holidays or whatever. 30 days seems more reasonable, especially since the 14 days doesn't seem to be a critical limit.
 
Also:
"A promoted ANO is expected to have successfully completed the procedure described in Doc 204 within 14 days of being promoted to ANO status. "
This seems tight. If you are hanging out on the 'waiting list' to be come an ANO, and you are suddenly out of the blue told you need your servers and such up in 14 days (which includes getting feedback from existing ANOs on whether your settings are correct), I think its a rush. Especially if you are on vacation when you get the news or its the holidays or whatever. 30 days seems more reasonable, especially since the 14 days doesn't seem to be a critical limit.
The dynamics for ANO's to be promoted into the authority set are changing due to the following factors:
- Previously the ANO round from start->finish was quite short.
- In this new system applicants are required to have a testnet presence before applying, so they will have experience with deploying factomd and setting up and securing their servers.
- Applicants will most likely build their standing over multiple months, and when they start getting close to 60% or new ANO spots opening up they have ample time to prepare their servers, as well as creating their authority identities beforehand.
- Teams may deploy on AWS or similar as an interim solution before moving their identities to their final servers if they like.

We will also improve doc 204, and create a proper checklist where teams will be able to self-asses their readiness to ensure that things will go more smoothly (instead of going back and forth with the core committee).

With the above in mind I think 14 days will be a decent goal, and as it's known beforehand teams will be able to make necessary arrangements.

It's also not a hard limit so if there are special circumstances like a vacation/holidays this could be worked around.

I think 14 days would be suitable under the conditions described here, but if others also would like it longer I'm happy to bow to the majority :)
 
In section 2.11, these sentences confound me:

"Candidate ANOs can automatically be promoted directly to ANO status by obtaining 90% support of the Standing Parties even if an ANO spot has not become available through ANO demotion or by Guides making more ANO slots available.
Note: This does not apply if the Authority Set is at its temporary maximum limit of 32 ANOs. "

If no ANOs are demoted, and the guides don't add space for more ANOs, where does a candidate with 90% standing go to if there isn't a spot? Is a new spot automatically created and the ANO is added there? If so i think the wording needs to change to say that the ANO capacity grows by one and then the ANO is added to that spot. It already sort of implies this as the only thing that makes sense, but since the whole document is so specific about exactly what happens, it seems to me that it needs to be clearly spelled out.
Thank you for making this point. I think I'll agree and will take a stab at including it tomorrow.
 

Chappie

Factomize Bot
We are now 18 hours into the discussion. You may now make a motion to extend this Document Ratification/Amendment Discussion by an additional 72 hours or end this conversation by selecting the pertinent button at the top of this thread. This option will end when there are 24 hours left in the discussion.
 
I believe we need to add an objective element to the scoring, similar to how we currently score ANO applications. I did not get much support for my suggested scheme in the previous thread. So, instead I will simply suggest that we include only efficiency as a support category. The rationale for this is to reward higher efficiency and reduce the likelihood that a cartel can unjustly have an operator removed.

One possible way to implement this would be to map efficiency directly onto a support category that is valued at, for example, 20%, where 70% efficiency is rewarded by the full 20% support and 0% efficiency does not receive any support.

I believe objective criteria are necessary in order to make this process fair and effective. Otherwise, unpopular ANOs may be dismissed unfairly and popular ANOs may might not be penalised for dropping efficiency without due cause.
 
Last edited:
Thank you for pulling this together.

Like Alex I too have previously suggested that this process should be as objective as we can make it.

There are different ways of doing this and Alex's suggestion is a good one. I think that as a minimum we should find a way of correlating and scoring what an ANO has committed to through their application (initial pledges) and their ongoing (quarterly) reports against these. We can do much the same with New Applicants.

In fact linking this doc to those quarterly updates would be good and should possibly be the desired frequency of objectively evaluating ANOs. The fact that these are not synchronized means that such updates and the community evaluations will be reasonably spread across time.

Without an approach like this, the effectiveness of the proposed mechanisms risks becoming diluted or simply too political, something I believe we cannot afford.
 
Some comments at a tactical level:

Para 2.11 describes how an ANO can be elected even if no ANO spot is available and the added note states:
" This does not apply if the Authority Set is at its temporary maximum limit of 32 ANOs." I'd like to suggest that the current temporary maximum limit is just that, temporary, and that to give this doc some longevity we consider the maximum limit as being defined by the community so that we have way of defining and maintaining this limit.
 
I'd like to reiterate that various stats and links will be included in the ANO Dashboard next to each ANO. For example, we aim to include each ANOs current efficiency and link to their respective Contributions area. I believe we'll be able to show what percentage of governance votes an ANO has taken part in as well. As other important stats are determined and it's viable to add them, we'll do so.

If/when efficiency requirements are added, then those requirements can become a part of this system. In my opinion, this thread isn't the place to determine those requirements but I welcome people to start such threads so that debate can begin. If people feel so strongly about it, start that thread ASAP so that by the time this system goes live, the efficiency standard is implemented since we had sufficient lead time.

We want this system to provide as much information to Standing Parties as possible. As standards are determined for various criteria, we will implement them so the process becomes more and more objective.
 
Some comments at a tactical level:

Para 2.11 describes how an ANO can be elected even if no ANO spot is available and the added note states:
" This does not apply if the Authority Set is at its temporary maximum limit of 32 ANOs." I'd like to suggest that the current temporary maximum limit is just that, temporary, and that to give this doc some longevity we consider the maximum limit as being defined by the community so that we have way of defining and maintaining this limit.
Thank you for this input.

I'm actually having a hard time to figure out a good solution to this. Currently the guides decides if there should be opened up new ANO spots or not, and we have only informally set a "temporary maximum size of 32 ANOs" due to the fact that we don't have a solution to move from 2 to 1 Authority server per ANO.

If we formalize the above decision ("hard limit") into a document this means that the cap can not be raised higher than 32 without a 4/5 guide and 3/5 ANO approval of that document.

Personally I think a sufficienct solution would be to:

1) For now change the note in this document to just limit its use to when there are less than 33 ANO's (then this process can be amended later by just removing that single note if required).

2) When amending Doc 001, add a paragraph that states that the final number of Authority Servers shall be 65, and that these shall be operated by 65 ANO's, and stating (high level) that the Guides will be responsible for opening new ANO positions to work towards this goal, based on factors like FCT-price, network metrics, protocol usage and growth etc

3) I think that we could amend the "ratification matrix" in Doc 001, approving Guides to update the section of Doc 001 that describes the number of available ANO positions with a 4/5th majority. I.e when the guides determine the number of ANO's (or one is added via the 90%-rule) they can amend this number in doc 001 without requiring a full ratification of the document. When this change is put into the document the standing system can be updated on the protocol forum based on this.

I'm open for other views on this as well and am happily accepting any other suggestions on the matter!
 
I would also like to add to this thread that IMO this should be an iterative process. TBH given all the different opinions we really cannot make it work for everybody and the more we add the more contention it could possibly bring. I get that some might not like every single bit of it, but what is written down right now is pretty close and certainly in the spirit of our governance document, which is something I do hope all ANOs have read and agreed upon.
 
Thank you for this input.

I'm actually having a hard time to figure out a good solution to this. Currently the guides decides if there should be opened up new ANO spots or not, and we have only informally set a "temporary maximum size of 32 ANOs" due to the fact that we don't have a solution to move from 2 to 1 Authority server per ANO.

If we formalize the above decision ("hard limit") into a document this means that the cap can not be raised higher than 32 without a 4/5 guide and 3/5 ANO approval of that document.

Personally I think a sufficienct solution would be to:

1) For now change the note in this document to just limit its use to when there are less than 33 ANO's (then this process can be amended later by just removing that single note if required).

2) When amending Doc 001, add a paragraph that states that the final number of Authority Servers shall be 65, and that these shall be operated by 65 ANO's, and stating (high level) that the Guides will be responsible for opening new ANO positions to work towards this goal, based on factors like FCT-price, network metrics, protocol usage and growth etc

3) I think that we could amend the "ratification matrix" in Doc 001, approving Guides to update the section of Doc 001 that describes the number of available ANO positions with a 4/5th majority. I.e when the guides determine the number of ANO's (or one is added via the 90%-rule) they can amend this number in doc 001 without requiring a full ratification of the document. When this change is put into the document the standing system can be updated on the protocol forum based on this.

I'm open for other views on this as well and am happily accepting any other suggestions on the matter!
Hi Tor, Thank you for a considered response to my question. I had not realised how complex it could be to create a solution but I am glad that we recognize the potential issue. I do not disagree with your suggestion but if anyone has a better/more elegant solution then it would be good to hear it.
 
I would also like to add to this thread that IMO this should be an iterative process. TBH given all the different opinions we really cannot make it work for everybody and the more we add the more contention it could possibly bring. I get that some might not like every single bit of it, but what is written down right now is pretty close and certainly in the spirit of our governance document, which is something I do hope all ANOs have read and agreed upon.
Hi Niels, like you I think that this, like a lot of parts of Factom governance should be an iterative process. It can only get better with careful scrutiny, understanding and support for the difficult and often novel challenges the protocol face. I also totally applaud consistency with our base governance document(s). I am sure you do not mean to stifle discussion and debate on this issue. Added complexity to try to make it work for everyone is not the objective, quite the opposite; we prefer simplicity.
 
No I am certainly not stifling discussion. I think everybody should know by now that I value discussion. There is a reason why we have seen multiple iterations of the current document and a pre-discussion.

But what I do see happening quite often is that people propose something. Or already have done a lot of work and then people come in, quite often shooting something down rather vocally/opinionated, without actually providing solutions and setting the tone for a thread/discussion. Of course there are others providing more nuanced reactions and possible solutions. Problem is that we really get nothing done if people do not accept that we cannot really get this all encompassing solution in one go with so many cooks in the kitchen.

We simply have to accept with so many opinions that not every single person/entity will support changes if we want to move forward and that doing it in a iterative process to both get minds, tech and need aligned is the way forward.
 
I’d like to reiterate my appreciation for the effort applied to get this challenging aspect of governance progressed.

It is an important and significant piece of governance which serves to remind me how fortunate the community is to have the power and the privilege to decide such fundamental aspects of how the protocol works.

With such power comes responsibility.

We need to make good timely decisions and enact them if we are to be recognized and valued as the Internet Integrity Layer that we aim to be.

Therefore I support the current objective to get this Doc ratified so that it establishes the principle that ANOs will be assessed/ranked by the community, a community charged with ensuring we each perform as we have committed. I encourage other ANOs to make their assessment of this proposal to ensure they are comfortable with this significant piece of governance.

I believe there is support for making this assessment as objective as possible. To build this mechanism into the current doc will probably over-complicate, take time to revise, debate and agree. Therefore my only proviso is that there is a clear reference to setting up objective criteria (and acknowledging/ correcting the detailed issues already identified).

I am happy as a member of this community to play my part in improving the objectivity of ANO assessment.
 
I have added the following as 1.2 in the document:

Objective measures will be designed and implemented by Standing Parties. They will account for a percentage of ANO Standing and will be defined in supplementary documents.
The first objective measure we'll tackle is efficiency. If anyone would like to be a part of that draft process prior to presenting it to the community, please contact me privately.
 
Last edited:
I have added the following as 1.2 in the document:

Objective measures will be designed and implemented by Standing Parties. They will account for a percentage of ANO Standing and will be defined in supplementary documents.
I have amended this slightly in the document, so the proposed text now reads:

Objective measures will be designed and approved by Standing Parties and then implemented via an amendment to Doc 001 ("Factom Governance Document"). When implemented, they will account for a percentage of ANO standing.
Note: The system described and implemented via this document is not contingent on objective criteria being added.
The reason for the amendment is two-fold:
1) It now describes that the objective measures are to be included in Doc 001 where they belong.
2) Making clear that the system will be implemented as described in this document even without objective criteria being ready at the time of launch. This removes any ambiguity, and ensures that the implementation of the system is not held up if the standing parties are unable to agree on objective terms prior to the system going online.
 
TRGG3R, LLC. will be voting in favor of this ratification. In addition to the incorporation of accountability for the Authority Node Operators, this will also allow for ANOs to gather information into where their support level exists and whether or not to take measures to improve. As we continue developing this protocol further, it will be important for us to identify organic and dynamic measures through which the onboarding/demoting of ANOs can take place. This document is the first step in bringing that process to light and has my full support.
 
This is a minor point, but I don't think 14 days is reasonable for new ANOs. We want ANOs who will operate quality equipment in quality data centers and there is no way we should expect them to preorder equipment and sign a long-term lease before the selection is complete. Temporarily spinning up on AWS is a possibility but the only reason being just so you can get up in 14 days? (We proposed this when our second data center was delayed but Brian believed it to be a waste of time). I think that would be a waste of resources just to save time with no quantifiable outcome. I'm fine with 14 days as a goal but not the limit.

I think we should (at least) define what percentage the objective metrics will count for. In general, I don't like the subjective nature of this process, especially because most of what we do is public. I know we're all big boys and girls but the notion that how one votes in the grant round won't affect any opinions is unrealistic. My solution would be to make voting private or the ANO removal mostly objective metrics.
 
I think we should (at least) define what percentage the objective metrics will count for. In general, I don't like the subjective nature of this process, especially because most of what we do is public. I know we're all big boys and girls but the notion that how one votes in the grant round won't affect any opinions is unrealistic. My solution would be to make voting private or the ANO removal mostly objective metrics.
The goal is 100% objective criteria so that this eventually becomes a fully automated process on chain. @Mike Buckingham @Alex @Tor Paulsen and myself have begun talking how to first implement efficiency and will present that as a proposal to the community. Mike started a big list of additional objective criteria we can employ in the future and we're starting to debate those and think of new criteria to add to the list. A couple shouldn't be too hard with current infrastructure, some just plain won't work, others will need infrastructure in place in the future before they become viable.

It's why I continue to reiterate that this needs to be an iterative process as determining, getting consensus, designing, developing, and deploying each of these objective criteria will take some work.
 
This is a minor point, but I don't think 14 days is reasonable for new ANOs. We want ANOs who will operate quality equipment in quality data centers and there is no way we should expect them to preorder equipment and sign a long-term lease before the selection is complete. Temporarily spinning up on AWS is a possibility but the only reason being just so you can get up in 14 days? (We proposed this when our second data center was delayed but Brian believed it to be a waste of time). I think that would be a waste of resources just to save time with no quantifiable outcome. I'm fine with 14 days as a goal but not the limit.
Thanks for the input @Nate Miller. As this is the second comment regarding this we've decided to amend the expectations from 14 to 28 days for completing the necessary steps to be onboarded.
 
As a general comment, the opinions below are mine alone and do not necessarily reflect the ANO Kompendium

2.1 The protocol forum will host a public ANO Standing Dashboard that is permanently visible to all parties and displaying real-time Standing levels…

What is the value of having this dashboard public vice internal to the ANO community or only those with standing? Other than as pressuring mechanism–I don’t immediately recognize the benefit. I’m also having a hard time of trying to understand the utility and practicality of “real-time standing levels” given the expectation ANOs might only cast judgments every two months? Regarding "real-time standing", please see comments below on 2.3 and 4.2.

2.1 The system will start with all Standing Parties with “Blank Vote” but will be expected to make that vote within two months

I personally would be far more interested in a system where once a standing level dropped to a certain level (let’s say 20%) a timed vote (3-5 days?) would be called where all ANO vote whether an ANO of low standing be put on probation, and if sufficient corrective action isn’t achieved within a certain time frame (90 days?) the ANO would go through the standard process to be removed by a supermajority vote (maybe 80%?). The process would work the same for aspiring ANOs: if a support level climbed to a sufficiently high amount (75-90%?) for more than xx days (30?), a timed vote (5 days) would occur where the aspiring ANO would be publicly interviewed and have their pledges, credentials, and infrastructure reexamined. At the end of the five-day interview, all ANOs would be required to cast a vote; a supermajority (75-90%) should be required for admission to the ANO set (which should be achievable if the aspiring ANO achieved a high pledge support level before the vote).

2.2 If an ANO drops below 40% Standing on the ANO Standing Dashboard, they are immediately notified and have 90 days to improve and rise above 40%.

In my opinion, this percentage is too high. With so few ANO and members with standing I feel we need a larger percentage opposing the continuation of an ANO (remember this successfully campaigned for an ANO spot). I propose a number closer to 20% or 25%. A great example is the recent multicoin discussion where I’m guessing a group comprising a less than 40% of ANO supported keeping multicoin in the authority set and prevailed in doing so, I feel rightly for the benefit of the protocol.

2.1 If they move back above 40% during the 90-day period and drop down again thereafter, they once again have 90 days to improve.

If continual voting remains and this language remains, we may want to add some qualifier such as ”If they move back above ##% during the 90-day period for ## days…”

2.3. Standing Parties can update their Standing for ANOs at any time

In my opinion, identifying a specific day where the system will take THE measure of community standing is more desirable and will provide more actionable information for the community and standing parties. We should adopt a specific day/time per month/week where official standing is measured for all ANO. See below request for 4.2.


2.4 All current ANOs will automatically be listed on the election dashboard where Standing Parties can choose to “Support” or “Not Support”

Is there going to be a justification/validation requirement to casting “Not Support” votes? For example, if we choose “not support” for an ANO, are we required to justify our non-support? I believe such a requirement should exist. All “non-support” votes should be treated as a change from community approval (given they have already successfully campaigned for an ANO spot) and should be justified with a justification statement changeable by any and all with standing to ensure standing is not abused. Votes should be more than feelings of ANOs – otherwise, they could be biased, or based on ignorance of contributions/ANO activity.


2.5 The moment an ANO is demoted, if a candidate ANO has 60% or higher Standing, the Candidate becomes an ANO.

I recommend that we move this number to 75% or even 90% (see previous 2.1 comment). Also, if this high support level is attained, I don’t believe they should automatically become ANO, but instead, a time-limited election period should be held where those with standing can focus on the prospective ANO, ask questions, review achievements, application, and at the end of the 5-day period, a vote will be held; prospective ANOs should require a supermajority for admittance to the Authority Set (which should be obtainable given the achieved 75%-90% favorable standing rating required to trigger an election vote).

2.8 I feel like this is something that the community should also need to approve. I also strongly support employing a standing tiered model such as: admittance of additional ANO # to 32 occurs only after FCT price is greater than $15 for more than 90 days, admittance of ANOs 33-45 only after FCT price is greater than $30 for 90 days, admittance of ANOs 46-60 only after FCT price is greater than $45 for 90 days, admittance of ANOs 61-65 only after FCT price is greater than $60 for $90 days. These price-tiered admittance bands guarantee responsible ANO growth and ensure we will be able to maintain the sustainable health of the community grant pool beyond the 32 ANO level. Our race to 65 is self-imposed and racing to it independent of market conditions and protocol state achieves nothings if it compromises our ability to fund the long-term improvement of the protocol.

4.1. Promotions and demotions will happen on a continuing basis.

In my opinion, I think we should experiment with continual campaigning, but not continual promotion and demotions - as described in an above previous comment regarding time-limited elections/votes for promotions/demotions.

4.2. Standing parties can and should continuously vote throughout the year to show their support or non-support for both current ANOs and Candidate ANOs.

Can we consider changing “continuously vote” to something more quantitative such as “...should cast a vote for each ANO before the 27th day of each month, where on that day, each ANO’s standing will be measured”?

Thanks
 
In my opinion, this percentage is too high. With so few ANO and members with standing I feel we need a larger percentage opposing the continuation of an ANO (remember this successfully campaigned for an ANO spot). I propose a number closer to 20% or 25%. A great example is the recent multicoin discussion where I’m guessing a group comprising a less than 40% of ANO supported keeping multicoin in the authority set and prevailed in doing so, I feel rightly for the benefit of the protocol.
I believe the percentage is just right if we can ensure that objective measures account for some small yet significant share of standing. For example, if I can get 15% standing just by fulfilling objective criteria, then a much greater percentage of ANOs need to remove support before I am removed from the protocol.

Votes should be more than feelings of ANOs – otherwise, they could be biased, or based on ignorance of contributions/ANO activity.
Again, objective measures should be able to counter votes that are completely unjust. Trying to police the cause of negative votes will be a complete waste of time.
 
Thank you @Jason Gregoire for taking the time to properly review and provide feedback to the suggested document.


2.1 The protocol forum will host a public ANO Standing Dashboard that is permanently visible to all parties and displaying real-time Standing levels…

What is the value of having this dashboard public vice internal to the ANO community or only those with standing? Other than as pressuring mechanism–I don’t immediately recognize the benefit.
- Public means that there are transparency also for the wider community. They can see who votes how and also question people's stance. For example if a standing party continues to support an ANO which are heavily underperforming (in their eyes) they may publicly ask this standing party about their stance. In the future we also want to expand standing to stakers and protocol users, so it is natural to make it public now as that is the future intent anyways. In addition the intention is to move standing on chain and then it will be public nevertheless.

2.1 The system will start with all Standing Parties with “Blank Vote” but will be expected to make that vote within two months

I personally would be far more interested in a system where once a standing level dropped to a certain level (let’s say 20%) a timed vote (3-5 days?) would be called where all ANO vote whether an ANO of low standing be put on probation, and if sufficient corrective action isn’t achieved within a certain time frame (90 days?) the ANO would go through the standard process to be removed by a supermajority vote (maybe 80%?). The process would work the same for aspiring ANOs: if a support level climbed to a sufficiently high amount (75-90%?) for more than xx days (30?), a timed vote (5 days) would occur where the aspiring ANO would be publicly interviewed and have their pledges, credentials, and infrastructure reexamined. At the end of the five-day interview, all ANOs would be required to cast a vote; a supermajority (75-90%) should be required for admission to the ANO set (which should be achievable if the aspiring ANO achieved a high pledge support level before the vote).
This adds, in my eyes, unnecessary overhead and a lot of excessive work for all parties. The guide role is intended to diminish over time, and organizing and attending time-specific and critical votes is a step in the wrong direction. Also we intend to add more standing parties which then would have to attend a vote at a specific time which I believe is unrealistic. You would also end up with situations where the process happening during holidays, etc. which would imply lower attendance.

The intention of this system is to have the standing parties to decide which entities are included or kept in the authority set using their standing and vote - and that is achieved by the devised system.


2.2 If an ANO drops below 40% Standing on the ANO Standing Dashboard, they are immediately notified and have 90 days to improve and rise above 40%.

In my opinion, this percentage is too high. With so few ANO and members with standing I feel we need a larger percentage opposing the continuation of an ANO (remember this successfully campaigned for an ANO spot). I propose a number closer to 20% or 25%. A great example is the recent multicoin discussion where I’m guessing a group comprising a less than 40% of ANO supported keeping multicoin in the authority set and prevailed in doing so, I feel rightly for the benefit of the protocol.
I believe 60% is a good choice for removal as this is a number that is engrained in our other processes as well, and its also the minimum support required to become an ANO. Keep in mind that when an ANO is elected they have 60% support, and they have to fall all the way below 40% to be put on notice and subsequently removed.

There is also a group looking in to adding a base amount of support ANOs get from objective criteria and this will offset the number quite a bit (If you have a base support of say 20% from objective criteria) you'll have to drop below 20% support (i.e 80% of the community does not support you), and this will get you in the 75-80% ballpark.

Personally I think that if 60% of the community disagreed with me being a Guide I would step down - and this also should go for ANO's in my opinion.... The ANOs are incentivized to keep a healthy authority set as it is the basis of their own income - and since we designed this to not be a game of musical chairs I think we won't see many ANOs get removed if they are not deserving it.


2.1 If they move back above 40% during the 90-day period and drop down again thereafter, they once again have 90 days to improve.

If continual voting remains and this language remains, we may want to add some qualifier such as ”If they move back above ##% during the 90-day period for ## days…”
I think we might want to add some kind of time period here to protect against "finger troubles"; i.e that an ANO might click the wrong button by accident taking an ANO one the limit for only seconds or minutes before switching it back again. I'll let @David Chapman chime in, as Factomize will be building the actual implementation and might have ideas around this.

2.3. Standing Parties can update their Standing for ANOs at any time

In my opinion, identifying a specific day where the system will take THE measure of community standing is more desirable and will provide more actionable information for the community and standing parties. We should adopt a specific day/time per month/week where official standing is measured for all ANO. See below request for 4.2.
I don't think it will provide "more actionable information" to have it happen at a specific time/day. An ANO has standing, and in my opinion they should be able to use this standing at any time. Also the information would be available to the admins of the site even if the dashboard was coded to be updated only once per week/month; and when we move it on chain the information will also be available the second the standing parties make the entry with the standing amendment. I also think we'd see situations where an standing party decides to not support an ANO due to them being unavailable during a stall etc, and then flagging this on discord in the forum ("We will be removing our support(....)".... Much better if they just update the standing when they want and the dashboard gets updated.


2.4 All current ANOs will automatically be listed on the election dashboard where Standing Parties can choose to “Support” or “Not Support”

Is there going to be a justification/validation requirement to casting “Not Support” votes? For example, if we choose “not support” for an ANO, are we required to justify our non-support? I believe such a requirement should exist. All “non-support” votes should be treated as a change from community approval (given they have already successfully campaigned for an ANO spot) and should be justified with a justification statement changeable by any and all with standing to ensure standing is not abused. Votes should be more than feelings of ANOs – otherwise, they could be biased, or based on ignorance of contributions/ANO activity.
I believe we decided that there will be a form to fill out to describe why the standing party changes their vote yes. It cannot be a formal requirement ("shall") but must be a "should"; as there is no way to actually enforce this. You can't invalidate a vote if they refuse to write anything, but with only guides/ANOs in the mix it would affect their own public standing (if I consistently did it as a Guide someone could motion to have me removed, or not re-elected).

2.5 The moment an ANO is demoted, if a candidate ANO has 60% or higher Standing, the Candidate becomes an ANO.

I recommend that we move this number to 75% or even 90% (see previous 2.1 comment). Also, if this high support level is attained, I don’t believe they should automatically become ANO, but instead, a time-limited election period should be held where those with standing can focus on the prospective ANO, ask questions, review achievements, application, and at the end of the 5-day period, a vote will be held; prospective ANOs should require a supermajority for admittance to the Authority Set (which should be obtainable given the achieved 75%-90% favorable standing rating required to trigger an election vote).
They will only be elected an ANO if there are open spots. If there are not, they can still be elected ANO with 90% support (very high bar, intended to be used if a company/organization of great importance wants to become an ANO and we don't want to wait for the next date for determinating the size of the authority set (every 6 months).

Standing parties will of course not provide applicants with support "lightly", and if they are able to accrue 60% standing I believe they should be elected an ANO. They will not get this support lightly, and if they are able to secure it I believe they have earned their spot. I'm opposing a vote here for the same reasons I mentioned above; it adds overhead, the timing might be bad (holidays etc), and also when we expand the authority set we can't expect stakers/users to "vote again" for the same team they have already decided to support. Also long term we want to move to the on-chain solution where standing is signaled by support/not support, and having additional on-chain votes complicates the entire process.


2.8 I feel like this is something that the community should also need to approve. I also strongly support employing a standing tiered model such as: admittance of additional ANO # to 32 occurs only after FCT price is greater than $15 for more than 90 days, admittance of ANOs 33-45 only after FCT price is greater than $30 for 90 days, admittance of ANOs 46-60 only after FCT price is greater than $45 for 90 days, admittance of ANOs 61-65 only after FCT price is greater than $60 for $90 days. These price-tiered admittance bands guarantee responsible ANO growth and ensure we will be able to maintain the sustainable health of the community grant pool beyond the 32 ANO level. Our race to 65 is self-imposed and racing to it independent of market conditions and protocol state achieves nothings if it compromises our ability to fund the long-term improvement of the protocol.
We are not racing to 65 right now - at all. I'm not foreseeing any spots opening up before the price is well stabilized at $10 or above.

I do agree with you that we should have some metrics defined, but they should go in Doc 001. I suggest we bring that point up when drafting v.1.6 of that document. @Nolan Bauer do you mind? :)

4.1. Promotions and demotions will happen on a continuing basis.

In my opinion, I think we should experiment with continual campaigning, but not continual promotion and demotions - as described in an above previous comment regarding time-limited elections/votes for promotions/demotions.
I respectfully disagree. It adds overhead and complexity and opens up for gaming to a larger extent as people are incentivized to change their votes just prior to an election to remove someone without them being able to do anything about it over time. With continuous elections the changes in support will be more gradual and the ANOs in question may act on this at an earlier time.

4.2. Standing parties can and should continuously vote throughout the year to show their support or non-support for both current ANOs and Candidate ANOs.

Can we consider changing “continuously vote” to something more quantitative such as “...should cast a vote for each ANO before the 27th day of each month, where on that day, each ANO’s standing will be measured”?
Ref. my comments previously I don't believe this is a good solution. With the "every 2 months" option we ensure that teams ought to update their standing prior to an ANO "on notice" being removed, and they are more free to do it at a time that fits their calendar. Also if an ANO does something they disagree with they are able to use their standing immediately do voice their opinion.

----

I am sure that this system will require some tweaking when we gain more experience with it, and some of the ideas brought up might turn out to be necessary to balance the system.

At this stage I think the process as drafted in this document is the way to go, and I won't be making any amendments at this stage apart from the two items I tagged Nolan and Chapman for.

Thank you again for taking the time to provide your thoughts, and I hope you continue to do so during the creation of objective determinable criteria and subsequent improvements to this document if it passes ratification.
 
Status
Not open for further replies.
Top