Voting NO on anchor and Oracle master grants

Niels Klomp · Feb 15, 2020

@ANO

I saw several entities voting No on the anchor master grant as well as the Oracle master grant.

I was wondering whether people really have thought through what would have happened if these didn't make it this round. I find it rather worrying that people vote no on the Grants without coming up with an alternative plan or party for the Grants.

I certainly hope that every single ANO takes the stability of ECs as well as the security of the network very seriously.

Kind of interested to hear people's thoughts here.

Matt Osborne · Feb 15, 2020

We are not fans of how Oracle and Anchor have been run, but we 100% agree with Niels. To my knowledge, no one pushed for a backup plan. If you don't like how they are run, then please try to SOLVE the problem due to their critical nature instead of just voting no. Thank you.

Nolan Bauer · Feb 15, 2020

I agree. The stability of the network is dependent on having an anchor mechanism and an oracle to maintain Entry Credit valuation. If we decide to cut those without a viable replacement, we are potentially slitting our own throats. Build an alternative and propose a competitor and now we are talking. If these had passed, we would've been injecting more chaos into an already painfully unpredictable system. We should be governing smartly and not trying to create fires just so we are forced to put them out.

my .02 here

Quintilian · Feb 15, 2020

Reasoning for voting no on principle:
Anchor Master
Oracle Master

No grantee (even factom inc) is above the grant process, and in total they were requested 8 times to provide feedback on their previous Anchor/Oracle grants in their tracking threads (and pinged twice on Discord), without even replying.

I deemed a no support vote appropriate based on the above, but would be happy to fund these as backpay grants (if they did not pass up front) if they provided appropriate reporting and responded to inquires.

Nolan Bauer · Feb 15, 2020

Tor Paulsen said:
Reasoning for voting no on principle:
Anchor Master
Oracle Master

No grantee (even factom inc) is above the grant process, and in total they were requested 8 times to provide feedback on their previous Anchor/Oracle grants in their tracking threads (and pinged twice on Discord), without even replying.

I deemed a no support vote appropriate based on the above, but would be happy to fund these as backpay grants (if they did not pass up front) if they provided appropriate reporting and responded to inquires.

Voting what you think is right in principle is your prerogative. I just think the consequences of not passing an anchor master or oracle master would be severe. If the desired end state is to make it a backpay grant, then perhaps that is the proper way forward and we initiate the governance to do so. The community would still need to approve and "contract" with the entity charged with anchoring and maintaining the oracle prior to any determination of whether or not they should be paid out for their services.

Mitchell Berry · Feb 15, 2020

Is the anchor and oracle opensourced?

Niels Klomp · Feb 15, 2020

@Tor Paulsen I get you are pissed about it. I probably of most people given our company 's lack of updates.

But saying No to two very important functions in the core protocol, without an alternative and just hoping that somebody would still do it as backpay grant is setting a very dangerous precedent IMO.

WB · Feb 15, 2020

Tor has been very clear about his intention to vote no in both the anchor and the oracle grant.

So @Nolan Bauer @Niels Klomp , here's an idea:

You could have addressed this during the actual grant discussion to ask Tor for an alternative or push Factom Inc to answer Tor's concerns so people might be swayed to vote in favor. Especially as fellow guides and especially if you have grant discussion / monitoring in your task list.

I'd say that beats bringing this up after the fact.

Niels Klomp · Feb 15, 2020

True, except unfortunately there wasn't time anymore and seeing multiple parties voting the same, made me address it. Simple as that. Don't try to make this as something on purpose. Let's try to approach things from a perspective of trust instead of the opposite

Keith Pincombe · Feb 15, 2020

Given their importance to the protocol I would presume funding would be found regardless of whether they received a grant or not.

It's kinda pointless to even have voting for grants which are required, maybe Inc could lower their efficiency to cover the costs required?

Unless I'm mistaken the anchor code could be made open source fairly easily, that way we could have multiple ANOs submitting anchors, that would offer further robustness to the blockchain.

There was talk a while ago about the oracle being rewritten to use the PegNet and be powered by PegNet miners. I'm not sure if that is still happening or not?

Niels Klomp · Feb 15, 2020

In principle other parties could execute it, so it is not an automatic checkmark.

I am rather worried several parties voted no. And IMO it would be good to have the insight of these parties and also have them involved in coming up with a solution

Tagging parties to get their insights:
@Nic R @Factomatic
@Kompendium (you abstained as well so it wasn;t counted, still happy to hear your thoughts on the matter)
@DBGrow & @Brian Deery (including you guys, despite the No-mistake on everything, as you could vote No regardless of course)

Nolan Bauer · Feb 15, 2020

@WB

For the record, I do not condone the way Factom Inc. has handled the Anchor Master and Oracle Master grants. The fact they did not respond in one proposal thread and the other ~3hrs prior to close of the discussion period is unacceptable and rightfully opens them to not getting the grant approved. Couple that with the clear lack of communication in the tracking thread, Tor is justified in his reasoning. I am merely highlighting the severity of pressing forward without an Anchor Master or Oracle Master.

Keith Pincombe · Feb 15, 2020

I think its good to be worried. It's an indicator that something needs to change but I feel we need to talk about the problem and not shoot the messengers

Samuel Vanderwaal · Feb 21, 2020

Realistically, what happens if the Anchor Master grant is not funded?

Realistically, what happens if the Oracle Master grant is not funded?

Valentin Ganev · Feb 21, 2020

I find the premise that the protocol would untangle if those grants were not approved far fetched tbh. The security of the protocol and the stability of the EC price is not at risk if those grants are not approved, it's at risk if no one is willing to pay for the tx fees (not to mention that the centralized nature of the anchor master is a far bigger security concern than finding the money to pay for the fees). I would happily contribute towards the fees out of pocket, should one of these grants not be approved in the future.

To answer the original question, we did not approve those grants for the reasons outlined by Tor above. We find it unacceptable that there is no reporting, despite a myriad of requests to provide those. We will continue with this no approval policy in the future.

Niels Klomp · Feb 21, 2020

Interesting people feel so lightly about what are governance grants defined in Doc 001. Interesting that core features of Factom are being shoved under the rug without getting a backup plan because people want the reporting.

Tell me what do I tell governments and enterprises of we favor that above governance, price stability and and security. I do hope people take into account some entities in this system are working on large projects and clients.

Niels Klomp · Feb 21, 2020

Failure of governance that would be my classification of it.

And don't get me wrong. I am in no way condoning or looking away from the reporting issue. I have issue with people simply voting no without a plan firstm

Niels Klomp · Feb 21, 2020

4.4. Ongoing Governance Grants
The protocol needs to support a number of activities to maintain the
protocol in an ongoing fashion. These grants to maintain ongoing
operations of the protocol take precedence over other grants which
improve the protocol.

Niels Klomp · Feb 21, 2020

Each grant application requires two separate voting
actions, an Approve/Disapprove vote and a rank-based
vote, except for the governance-defined grants (Guide
pay, Anchor, and Oracle) which will only have an
Approve/Disapprove vote if there is no competing
grants.

So the only option was to abstain....

Schalk Bower · Feb 21, 2020

TLDR: We will develop a backup anchorer.

I believe I have a solution. RewardChain would like to commit to open sourcing and completing our anchor auditing bot as well as extend it’s functionality to automatically anchor into both Bitcoin and Ethereum when it picks up on missed anchors.

This project will be completely self-funded by us, however in the event that the Factom anchor grant doesn’t get approved. We will automatically pick up the slack and take over the anchoring. In that case we would apply for a back-pay grant to cover the transactions fees associated with the anchoring.

I’ll be able to provide an estimate of completion next week. However I can say now, we will prioritize this development effort over our other project.

Valentin Ganev · Feb 21, 2020

(Paragraph 4.8.2.2 from Doc 107)
Each grant application requires two separate voting actions, an Approve/Disapprove vote and a rank-based vote, except for the governance-defined grants (Guide pay, Anchor, and Oracle) which will only have an Approve/Disapprove vote if there is no competing grants. The Approve/Disapprove vote marks whether the standing party believes the grant meets the threshold for eligibility for the grant round.

Niels Klomp said:
So the only option was to abstain....

Niels, I do not agree with your interpretation of the above.

The text says that the governance-defined grants will not be ranked in case there are no competing grants. Indeed, there were no competing grants and those grants could be not ranked on Factomize (they were fixed at the top).

The text also says that the governance-defined grants will only have an Approve/Disapprove option in case of no competition. That's what they had and some entities chose to not approve them for the reasons outlined above. It is the right of Standing Parties to approve or disapprove any grant, including the ones defined in governance, as any Standing Party may believe the grant does not meet the threshold for eligibility for the grant round (as per Doc 107).

If we believe that those grants should always get a free pass, an amendment to our governance documents should be suggested and brought up for ratification.

Niels Klomp · Feb 21, 2020

@Valentin Ganev That interpretation can work. But what about the Doc001 and what about being able to trust the standing parties to uphold the stable price and anchors no matter what?

You want a trustworthy party when making a decission to go with a protocol. Yes the discussion about providing updates is good. Yes choosing another approach when it doesn't happen is good. No potentially just trusting it will work itself out when the majority would have voted no, or acting like it is not that important is not my definition of a party I can trust when choosing for Factom.

As I said before in other occasions, I do hope people sometimes take the perspective of large entities when looking at the protocol and governance as a whole.

Keith Pincombe · Feb 21, 2020

The Anchor and Oracle issue has been ignored for too long. It's important that the protocol is able to function regardless of the outcome of any grant. The non-funding of a grant can be devastating to the community but it shouldn't affect the function of the blockchain.

The focus should be to solve the root problem (Anchors and Oracle) and not alter governance or the grant process.

Valentin Ganev · Feb 21, 2020

I understand your concern, Niels and I assure you we did not take this decision lightly. We're well aware of the importance of having anchoring and an oracle for determining the EC price.

Where we seem to have a difference of opinion is in the consequences of this vote, should those grants have not been approved. I am not convinced that it would have been an issue that jeopardises the security or the stability of the network, as we're a decentralised ecosystem after all, and as mentioned above I personally would have had no issue stepping up to cover the txs costs and would have applied for a backpay grant next ground round after providing proper reporting.

To me the much bigger issue is the fact that there is a single entity operating both of these critical components. I don't have nearly enough experience in communicating with large entities who are interested in the protocol, but wouldn't this fact be a bigger hurdle of adoption for them compared to several entities not approving of the grants (and even compared to the grants themselves not being approved)?

Mitchell Berry · Feb 21, 2020

Niels Klomp said:
Interesting that core features of Factom are being shoved under the rug without getting a backup plan.

The backup plan should be opensourcing this software for the numerous parties across the world to step in if something goes wrong. Even if someone were to create an alternative there's little chance of the community funding it over inc, either through backpay development or ongoing support.

Would be quite interested how close it is to the archived anchor code anyway.

Alex · Feb 21, 2020

Mitchell Berry said:
The backup plan should be opensourcing this software for the numerous parties across the world to step in if something goes wrong.

I think the issue is not so much the software, but the private keys needed to make it work.

Schalk Bower · Feb 21, 2020

Alex said:
I think the issue is not so much the software, but the private keys needed to make it work.

For the oracle master, yes. But private keys aren't "necessary" for anchoring right? Useful, but not necessary

Mitchell Berry · Feb 21, 2020

To be frank I don't know much about how the oracle works, though anyone/node can anchor factom blocks into the bitcoin chain, whenever they feel like it. You don't have to ask for permission to do so.

Was under the impression that any auth node could (and should) anchor each block themselves, it's a simple OP_RETURN.

Mitchell Berry · Feb 21, 2020

But private keys aren't "necessary" for anchoring right?

Exactly. It's just weird, when M3 hit bitcoin fees were insane and understand the need to shelter ANO's from that, but now it's not really a problem. There should be far more anchors.

Won't hold my breath for someone to backpay me for writing it up

Might give it go anyway/

Schalk Bower · Feb 21, 2020

Mitchell Berry said:
Exactly. It's just weird, when M3 hit bitcoin fees were insane and understand the need to shelter ANO's from that, but now it's not really a problem. There should be far more anchors.

Won't hold my breath for someone to backpay me for writing it up

Might give it go anyway/

Some quick math based on https://billfodl.com/pages/bitcoinfees $0.44 per transaction.

144 blocks a day, 30 days a month, 0.44 per anchor. That's still roughly 144*30*0.44=$1,900 a month for anchoring into Bitcoin