As per the GIVmatching MVP forum post, we want to implement a very basic matching pool system where donors who are looking for an easy giving solution can send funds to the Giveth matching pool, get GIVbacks… and we distribute these funds to verified projects on Giveth.
Starting Considerations and Ideas
We need to discuss and determine how we will distribute the funds raised in this pool. There are a few ideas/considerations based on chats with @Griff, putting them here to get the ball rolling, looking forward to more thoughts
Considerations:
The matching pool will get donations on both mainnet and xDai
Some projects (i.e. Giving Block projects) can only accept funds on mainnet
Funds will be in a variety of different tokens
We need to pick an initial “raise” goal
When GIVcuration goes live, we should use GIVcuration to distribute these funds
Ideas:
We could distribute funds evenly across many/all projects
We could distribute funds as proportional matching
We could distribute the funds to the top 10 verified projects (the ones who raised the most)
We could split the pot up evenly to the top 10 projects
We could give a greater % to the top project, less to the second and so on (for up to 10 projects)
We could convert all donated funds raised to GIV and distribute on xDai (except what would go to Giving Block which we could send as ETH (or GIV if Gemini accepts us) on mainnet)
Of the pool of funds, after we reach our raise goal, we divide by 26 and distribute every 2 week round… so we have enough to distribute for a whole year
Conclusion
Throw all those big brain ideas here and we can start hashing them out. I think that, once these ideas turn into serious proposals, they should become their own forum posts.
I love many aspects of these ideas. I thought initially it would be cool to push for projects who raised the most however I think this will present a big challenge for us because we don’t have any great tools to see if a project was using its own funds to pump itself full of donations in order to get GIVmatching…
Maybe a solution presents itself but at the moment I think we’ll open ourself to many many headaches if we go that route.
I love the idea of liquidating assets into GIV then donating GIV - I think that will benefit us while onboarding more project owners into GIVernance.
What about selecting a category as a theme (they can only have max 5) for a distribution and using top projects by quality score?
Yeah, I don’t know if I like the distributing to top-donated-to projects either… it would be nice to give funds to projects that need it more (in some way), but still not sure the best way to do that.
+1 on making it all GIV. I think this is a super good idea and I’m also backing it.
The issue w quality score is that #1 it’s still not implemented… #2 it’s also easily gamable because it takes into accounts number of likes & amount raised. so you could create a bunch of accounts to like your project & donate a big chunk… then get the most of the matching pool.
I also wouldn’t want to make things too limited by category. what if there’s an awesome verified project that doesn’t select any categoies? Vs. one who selects 5 increasing their odds of getting the matching.
Sorry, I didn’t offer solutions, just more questions/problems…
maybe we just make it fully random, taking a slice of verified projects, donating to them via GIVmatching and then moving them to an ineligible list until we cycle through them all. A random lottery.
other objective filters I thought of that we have are creation date and alphabetical order - less exciting though.
I was braining this a bit more and I like the idea of a lottery or random draw for projects but they should be required to do some sort of action to show “proof of life” like perhaps they just need to click a button on their project page to sign up for a GIVmatching round. This would be to keep project owners visiting the site and revisting their projects.
We could even prompt them before signing up for a round if they would like to add an update to their project or something along those lines - something that entices projects to increase the quality of their profile on giveth, thus benefiting the site overall.
Hi I really like the idea of distributing evenly amongst verified projects for the following reasons:
projects who raise the most money are more versed in crypto and has more opportunity (or donors) to support them while project who didn’t raise much perhaps has less influence or less experienced, I feel that they may get a boost and motivated to do more in this space if there is the matching fund for encouragement
again the projects who raise more money may be in general bigger and more influential - this create a power position for them while smaller local project may not have enough following power but really need support can be left out
we can use the matching fund to attract new projects/nonprofit to come onboard. Most traditional nonprofits I work with often are hesitating because they either don’t know a lot about the crypto space or they are unsure there will be donors, this is a great assurance that if they sign up and get verified at least some fund will come and they will build confidence that way.
While it is nice to have a fair distribution where all verified projects would receive the same amount this solution wouldn’t scale well. At some point the amount of funds projects would receive would be so small that it would not be able to have an effective impact for the project’s goals.
I would like to expand on the random lottery idea I mentioned a few weeks ago:
@WhyldWanderer brought up a point of how to mitigate project owner’s who own many projects from receiving GIVmatching funds multiple times. We could instead look at project owners instead of projects. When we hit our GIVmatching goal we select 25 project owners of verified projects at random and send funds out to them. a project owner who has multiple projects would receive funds diluted equally across all projects they own. Once a project has received funds from GIVmatching they are taken out of the eligible pool until we’ve cycled through all other verified projects.
Example:
We reach our GIVmatching goal of 500k and select 25 project owners at random
Each project owner receives 20k
Project owner A has 1 project - they receive 20k to their single project
Project owner B has 4 projects - they receive 5k to each project they own
Project owner C has 10 projects - they receive 2k to each project they own
My thoughts on the random distribution w/ project owner constraint
So as we discussed, I don’t think using project owners to make the system more resilient is the best option. There are some people who own multiple distinct projects, and their projects (while distinct) would get less matching. It’s also really easy to game, for example, for one big org can just get multiple different people to make sub projects.
The disadvantage w random distro is that… projects could get matching even though no donors gave. if no one gave… do we really want to be supporting them? I think part of the appeal of donation.eth is knowing that donations go to a good place, if it’s random, there’s no way we can say that was true.
clr.fund as a option
We were talking with Auryn from clr.fund who was saying we could deploy an instance of their quadratic matching and test it out. There are some interesting nuances for sybil protection:
we can’t track which projects each donor donated to (for the rounds)… they would all show up as “anonymous donations”. that means the donors couldn’t be on the project’s leaderboard, but they could be on the overall leaderboard with their profile… so we could give them GIVbacks
we would need to have brightID or some kind of identity solution
It would be interesting to talk more w Auryn and determine what steps we’d need to take. maybe deploy a test env.
using top-projects
As discussed w Griff & Mitch… we could also consider giving matching funds to the top projects in a particular round (or the top projects ever?)… we could say we give to the top 5 and give “matching” funds that are proportional to the amount donated by other donors… if we give 20k out each round it could be something like 4k to each project… or maybe 10k to the top and 1k to the bottom…
I think the idea of using this for actual matching is pretty cool.
Additional ideas
Whatever we do… I think it’s worthwhile using the funds collected to buy GIV, and then we distribute GIV on gnosis chain. As I mentioned at the beginning of this process though, we need to consider that some of these projects will be Giving Block projects and therefore will only be able to accept mainnet tokens… and to date, they don’t accept GIV.
There’s definitely a lot of scope added if we need to implement an identity solution. I don’t think we should include it in the GIVmatching spec.
The disadvantage w random distro is that… projects could get matching even though no donors gave. if no one gave… do we really want to be supporting them? I think part of the appeal of donation.eth is knowing that donations go to a good place, if it’s random, there’s no way we can say that was true.
I don’t think we should pass over verified projects with no donations, maybe they’re new or don’t have a strong marketing campaign, we should trust our project verification process in terms that donations are going to a good place.
Using top donated projects opens us up for more direct angles of exploitation than using project owners. If a project owner has multiple profiles and multiple orgs they would all have to be verified and ideally we have their social media info from the typeform and we could do some basic investigation to see the correlation between sub projects and their parent orgs.
Using top donated to projects provides strong incentives for project owners to spin their funds around back into their projects and there are many tools in crypto to make this hard to trace. We would create significant overheard for ourselves to have to track donations received in this manner.
I agree with swapping funds to GIV and dispering GIV to “winning” GIVmatching projects.
My favorite option is proportional matching. I like this approach because it motivates projects to promote donations on Giveth. Think about how we and every project on Gitcoin promote donations on Gitcoin during the grants round, but not much outside of that. If we go with any of the options that are random or evenly distributed, we lose this major benefit. I also prefer distributing matching donations to all projects that receive donations rather than the top 10 to both spread the love further and also to ensure that all projects, not just top projects, are motivated to promote donating on Giveth.
Yesss I would love to do quadratic matching if we could figure out a way to mitigate sybil attacks. Will ask Kevin whether Gitcoin has anything we could borrow for this. It would be great if they’ve already built a tool where we could upload a list of addresses and transactions and filter out any that are suspect for instance.
How do we create a fraud proof system to make sure projects aren’t just recycling funds back to themselves to acquire more matching funds? The way we are currently investigating for fraud is insanely time-consuming and certainly not efficient nor scalable.
Great point, this is main tradeoff of making donation matches proportional. I asked Kevin whether Gitcoin has anything available that we can borrow and this was his response:
"heya; man i wish we had our QF protocol ready but its just not yet.
long term for sybil we have https://proofofpersonhood.com/ available, but for now i can intro you to our Fraud detection lead who will have that data?"
I’ll ask Joe whether they have anything we can borrow that would help with this, both for matching donations as well as for GIVback fraud detection. The fact that projects have to be verified and can be disqualified I think puts us in a somewhat safer position than Gitcoin where anyone can create a project and be eligible for matches, but you’re right that any proportional distribution will require fraud review.
Is there anything about doing fraud prevention on matching donations that would be harder than fraud prevention on GIVbacks?
Nothing about it necessarily makes it harder but if we would go for a proportional matching method for example there would be a ton of donation data stretched over potentially a long period of time, creating lots of overhead. The verification process is a good extra step but not a hard preventative. We don’t have an id solution and there has been some resistance to implementing an id solution iirc from our governance discussions.
I would honestly love to find a way to incentivize donations to projects but it would be a shame if the end result is a massive headache of fraud detection. I know we had some discussion with TrueBlocks to create a fraud analytics tool but I haven’t seen any movement for a while.
Agreed, Gitcoin can help as they are the experts in this field.
It did just occur to me though… if we are already doing fraud review on all donations to verified projects for GIVbacks, wouldn’t this cover the fraud review for matching donations as well?
Either way, will see if Gitcoin has anything that can help us improve our fraud review process.
that’s a great point! that does alleviate a big part of the problem - we’ll need to make sure we relay blacklisted donations from GIVbacks to our GIVmatching distribution.
Okay everyone, I took a serious stab at trying to figure this out and I came up with a pretty robust solution. Strap in, we’re going deep.
General Overview
With GIVmatching we will take “top-ranked projects” from established bi-weekly rounds and distribute a portion of the funds held in the Giveth Matching Pool to these projects. The metrics for deciding “top-ranked projects” will change depending on where we are in the current Giveth Core Roadmap. More details on that a bit further down.
GIVmatching starts officially when we hit $500,000 worth of funds held inside of the Matching Pool. We will liquidate all holdings at that time into GIV and distribute matching funds exclusively in GIV.
From launch, every 2 weeks we will take a percent of the current GIV holdings in the Matching Pool and set them aside to have as matching funds for a given number of top-ranked projects. This means, without receiving additional funding each round will distribute incrementally less as the GIVmatching supply dwindles.
The top “top-ranked project” will have a set percentage more of maximum matching funding than the bottom “top-ranked” project, with all the projects inbetween calculated proportionally. This is the variance factor.
For example:
There’s 200,000 GIV in the Matching Pool. We want to distribute 10% (20,000 GIV tokens), we have 10 “top-ranked” projects picked for the round. Our variance factor is 110% so the top project will receive 10% more tokens than the bottom project. The distribution would be as follows, from lowest to highest:
Rank Placement
Tokens to Receive
Rank #10
1901.29050320353
Rank #9
1924.84130368797
Rank #8
1947.79142148437
Rank #7
1970.13596385686
Rank #6
1991.87176575824
Rank #5
2012.99731160521
Rank #4
2033.51265156975
Rank #3
2053.41931353044
Rank #2
2072.72021177969
Rank #1
2091.41955352388
Donations made to the Matching Pool after launch will be arbitrarily liquidated into GIV at any given moment, decided by the multisig holders, thus keeping the GIV supply periodically topped up.
GIVmatching will provide up to 75% of the USD value of donations as matching funds or if this over the matching funds remaining it will match with whatever funds remain for the given project. The 75% matching is considered the GIVmatching Factor.
A project that has been “top-ranked” in a round and received GIVmatching funds will become ineligible for the subsequent 5 rounds (10 weeks).
Parameters
There’s a few parameters that we’ll need to decide at launch and we could modify between rounds:
The percentage of remaining Matching Pool GIV to distribute
The amount of projects to include as “top-ranked”
The GIVmatching Factor
The percentage of tokens the top projects gets over the bottom project. (Variance Factor)
How long a project that has received GIVmatching must wait until it is eligible again
The first two states that will define a project’s rank are pre-GIVpower launch and post-GIVpower launch.
pre-GIVpower
Before the launch of GIVpower the clearest metric we have for ranking projects is USD value of donations received within a given period. Projects must be Verified to be eligible for GIVmatching.
Following the GIVbacks bi-weekly cycle we can get the sum of the USD value of donations received to each project during the given period dates, we’ll take the top slice of highest donated to verified projects, assuming elgibility, and make them eligible for GIVmatching on donations for following 2 week round.
post -GIVpower
After the launch of GIVpower we’ll have a new metric to consider, that will be the average amount of GIVpower staked to a project during a round. We’ll now have this metric in addition to USD value of donations received to consider when ranking projects. GIVmatching will transition to follow the bi-weekly cycle of GIVpower from GIVbacks.
We can dynamically set how much we value one metric over the other by introducing two new parameters: Donation Factor and GIVpower Factor which can increase or decrease the influence of each metric on the final GIVmatching rank of a project.
For example:
We have 10 Projects with the following stats at the end of the round:
Project
Donations USD value for Period
Average GIVpower
Project A
500
1000
Project B
1000
200
Project C
2000
500
Project D
15000
10
Project E
250
60000
Project F
40000
2000
Project G
5000
4000
Project H
6000
7000
Project I
10000
8000
Project J
500
60000
Our Donation Factor is 1 and our GIVpower Factor is 0.5. We multiply the second column by the Donation Factor and the third column by the GIVpower Factor. Our project ranking then looks like this:
Project
Final Donation Score
Final GIVpower score
Total Score
Top-project Rank:
Project A
500
500
1000
10
Project B
1000
100
1100
9
Project C
2000
250
2250
8
Project D
15000
5
15005
4
Project E
250
30000
30250
3
Project F
40000
1000
41000
1
Project G
5000
2000
7000
7
Project H
6000
3500
9500
6
Project I
10000
4000
14000
5
Project J
500
30000
30500
2
Parameters
So we’ll introduce two new parameters than can be changed, making our total list of modifiable parameters post GIVpower launch to be:
The percentage of remaining Matching Pool GIV to distribute
The amount of projects to include as “top-ranked”
The percentage of tokens the top projects gets over the bottom project. (Variance Factor)
GIVmatching Factor
Donation Factor
GIVpower Factor
Spreadsheets!
It wouldn’t feel right with some good ol’ spreadsheets to play around with some parameters.
You can fork this Google Sheet and get started.
Tab 1 - Distribution Calculation: How much funds should we distribute each round and to how many projects.
Tab 2 - Dynamic GIVpower Switch: Weighing USD value of Donations vs. GIVpower and how it affects ranking and thus allocated GIVmatching.
If you want to test how GIVmatching looks pre-GIVpower simply set the GIVpower factor to 0.
Tab 3 - Matching Funds: Bringing it all together, taking the funds available for each round in total, and to each project and simulating how much matching funds a project would receive for a given donation.
CHECK IT OUT!
Major props to Zhiwei for creating the variance factor algorithm and @cquinterom096 for implementing the cusom function script so we can actually play around with it!
This post indicates that we need to address all UI changes and user flows before even thinking about starting to work on the implementation.
Has any designer been contacted and made aware of this already?
Gitcoin can help as they are the experts in this field.
