Grant Round 3 Improvement - Grants for Tangible work performed

Unrestricted Public Thread

  • Viewed Bedrock Solutions Bedrock Solutions Blockrock Mining Blockrock Mining BuildingIM BuildingIM Canonical Ledgers Canonical Ledgers Crypto Logic Crypto Logic Cube3 Cube3 DBGrow DBGrow De Facto De Facto Exchange Committee Factom Inc. Factom Inc. Factomatic Factomatic Factomize Factomize Factoshi Factoshi Federate This Federate This HashnStore HashnStore LUCIAP LUCIAP LayerTech Matt Osborne Matter of Fact Matter of Fact Multicoin Capital Multicoin Capital Nic R Prestige IT Prestige IT RewardChain RewardChain Stamp-IT Stamp-IT The Factoid Authority The Factoid Authority VBIF VBIF
  • Not Viewed BI Foundation BI Foundation Syncroblock Syncroblock
Secured
#1
The way the Grant Round is currently setup, grant compensation for work already performed is disallowed because it falls under "backpay." This restriction is too broad and is detrimental to the community.

Note: This is not an overhaul of the process, this simply would coincide with the current process.

The easiest way to explain the addendum is with scenarios:

Scenario 1 (the current method):
An ANO has to wait 3 months to build something, they have to also campaign for votes, then they have to hope their grant even gets approved.

Scenario 2 (the addendum):
In addition to waiting to begin work before getting an approved grant (scenario 1 above), the following scenario would be allowed:

The ANO can begin building immediately and then HOPEFULLY sell the product to the community when the next grant round is initiated. The ANO assumes all the the risk in this situation, as the standing parties may choose not to approve the grant.

Benefits of adding scenario 2:
1. The community is taking less risk because the product is already built (the grant submitter has something tangible to show the standing parties). This would also have the added benefit of improving the grant applicants chances of receiving a grant since the grant applicant has tangible results to present.
2. The product arrives much earlier than it otherwise would have (no need to wait months to hopefully get the grant approved and begin work)
3. This opens the door for non-ANOs to build, since they can now sell a finished product to the community instead of needing a grant, which largely go to ANOs.

If we want to maximize the number of development projects, maximize the speed of development, maximize appeal to outside developers, and minimize grant pool risk, then we should implement something similar to the above.
 
Secured
#3
Don’t you think that ANOs will start to use scenario #2 for all works they made instead of using ANO income for some of works?
@Anton Ilzheev Valid concern. If we unpack that a little, here's what I see:

1. If the software is currently private, but they want to sell it to the community, thus making it open source, then I see that as a good thing

In the long-run, open source should always win out over private solutions. Open source is cheaper (no mark-up by provider) and it gives the party using the open source code 100% control (no gatekeeper issues). Hence, one of the reasons we all love and believe in blockchain. As a community, we should strive to make as much of what we are doing open source.

2. If the standing parties do not want to buy what the grant applicant is selling, then they simply vote against the grant. If the product is overpriced, then we vote against it. We have no obligation to buy anything.

3. If someone already has an awesome, private solution built but making it open source could help FTC usage explode, do we really want to say no to that? Are we supposed to wait for some other developer to come along and pitch the exact same solution as a grant?
 
Secured
#6
ANOs should be motivated to expand protocol usage. More usage = higher token price = more funds from ANO income for development.
Yep, and in theory, the more open source tools out there, the more usage. So incentivize people to build prior to receiving a grant.

Scenario #2 will decrease open-source projects launched, cause instead of simple launching open-source, they will try to sell it in the grant round.
Disagree. Instead of launching open source, they will keep private. No one is going to forego profits. Is your new BaaS API totally open source? Or is it private because you want to make a profit??? :)

If a developer can sell after they have already built a soltuion, and the community feels it has value via voting for it, then a private solution can becomes open source, which should further "expand protocol usage." And per your statement above, protocol usage is the goal. We both agree on that.
 
Secured
#7
Playing devil's advocate here but a possible scenario I see is :

People will try to build more stuff privately, try to monetize it and if they fail or lack funds at some point they will then try to package the idea and sell it to the grant pool as a "novel" idea.

If the goal is to build open source software from the start why would anyone do something secretly for 6 months ? Why not involve the whole community right away?
 
Secured
#8
Playing devil's advocate here but a possible scenario I see is :

People will try to build more stuff privately, try to monetize it and if they fail or lack funds at some point they will then try to package the idea and sell it to the grant pool as a "novel" idea.

If the goal is to build open source software from the start why would anyone do something secretly for 6 months ? Why not involve the whole community right away?
I have a use case for FAT that would be HUGE if it got traction. It could theoretically be done on Ethereum and it would be important to get first mover advantage.
 
Secured
#9
Hey Mig. Thanks for the Qs.

People will try to build more stuff privately
That's better than them not building at all. Being able to fall back on potentially selling to the grant pool gives them a parachute should they not be able to monetize it. That assumes the community decides the product has value though and wants to buy it.

try to monetize it and if they fail or lack funds at some point they will then try to package the idea and sell it to the grant pool as a "novel" idea.
And if they build a crap product, then we don't buy it. Which option is riskier for the community?
1. Funding a grant before any development has even started, thus solely basing the grant off of a Google Doc outline?
2. Evaluating an already built product that was not able to get traction?

I'll take option 2 every day of the week.

If the goal is to build open source software from the start why would anyone do something secretly for 6 months ? Why not involve the whole community right away?
They aren't doing it secretly, they are just starting to build before they receive a grant. They are also potentially increasing their odds of getting the grant because they actually have something tangible to show.

Another scenario, maybe they have a private solution that they originally intended to sell, but they are all good developers but are bad at sales, so they have changed course and decided to sell to the community. Nothing wrong with that. It's then up to the community to decide if they want the product.

There is no reason the community should only be able to invest grant funds in projects that have not yet started.
 
Secured
#10
Your points are all valid and I don't really have a strong opinion either way.

I am simply twisting the argument to understand why would anyone take this much risk in the first place? The only answer I could come up with is that you mainly want to switch from private to public to get funding that you failed to secure. There is a lot of valid reasons why this might happen along the way.

I personally find it harder to say no to something that looks good when it's half way done, I get all FOMOy
 
Secured
#11
I personally find it harder to say no to something that looks good when it's half way done, I get all FOMOy
LOL


@Miguel Proulx I see where you are coming. I appreciate you providing a different view. You very well could be right that the only reason people switch from private to public is because they couldn't generate revenue. To me though, that's not a big deal. The community has to make decisions one way or another on how to allocate grant funds. The more information they have (an already built product), the sounder their decision should be (in theory).
 
Secured
#12
You very well could be right that the only reason people switch from private to public is because they couldn't generate revenue.
As part of a project that started development for months privately before bringing public, I can say that there are at least SOME times when you go private to public that has nothing to do with not securing private funds ;)
 
Secured
#13
Also, I 100% support Backpay grants. You hit the nail on the head with your pros/cons list.

And for transparency, there are currently no projects DBGrow is building that we plan to seek backpay on.

I just really think backpay grants make sense for the sake of the protocol. I love the idea of the protocol being able to "buy" products to put them into public domain for the betterment of the protocol. And I don't really care why the entity is putting them forward for us to buy, We'll make our decision at that point in time whether its a good purchase.
 
Secured
#14
Backpay for development work (which incentivizes immediate work when it's conceived -- rather than waiting some time to begin that work), sounds like a great option to me, as well.

While I do see the concerns relating to ANO's assuming the risk when starting work prior to Grant funding, it just makes more sense to me that bringing something to the funding table that is tangible, able to be evaluated, and shows some promise (as more than just on paper), is the best way forward. Plus, as Matt said, it represents the most community-based option in terms of lowered risk and increases the likelihood of non-ANO's developing and selling to the community.
 
Secured
#15
Thanks for this, Matt. I think backpay for tangible work produced is a good thing, when the community is getting something they want in return.

It’s the communities choice whether they vote for or against it, so all the risk lies with the developer. The protocol can only gain from this.

Crucially, the work needs to be somewhat visible and announced. Otherwise it opens up a lot of future claims which can’t be verified.
 
Secured
#16
To add to the above: a risk to the protocol is that if a project wasn’t awarded after all that work, due to competitive/core grants, then a good team may feel slanted and leave the ecosystem.

We’ve seen the Herc guys feel like they weren’t supported.

Perhaps we can find a way to include or give support in other ways in these oversubscribed instances.

For example David’s EC donation, or an offer of lower efficiency in lieu of a grant until next round.
 
Secured
#17
Thanks for your thoughts on this, @Matt Osborne

I think last grant round backpay was a hot potato because the pool was so oversubscribed, it left everyone with a take it or leave it situation. I personally can’t see the pool getting less competitive anytime soon. But I agree, ultimately the decision should be with the standing parties and we should have as few 'rules' as possible.

So to be clear, are you suggesting that only completed work should be eligible to be 'bought'? i.e not 3 months backpay for a 10% completed project?
 
Secured
#18
@Matt Osborne I interpret this in venture terms. The current grant method funds Seed rounds. Your addendum would encourage funding of Series A rounds, which are inherently less risky.

In general, like follows like - mature investors (KKR, Blackstone, etc.) fund mature projects (Uber, Lyft, etc). So by funding later stage projects, we would be signaling to the public the growth and maturation of our community. I like that.

That said, many Series A companies come to the table with deferred compensation. To be fair to those teams, and to @Benjamin Dufty's point, I'd avoid creating a hard rule against paying those when they seem legitimate.
 
Secured
#19
@Benjamin Dufty - Matt can correct me if I'm wrong on this one, but my understanding is that ether option is entirely possible and beneficial for the Community.

1) A team completes work on a project and then attempts to sell it to the community, requests backpay for the labor.
2) A team completes a teaser of say 10-20% of the work, then requests backpay, and forward-pay for more development.

In Scenario 1, the community can decide whether that backpay is deserved in terms of whether the product is beneficial enough to the protocol. i.e. whether the community wants to buy the product.

In Scenario 2, the community can decide whether the teaser is enough to fund backpay and forward pay.

In both scenarios, the community still decides what is most valuable to the protocol from a Grant funding perspective, and gets to do so with far more information and insight into a particular proposal relative to our current Grant review system.
 
Secured
#20
3. This opens the door for non-ANOs to build, since they can now sell a finished product to the community instead of needing a grant, which largely go to ANOs.
@Nic R probably, the above scenario only described a completed project. Personally, I don't have an issue either way - standing parties should always decide where the best value is.
However, that risk is very much on the protocol if the project is only 10% completed and half the grant pool is being requested. Obviously there would be much more appetite for a completed project for half the grant pool (or paid in installments). If competition continues to increase I think we're more likely to see entities internalising preliminary work and applying for forward looking work only to gain a competitive advantage.
 
Secured
#21
@Benjamin Dufty and @Mark Thorsen Thanks for chiming!

So to be clear, are you suggesting that only completed work should be eligible to be 'bought'? i.e not 3 months backpay for a 10% completed project?
Nic is correct. His wording was better than mine, so I'll just quote Nic:

1) A team completes work on a project and then attempts to sell it to the community, requests backpay for the labor.
2) A team completes a teaser of say 10-20% of the work, then requests backpay, and forward-pay for more development.

In Scenario 1, the community can decide whether that backpay is deserved in terms of whether the product is beneficial enough to the protocol. i.e. whether the community wants to buy the product.

In Scenario 2, the community can decide whether the teaser is enough to fund backpay and forward pay.
Just to unpack scenario #2 a bit more: The community could also decide that they don't want to provide back pay, but they do want to provide forward pay (technically, this would require the grant proposer to update his proposal after he has received sufficient feedback from the community).
 
Secured
#22
It is important that the community sponsors research and development and hence there is real value in the grant process as something distinctly different from running operations, for which the ANOs get rewarded normally. However there is also a lot of merit in enabling payment for completed work.

I think that the historical problems have been centred around the concept of grants being just for future work. Grants for future work are speculative and have no guaranteed outcome, whereas “grants” for completed work can be more sure of a securing a specific product.

I know that you do not want to rewrite the grant process but would question whether buying completed work is really the subject of a grant or is it procurement?

Assuming that we want to manage this through the grant process is there a case for asking grant applicants to declare the status of their work, which could range from not started (require funding to make a start) through to a fully completed product. Where applicants choose to put themselves on this spectrum is a function of their risk appetite. Some may prefer to do the work first and then expect a more sizeable reward for having borne the risk and completed the work, others may require payment via a grant for effort early in the development process.