Gitcoin Grants Fee Models

gitcoin_grants_fee_models.md

Assumptions:

1. Gitcoin Grants is a self-sustaining revenue stream.
2. Adoption has been strong enough since the release of Gitcoin Grants (along with CLR incentive matching) to consider charging a fee.
3. Users won't sidestep Grants completely to tip individuals outside of our network.

Problem:

What is a fair and sustainable way of earning revenue off Gitcoin Grants?

Hypotheses:

We are trying to learn what users will pay for, and what the MVP is for the fee that best incentivizes users to stay.

1. foundation model for larger grants

   • foundation/organization gets a different grants page
   • e.g $500k is deployed, x% of that is taken for CLR, let's say x=10%, so $50k
   • y% of the $50k is taken as revenue for Gitcoin, the rest goes to CLR
   • it's sort of like a social marketing thing that we say "this org is helping to do CLR stuff"
   • hopefully that's a social incentive to stay and not just tip the amount

2. % subminer fee in grants

   • method on the grants smart contract that sets a fee percentage
   • default fee percentage = 5% on all new grants
   • how should the % fee be applied?
     • does this default fee percentage get applied to every contribution?
     • does this default fee only kick in on contributions past a certain point?
     • does this default fee percentage get applied to every grant, on a monthly basis if the goal is met?
   • how do we avoid users going off-platform and just tipping each other
     • marketing their grant for them to expose it to additional grant contributions (but we charge the grantee (contributor) then)

3. featured grants option

   • featured grant gets extra visibility and top of the page real estate
   • additional exposure somehow?

To hypothesis 1:

• @ceresstation thinks the foundation model makes more sense
• the fee isn't "really" a fee, just a CLR enhancement, money is going back into core enhancement
• creating separate pages for larger grants might be high lift but necessary (grant.io has done this for zcash)

To hypothesis 2:

• % fee can be taken from grants, even a % can be taken and put back into CLR
• an idea is to have a slider for donation amount similar to humble bundle choosing slider (maybe a v2?)
• % subminer fee involves editing the contract, which can be dicey
• first version, grant recipients to send some of it to us (no engineering lift)
  • implementation? ethereum address in the email (there are 4 Gitcoin campaigns) can help boost our own campaigns
  • larger donation pools can donate back to the CLR pool, and have a reserve pool that sustains the funding source
  • when someone does a grant successfully, Gitcoin has a grant as well, do you want to support us, or help support a CLR pot? there are different pools of funding (large and small)
  • another option is to generate revenue just through promotion of our own Gitcoin grant campaigns, relies on donations, less scalable
  • CAVEAT from @vivek about the asking for donations from contributors who are part of a smaller funding pool (weird / wrong place to ask contributors for a small percentage if all they're giving is 5 DAI, as an example). In the case for a larger funder, they would usually be asked from the foundational model for a % of their funding anyway for CLR contributions. I think it's just two ways of saying the same thing, with the foundational model being more sincere and upfront, and easier to finesse, but not necessarily long-term scalable unless with large amounts of funding.
  • implement inflation funding if donations fail (backlash from donations failing), then we have to focus on 1789, or not?

Next steps:

• @owocki & @vivek to ask about the foundational model for Grants round 2
• blue team product to support fulfilling the 50k CLR Grants round 2 (crypto twitter bot)
• find a researcher to sit in at mid-April for collusion detection look-ahead

2019-03-26 update:

1. no answer yet from V about getting a cut of the EF $50k (foundational model).

2. there's a bit of confusion about who we're asking the % fee from, based on the discussion last time, so I've outlined our v1 options as they stand - we can implement a fee on:

   • organization who is giving money to grants: if we do the foundational model with them, it doesn't make sense to take a cut from the grant creator him/herself who receives the money from the organization. We just take a cut of the CLR amount.
   • the grant creator him/herself: it might make sense to take a cut if the grant contributor reaches the monthly amount or when they start a grant or ask them to donate a bit to Gitcoin.
   • contributors to a grant: it doesn't make sense to charge every contributor that contributes to a grant a % fee (e.g I donate 5 DAI to burner wallet but really, only 4 DAI because a 20% fee is charged). We deal with small amounts, and can potentially promote unintended consequences (tipping instead).
   • "inverse fee with Gitcoin Grants": straight up have marketing around some grants for the Gitcoin core team after a contributor finishes contributing to a grant, which is reliant on straight or scaled donations, and potentially less scalable
   • subminer fee: is this under one of the above categories? (I think grant creator) high lift and low probability in terms of engineering complexity
   • dominance assurance contracts:
     • https://en.wikipedia.org/wiki/Assurance_contract#Dominant_assurance_contracts
     • https://programtheblockchain.com/posts/2018/05/01/writing-a-dominant-assurance-contract/
     • If a contributor of a grant stakes x%, and the monthly grant fails to be completely fulfilled, then the contributor gets back 100% + x % of the amount they staked (Gitcoin returns the money to them plus a "tax"), however, if the monthly grant is completely fulfilled, then Gitcoin Core get a % of the fulfilled amount. Technically, no one loses, since contributors get a profit if it fails, but if it succeeds, then they contribute to Gitcoin Core (which is a public good).
     • but doesn't the one who opened the grant lose out on just a tiny bit of funding?
   • inflation funding:

regardless of format the % fee we charge can be be setup for CLR:

• $ for grants -> % for CLR -> % fee -> revenue (larger funding pools)
• $ from grant creator -> might not make sense here?
• $ from contributors -> % fee -> % CLR -> revenue & CLR money (potentially for smaller funding pools who haven't been charged by $ for grants scenario)