Grant Round Improvements Discussion

Secured
#1
Hi Everyone,

This is an open thread for discussing improvements to the Grant process. This is not a timed discussion as the standard Major Timed Discussion would end on Christmas Day and I'm not expecting much participation as we get closer to the holidays. Rather this is a place to start the discussion early and gather ideas so that we can hit the ground running hard after the holidays, to be ready for the next Grant Round.

There were a number of issues discovered during the last grant round and a lot of people had suggestions for improvements. I'd like to start by listing some of the issues and gathering input from others on what things we need to fix. I'll update the list as people add thoughts on what issues need to be addressed. From there we can move towards solving the highest priority issues for this next grant round and working on the lower priority ones in subsequent grant rounds.

Grant Process Concerns and Issues
  • FCT versus USD denominated grants
  • The scoring system and the gaming it allows
  • What types of funding are acceptable and what metrics are required
    • E.g. retrospective pay (aka "backpay"), deliverables vs FTE cost estimates
  • To be continued. . .
 
Secured
#2
Regarding Backpay:

*The more open source development, the better
*By disallowing backpay, we are squashing potential development
*By disallowing backpay, we are putting ourselves in a position where we are banking on the developer producing a good product AFTER the grant has been approved. Ideally, the developer would already have something to show prior to grant approval.
*By allowing backpay, we would be creating a situation where a developer who feels strongly about a project can start development ASAP and then apply for a grant later. This means there's more development sooner AND less risk to the protocol/grant pool since their will be a semi-working product by the time the grant round comes up.
*By allowing backpay, the community is reducing its risk while also accelerating development.

*Said another way: Would you rather invest in a company that has no working product and only a white paper to show? Or would you rather invest in a company with a working product?

Backpay needs to be allowed. We just need to build some rules around it.
 
Secured
#3
Can we try and make this simple, by which I mean that everyone applying for a grant needs to make a structured proposal, that can then be scored against. The details of this could be worked out. One of the most important parts is that such a proposal should make a tangible business case.
 
Secured
#4
First suggestion. All Grant applicants give full disclosure of ANO’s that are in anyway affiliated with the Grant. Affiliated ANO’s are not allowed to vote on that particular grant.
Second suggestion. Open up a broader discussion on grant liquidation...and how we as a community at large can help not put any downward selling pressure on the price of FCT during grant distribution.
 
Secured
#5
First suggestion. All Grant applicants give full disclosure of ANO’s that are in anyway affiliated with the Grant. Affiliated ANO’s are not allowed to vote on that particular grant.
100% agree that this is an issue we need to address. I'd add that grant recipients should not be able to vote on their own grant. Too much incentive to stack a grant with 5+ ANOs in order to ensure the grant gets passed.

Second suggestion. Open up a broader discussion on grant liquidation...and how we as a community at large can help not put any downward selling pressure on the price of FCT during grant distribution.
This gets tricky due to legal concerns. Private sales are one thing (an ANO finding and selling to an interested party), but publicly announcing/searching for buyers is something to be avoided due to legality issues (if I am remembering correctly).
 
Secured
#8
This gets tricky due to legal concerns. Private sales are one thing (an ANO finding and selling to an interested party), but publicly announcing/searching for buyers is something to be avoided due to legality issues (if I am remembering correctly).
Yup you are remembering correctly, this can get tricky fast. Honestly, I dont think we should coordinate on selling right now unless we can find a great way to do it.
 
Secured
#9
First suggestion. All Grant applicants give full disclosure of ANO’s that are in anyway affiliated with the Grant. Affiliated ANO’s are not allowed to vote on that particular grant.
I absolutely support where it appears you're heading with this.

I think in some respects, it needs to be broadened and we need to define "any affiliation".

For example, I think this should be broadened to affiliation with an ANO, not just their grant. If I own an equity stake in X ANO, I shouldn't be voting on their grants.

I think it should cover Guides as well. If a Guide owns equity in X ANO, they shouldn't be voting on their grants.

As mentioned, "Any Affiliation" needs defined. I'm friendly with some Operators and thus am affiliated with them, but I don't think that should preclude my voting. But if I have any sort of financial involvement, it should. I'm sure the community can come up with a good list of variables that would constitute conflicts of interest.

Second suggestion. Open up a broader discussion on grant liquidation...and how we as a community at large can help not put any downward selling pressure on the price of FCT during grant distribution.
Agreed, but not specifically to avoid downward pressure but because the current way we have structured grant payouts is a potential attack vector or at the very least a "bad timing vector". We had some ANOs earn income on huge amounts of FCT they received at around $17 per Factoid. The price then tanked and they have tax liability (at least in the USA) on those FCT at $17.00. If the price were to continue to drop, it could be financially devastating. Payouts and/or grants need to somehow be staggered
 
Last edited:
Secured
#10
First suggestion. All Grant applicants give full disclosure of ANO’s that are in anyway affiliated with the Grant. Affiliated ANO’s are not allowed to vote on that particular grant.
Second suggestion. Open up a broader discussion on grant liquidation...and how we as a community at large can help not put any downward selling pressure on the price of FCT during grant distribution.
I agree with the first suggestion.

As far as the second suggestion goes, I think the most effective way to not incentivize Grant Recipients to sell is to ensure we have a consistent standard for Grant denomination. If we do it in USD fine, but if it's in FCT we have to accept that there will be price variation and Grant recipients may win or lose due to that. We can't compensate them extra if the price goes down and we can't expect more from them if the price goes up. If we apply the second but not the first then Grant recipients will be incentivized to sell as soon as they receive Grant funding as they will be expected to perform based on that exact amount regardless of where the price goes in the near and distant future. Having most of the Grant pool dumped on the market every three months could be disastrous. We want people holding onto FCT long term so we need to allow people to take the risk and receive the reward that comes with doing so.

In addition, David's suggestion of staggered grants should be easily achievable technically, as long as some Grant recipients are willing to receive payment at a later date. We can code in whatever block numbers we want for each grant payout.
 
Secured
#11
In addition, David's suggestion of staggered grants should be easily achievable technically, as long as some Grant recipients are willing to receive payment at a later date. We can code in whatever block numbers we want for each grant payout.
I'd suggest we not give them a choice. Break up payouts over X duration (my initial thought is 3 months). If I receive a grant, I get 1/3 at block X, 1/3 at block Y, and 1/3 at block Z. This also lets ANOs block a payout if a recipient for whatever reason is obviously not going to deliver.
 
Secured
#12
I think there were a few problems with how the first grants were handled right now that I would like to see discussed and fixed before the next grant application.

Voting scores

1. Should we allow standing parties to do binary 0-100 votes ? Allowing binary vote allow the system to be gamed more easily. If I believe 3 projects are worth close to 60 using a grading system but I do prefer one over the other it makes sense in order to maximize the chance of that project to go through to vote 100 for the project and 0 for the 2 others. Despite the 2 others projects being more useful as a whole for the community.

2. Should we try to implement a more standardized way of voting among standing parties using a grid that would be public in order to have a graded vote instead of people doing binary vote where it should be graded ? It would be nice to do an average of the scores using apples to apples instead of oranges to apples. Someone using a graded system and scoring 100 for a grant should have more weight than someone voting binary.

3. In order to limit gaming of the votes I think it could be wise to remove the top 10-20% of vote and the bottom 10-20% of votes from the final scoring. It is pretty standard in statistic to remove the data in a data set that would be considered at the extreme.

Grant payout

We need to standardize how the grants valuation and pay out is handled.

Grant #1, Factom inc got 90 000 Factoids and said they would not need to liquidate for months. The price tanked over 50% between the grant proposal and the time the grant payout was released and they locked the value of the Factoids at the release of the Factoids.

Grant #1, the Factoids valuation was locked at the pay out

Grant #2, the grants were proposed at 4-5$ per Factoids and the Factoids were released at 12$-17$. The teams needed X factoids at 4.5$ per to meet their obligation. In the end they got the same amount of Factoids but at a much higher USD valuation.

Grant #2, the Factoids valuation was locked at the proposal

Considering everyone is spending in FIAT (USD) and budgeting in FIAT (USD), I think it would make more sense that the grants be denominated in FIAT and the price of the Factoid be locked at the payout time. Now this could mean that at the payout time some grants that were voted to be funded would be unfunded until the next grant round or that some grants which didn't make the cut would then be funded. I think I would be fine with these. We get more done in good times and less in bad times.

I think paying in FCT is not sustainable. In bad times, grantees are going to bail out on the value they were voted in and in good times, they get a nice windfall. Paying in strictly in Factoids and socially enforcing grantees to deliver 100k worth of work when they only got 20k is going to be infeasible.

In order to mitigate the selling pressure we might also want to consider releasing the grants in a more fluid manner just like the inflation is handled. Could this be done every block ?
 
Secured
#15
Could you elaborate a little more than this. The goal of this thread is to have a discussion about how the current grant system could be improved. Just saying that "you don't agree" clogs the thread and doesn't let me understand your position.
Sure thing. One reason for denominating grants in FCT is the additional complexity in coding involved when having to denominate a grant in FIAT. I mention this because I remember Briary Deery and Paul Snow talk about this issue.
Another issue I could see occurring is the grant pool overextending itself and promising more funds than it can accomodate. This would be more likely to result if the FCT price drops sharply following a grant round. Grant round promises grant recipients $100k and FCT price falls 25% and now there is only $75K left in grant pool for distribution for example.
I also think when grants are denominated in FIAT, there is less emphasis placed on FCT value. This aspect is hard to define but I think denominating grants in FCT will ultimately help to boost the value of FCT, even though FIAT denominated grants still are paid out in FCT. FCT value just seems more important when grants are denominated in FCT and not FIAT.
I also don't think it should be a mixture of FIAT and FCT denominated grants. Similar to the second issue I described, what happens if the grant pool overextends itself. With FCT denominated grants you know exactly how many FCT will be distributed. Yes, some grant recipients will have less funds than they were hoping for and some will have more. They should ultimately be judged with this fact in mind, similarly to how ANOs will be judged. For instance, no one should expect an ANO receiving $5K a month to produce as much as one receiving $25K a month.
FCT denominated grants helps to drive support for the value of FCT. I'm sure there are more reasons that I'm not thinking of as well
 
Secured
#16
I would like to suggest an idea how to improve voting process on next grant round and make it more convenient.

Let's say all funds in grant pool — is 100%.
The grant pool is funded by Authority Node Operators, based on efficiency.
It means, that ANO with efficiency permanent 70% efficiency during 3 months prior grant round, pledged twice more tokens into grant pool, than ANO with permanent 35%.

The idea is to use the average efficiency during 3 months prior grant round to calculate points, that ANO has during grant voting.
So, each ANO will have 0-70 points total to vote for grant funds allocation.
The amount of ANO's points matches ANO's pledge to the grant pool funds — and each ANO decides, how to distribute this points (=part of grant pool they pledged) to the projects they like.

There is no negative points or something else.
As ANO, you know, e.g. you have 50 points, and you choose projects you like and give them your points (e.g. 10 points for one project, 5 points for another one and etc.).

Additionally, ANOs can't vote for own grant projects or projects where they participated, so the voting will be maximum transparent and fair.
 
Secured
#18
Anton, I suggested something similar and the legal working group looked into it. In essence, because you would be controlling your portion of of the grant pool, it opens up all kinds of potential legal and tax implications. I'll let @Nikola comment further.
What taxes can be applied if grant funds are not existed until payout day? I think it’s farfetched 🙃
 
Secured
#19
@Anton Ilzheev

You can see below what a tax attorney said after discussing with me David’s idea. The discussion with him will continue.

“The new idea clearly contemplates control over the grant pool by ANOs. That is, it will be taxable income for them almost certainly – just like the other FCT they receive. I have to think about whether something could be done with escrows because ANOs will choose which projects will receive grants, and this kind of control usually leads to income.

Another option I need to think about is whether taxable income can be avoided if everyone ensures that their FCT from the pool must be spent every year. This creates an illusion that funds are never really under your control. There are two problems - the rollover that is being contemplated will not be achieved, and separately, considering that ANOs choose which projects to award, they still may exercise too much control. I have to think about it.”
 
Secured
#20
I am not a lawyer, but from the legal side, if funds are not existed (no token allocated on the blockchain) until payout, can it be owned by anyone?

After payout date tokens are owned by ANOs whom’s projects are elected. I may be wrong, but I don’t see double taxation issue here in any jurisdiction.
 
Secured
#23
@Anton Ilzheev

I would have to think about it more.

I generally don't love the idea because it's a big departure from the standing party system we have been working toward for voting. Remember though one of the categories there was efficiency, your just talking about taki gn away the other categories. How does this balance then when we bring more standing parties into the mix?

As for legal aspects, tax laws are an area I can't even pretend to understand, I'll leave that to the lawyers ;)
 
Secured
#24
Right now we have only ANOs and Guides standing parties.

Guides may have the amount of points that suits to average efficiency of all ANOs (about 40-43% right now, if I’m not mistaken).

The problem of voting system that we used in last round, that standing parties may negatively involve on results (by voting 0, critically lowering the average score of the project) + different ANOs used different scale (some ANOs voted 0 only for projects they don’t like, others for projects that haven’t fit in their short-list and etc.).

Both this factors together leaded to accidental results of grant round voting.
 
Secured
#25
I have also alternative suggestion about grant voting.

Use binary system votes with clear rules.

+1 — Standing Party support this project
0 / abstain — Standing Party abstain from vote
-1 — Standing Party doesn’t support this project

Each party may vote for every project they don’t participated in.
 
Secured
#26
If the problem your stating is that last round different ANOs had different ways in which they viewed how to vote on grants, then I am not sure why efficiency based voting fixes that. And obviously it doesnt play into that second solution of binary voting.

For a conversation like this I recommend the following.

1. Determine if there was actually a problem/problems with the way grants were voted on last round.
- Were the results of the grant round poor?
- Did things arise that did not create poor grant round results, but reflect issues that may result in poor results in future rounds?

2. Determine what those are, if there are any.

3. Then determine solutions to fix those problems.

I feel like we may be skipping over 1-2 and going straight to 3. I do however agree that there were some issues in grant round 1 that must be addressed, but I think we should lay those out before moving on to the solutions phase.
 
Secured
#27
Efficiency based voting
Efficiency based voting requires to distribute X points between Y projects. There is no way to negatively involve on results with this system.

The only confusion I see here, is voting for pre-approved grants (like Anchor grant, Guides pay and etc.). If I have 35 points, how many points should I give to pre-approved grants and how many for others?

That’s really hard to fit into efficiency based voting.
 
Secured
#28
Binary based voting
1. Binary -1/0/+1 with determined rules (see above in my post) removes the difference in scale between Standing Parties.
2. It’s almost unable to manipulate results.
3. Everyone see what everyone supports / doesn’t support, full transparency
4. Abstaining from voting on own grants should take place

-1/0/1 binary vote is better, than 0/1 as we used in 1st grant round.

There are 2 points — abstain/be neutral & be against the grant. We shouldn’t mix into one 0 vote option.
 
Secured
#29
1. Determine if there was actually a problem/problems with the way grants were voted on last round.
- Were the results of the grant round poor?
- Did things arise that did not create poor grant round results, but reflect issues that may result in poor results in future rounds?

2. Determine what those are, if there are any.

3. Then determine solutions to fix those problems.
I don't think grant round results are poor. But there are some things, that may be an issue in the next grant rounds.

Issue #1. The different scales among Standing Parties when there is non-binary vote, 0-100 points per project.
Even if using 0-10 or 0-5 grades, there will be confusion.

E.g. we decided to use 0-100 gradation again.
I vote 40/100, what does it mean? I support this project, but not only for 40%? I don't support this project? Don't mind if it will be elected?
Or I vote 0/100, what does it mean? The project is good, but others are better, so this project won't fit in my short-list? I don't support this project? I think it's good, but it's not the time for this right now.

Issue #2 is voting for own grants
This behaviour makes grants with multiple parties be in better position, than grants with single parties.
Should I describe it in more details or disproportion here is clear? (more parties involved in grant = more 90-100 votes for such grant from involved parties).

Solution posted one message above :)
 
Last edited:
Secured
#30
Thanks for this thread. As we can see, it raises many concerns about the current system.

I distinguish several issues in the previous rounds:
1/ Pre and post grant payout FCT fluctuation
2/ Vote scoring
3/ Evaluating grant results

For 1/
USD denomination could be a solution.

Let's not pretend it is not. It may be a bit more complex than the FCT payout but this is not a valid reason to avoid this solution. In any discussion we have, this problem is raised either by the granted ANO saying it is taking fluctuation risk (FCT value decrease) or the ANOs because they see a massive value moving from the pool for a Grant which only needed a portion of it to be realised (FCT value increase).

USD denomination complexifies a bit the process. Not that much. If you consider the rules to be followed by the guides just need to be clearly defined, I don't see major issues. We could even "Factomize" the weighted average value of the FCT to be used.

The second issue concern the grant pool itself. What happens if the FCT value is crashing down and you need to pay twice more Factoids that we actually have in the pool?
Then we just need to have a reserve of FCTs. For example 20k. This will absorb any fluctuation. If the FCT value increases we add the extra FCT amount to the reserve. If it is the contrary, we use it to pay the USD denominated grants.

For 2/
I agree any standing party financially involved in a team submitting a Grant should not be able to vote for this Grant. Only problem: it can be easily gamed...

I would also like to see efficiency-based voting too.
I don't think an ANO with 0% efficiency should be able to vote as much as the one with 70%.
I understand the legal issue but lawyers are also very creative when it is about finding solutions in such cases.

For the rest, binary system is fine to me even if I did like the 0 to 100 scoring system. I found it elegant. But yes easily gamed.

For 3/
I consider this point also relates to backpay, massive grant payout and grant updates.

I am feeling uncomfortable paying out massive amount of money at once (be it in FCT or USD) for 2 reasons.

For example, someone makes a promise to make Factom reach 1000$ through a super use case or to scale the code in 3 months. This team looks serious and we all vote for them.
They ask for 500k USD.
We pay them and don't hear about them anymore.
Because there is absolutely no way to incentivize them to behave honestly after the grant is paid.

Second, we are expecting in this case super good updates. But clearly lastly we have seen a lack of communication on this side for some grants. Because there is no strong incentive to do so after the payout.

I would then support a gradual payout. Sam and David proposed it based on block height.
It can be one implementation possibility. The default option being they are paid out. And as already said, if they don't deliver then we don't pay them.
But the question then is who decide? Guides only? Guides+ANOs?
 
Last edited: