GRANT SOLUTION - WIDELY DISTRIBUTED ON-CHAIN VOTING AND 0% EFFICIENCY

OVERVIEW
The grant process as outlined by the Governance doc (Section 4) lacks the current infrastructure to execute the Governance document’s vision. Additionally, there are concerns from both Guides and Authority Set members regarding liability issues due to lack of legal clarity as well as centralization.

PRIMARY GOAL
As we await legal clarity on Decentralized Organizations and also the build-out of the Grant infrastructure per the Governance document, create a temporary grant process solution that does not unduly legally expose any standing party. Additionally, keep development of the Factom protocol moving forward. The below is just one potential solution. The Guides are not endorsing any presented potential solutions. Additionally, please suggest any solutions not already listed in the Factomize forum.

GRANT SOLUTION - WIDELY DISTRIBUTED ON-CHAIN VOTING AND 0% EFFICIENCY
  • All current and future Authority Set operators take 0% efficiency during their first two months of operation.
    • The community will socially hold each operator responsible in regards to delivering on campaign promises and helping build the protocol
  • During this time, several community members will develop a voting/election/digital signature solution
    • This process was already started in March, so we can potentially use this as a jumping off point if we would like
    • A realistic timeline for completion of this project would be 4-6 weeks
    • We already need this solution to make elections a simple process
    • It will be socially agreed upon that developers will be reimbursed in the future
  • Once the project is completed, we will have the tools in place to initiate a widely distributed voting/grant signing process, thus making the the protocol more decentralized
    • Guides will no longer need to digitally sign off on grants
    • After a vote, Factom Inc will have the digital signatures they need to execute objectives on their end from a development/coding standpoint
    • The initial grants from the Governance will be approved and digitally signed by a widely distributed audience.
    • Factom Inc will be able to start development of initial grants immediately and will be able to reach full scale initial grant development in approximately 6 weeks
  • The onchain voting tool will provide us with several options of achieving a widely distributed grant vote as well as digital signing. Potential solutions include but are not limited to:
    • All current Factom Wallets with >0 FCT get 1 vote assigned to the owner
      1. Yes, some people have more than one wallet, this acts similar to a PoS model
    • All current Factom Wallets with >100 FCT get 1 vote assigned to the owner
      1. Ensures people voting have more “skin in the game”
    • Discord community voting
      1. Everyone at “X” date in past has a vote
      2. Everyone with over “y” comments by “z” date in past has a vote
    • The Civic blockchain has an API that we can use to not only validate identities, but also record results on a chain via signature
      1. Note: The API has not been vetted by anyone in the Factom community yet
      2. The cost is $1.50 per identity for the basic package
    • ***Please keep in mind this is not a long-term solution. This is simply a process to fund the “Initial Grants.” The initial grants should have an extremely high approval rate. After Initial Grants, we will sunset this process
 

ThinlySlicedMeat

Block Party
Thanks for all the work on this, @MattO . Some really solid ideas here.

Quick question - is there a specific reason why efficiency has to be set at 0% for the first couple months with this solution? Couldn't we just keep efficiency as pledged and let those resources accrue in the grant pool while we figure out the voting mechanism?
 
Quick question - is there a specific reason why efficiency has to be set at 0% for the first couple months with this solution? Couldn't we just keep efficiency as pledged and let those resources accrue in the grant pool while we figure out the voting mechanism?
Yep, we could. That's how a few of the other Grant Solution Proposals would work (I probably didn't make that clear enough in them, sorry). The 0% efficiency option was proposed simply because it allows parties to begin developing/promoting the protocol immediately. 0% efficiency is simply a grant pool work around (it's obviously not ideal, but the community had talked about it enough that I thought it worth including in our options). With 0% efficiency, projects like the election tool could begin to be created. Without the grant pool or 0% efficiency, that project wouldn't be able to get started. That means we wouldn't be able to explore ways to have a much wider voting/signing distribution (among other things).
 

ThinlySlicedMeat

Block Party
0% efficiency is simply a grant pool work around (it's obviously not ideal, but the community had talked about it enough that I thought it worth including in our options). With 0% efficiency, projects like the election tool could begin to be created.
Got it, interesting. So the Auth Set could utilize these additional resources, not only for the election tool, but also for things like setting up the Foundation? If so, we could set an expectation for an amount in dollar terms that each member of the Auth Set is expected to contribute to one of these (or other) projects required to bridge the gap. If we then run those contributions through a traditional crowdfunding mechanism like Kickstarter, we should be free and clear of any potential liability. At least, I think :)

This would all need to be socially enforced of course, but if we said each Auth Set entity should contribute $2,000 per month to these projects, that would be totally reasonable (imo) if efficiency was set at 0%. That would give us ~$45,000 to work with, which could be enough to build the structure to a point where the grant pool can take over.

Anyway, just a thought!
 

Xavier Chen

LayerTech
I like this 0% efficiency as medium term solution in conjunction with the Foundation idea which would be a long term solution.

To meet our immediate short term needs, I suggest we utilize something like a Grant Committee to review and sign off on grant proposals (including initial grants). Since we have 0% efficiency, contribution to approved grant proposals will be funded directly by Operators. Because all of this will be socially enforced, the down side of 0% efficiency is minimal in my opinion. We can even have 0% efficiency for more than two months instead of rushing our long term solution.

For example, let's say it took us 4 months to get up a foundation correctly. And let's say we have our election in 8 months. An operator will work with 0% efficiency for 4 months, then 75% efficiency for remainder 8 months to have an average of 50% efficiency before the election. Based on how long we need to set up the Foundation (or another solution), we can easily make up the difference in later months. If we have a Grant Committee and that same operator gave away factoid equivalent to 10% of its monthly efficiency during that 4 months period, they just subtract the expense and make up the difference by only contributing 70% efficiency for remainder 8 months to reach that average 50% he/she promised. All of this will be socially enforced until we have a better mechanism set up via Foundation or other solution. But I can't imagine Operators take advantage of this situation... won't look too good when it comes to election.
 
As many should be aware, this has by far been my top choice.

A few notes I have one this:

All current and future Authority Set operators take 0% efficiency during their first two months of operation.
I think specifying that all future Authority Set operators should take 0% efficiency for the first 2 months is odd. First it seems unnecessary, and secondly its possible we arrive at a place in the future where the optimal state is for AS hosters to take much lower % of tokens generated (say FCT price increases greatly, we get tons of grant proposals, and AS hosters consolidate into basically just running the network, other dev and promotional work is done through grants). This line in that case could guarantee a huge and unnecessary revenue for the first 2 months to a new operator at that point. We could just put a time limit on this to solve that.

All current Factom Wallets with >0 FCT get 1 vote assigned to the owner
I think we have way too small of a community for this to be safe. Could easily create more wallets with small amount of factoids in them than there are total people in our community.

All current Factom Wallets with >100 FCT get 1 vote assigned to the owner
Still would be worried with this solution. Currently would cost 2k per vote. My OPTIMISTIC guess of number of community members who would vote for grants would be around 100. This means it costs 100k for a majority vote by yourself. Thoughts on this?

Discord community voting
  1. Everyone at “X” date in past has a vote
  2. Everyone with over “y” comments by “z” date in past has a vote
Would guides be the ones to vet this out? If there was a way to do this easily and soundly, this might be the best option for now. Part of the point of guides in the beginning is that automated solutions are hard to build in a way that can't be easily gamed, guides can act as a solution to pretty easily vet these situations out.

Lastly, if we want to pursue using Civic I could look into that more.

To @xavierwjc

To meet our immediate short term needs, I suggest we utilize something like a Grant Committee to review and sign off on grant proposals
Great idea, I'm assuming by "sign off" you mean informally give the operators the social go-ahead (whole point is noone signs off of course)
 
This is my preferred choice. I personally think Efficiency should remain 0 and we do away with the grant pool being on protocol. Then we have Authority Set entities fund grants via a Kickstarter-like Factom entity off-protocol. The primary drawback would be double taxation but I think it removes a substantial amount of complication from a protocol that was supposed to "not do very much".
 
I think there is a real danger of voter apathy with widely distributed voting. We don't have a particularly large community, so unless the usual suspects are willing to assess every application (and there is no direct incentive to do so), then we risk money being given out to unworthy applications.

I like @DChapman's idea of a Kickstarter-like entity off-protocol. Operators can then fund x% of any given proposal, and a leaderboard can show the percentage of an operators total rewards that have been allocated to grants. Anyone who doesn't review proposals and make grants will not hit their efficiency target, and thus get voted out. We therefore have an incentive to review proposals.
 
The widely distributed voting is appealing in theory but I'm a bit concerned that in practice it'll be hard to be sure that the vote is not gamed in its initial version. With the vote by wallet, any whale can split their FCT to multiple addresses for instance. And probably some ways to game the Discord vote too. You have to think and prevent any manipulation before hand, when writing the rules. I'm just saying, it seems pretty hard to design an anonymous voting process to be fair and resistant to attacks quickly. It could probably require as much time to think about it properly than to get the legal advice. So I'm not convinced it is a good short term solution (but if we have time to properly design and implement it, then it is a really cool idea).
 
This sounds like it could get cloudy very quickly. How do we decide that an operator isnt using their funds properly? How much development/support from the operators towards the community is enough? What are the expectations of operators? We dont even have that outlined yet. If we can answer some of these questions, we can avoid some issues down the line. Expectations of the operators should be very clear if we are going to rely 100% on operators to develop the protocol and "do the right thing".
 
This sounds like it could get cloudy very quickly. How do we decide that an operator isnt using their funds properly? How much development/support from the operators towards the community is enough? What are the expectations of operators? We dont even have that outlined yet. If we can answer some of these questions, we can avoid some issues down the line. Expectations of the operators should be very clear if we are going to rely 100% on operators to develop the protocol and "do the right thing".
Good questions @mrroboto. I would add:
  • At 0% efficiency, what would be the incentive of operators to provide funds to non-operator applicants versus funding their own internal development activities?
  • Should there be a requirement that a certain % of available funds go to non-operator grant applicants?
  • Should there be a penalty if operators don't fund any development activities outside of their own internal ones?
There are several grant ideas that were submitted as part of the AS application process for entities that were not selected as node operators.
 
Top