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?
From a macro economics point of view the idea of matching a percentage of funding in $USD is not going to work in favor of projects over time. As the purchasing power of USD is diminishing this affects the impact potential of a donation because at the local project level the costs of supplies or resources is also going to carry/include the same trend of inflation.
Matching based on % of total tokens received rather than their USD value will better preserve purchasing power of donation over longer time horizon.
For projects where local inflation is following an increasing rate of change the opportunity to receive greater total supply of an asset that absorbs the depreciating value of their local unit of account is going to help dramatically and would also likely incentivize keeping a portion their GIV donations so they can continue to collect a higher allocation of GIVrewards assuming a GIVforwards type program were put into place for the projects.
The value is registered in USD but GIV is distributed…Projects that receive GIVmatching benefit from possible upside of GIV and other GIVeconomy benefits like the GIVgarden…
Based on what % of what total tokens received? I don’t really understand what you’re trying to explain.
Praise @mitch , for putting so much work, effort and energy into this spreadsheet. I want to take my time to go through it and give well-structured feedback.
But here are a few initial comments that come to mind:
a) If being a top-ranked project gives your donors more GIVbacks and donors with more GIV can provide more GIVpower. Aren’t we creating a system that significantly favors the first commers? If so, is this what we want to promote?
b) Love the idea of the GIVpower factor. IMO, this should be equal or higher to the donation factor, to incentivize people to lock GIV.
c) I would like to see a matching fund that would encourage many projects to do the right things like posting updates and measuring their impact. Rather than only benefit to the top-projects
Thanks for feedback on communicating better. Let me try a user story format.
As a builder and designer of communities, I want to understand tokenomics and stock to flow logic of Giveth, so I can better serve project leads in developing countries with off ramping and navigating their local currency exchange dynamics.
I think what you wanted to point out was that USD has an inflation problem, this means that donor funds don’t go as far for project funding because of the purchasing power of USD becoming diluted.
Unfortunately the benchmark comparison for the vast majority of crypto projects is their USD value. This is the basic and easiest to understand metric and there is already a robust and accessible network of APIs that allow us to fetch USD prices of most crypto assets in real time and retroactively.
To compare donations in a wide variety of tokens against some other token or currency value to determine the “donation value” would be an uphill battle against the status quo.
Yes I wanted to highlight that all fiat is currently inflating away purchasing power. USD included and simply holding up because it’s been privileged to be the default reserve currency over 20th century.
In my original comment I wanted to raise awareness that in jurisdictions where USD is no longer accepted or scarce; the possible monetary impact of a donation will evaporate because exchange rates for USD are different in black/gray fx markets.
Absolutely. I know these APIs can also return values in BTC/SATs. I understand and agree USD is the simplest unit of account from a basic accounting/budgeting point of view. It’s just not ideal considering the off ramping dynamics I’m accounting for.
My thinking is that a calculator function that can switch between USD/BTC value on Giveth would be valuable to users in those jurisdictions/regions where banking and financial infrastructure is unstable/evolving.
I understand and what I’m concluding is that I need to put together a spread sheet for my needs and accept the logic that is informing Giveth’s trigger mechanisms to be what they are.
I like quadratic matching best though I think maybe verified projects that weren’t able to raise donations should be treated as if they received $1 as a sort of social safety net. So the minimum shares a project can have is 1 instead of 0.
In regards to sybil attacks, I’ve found an article on how Gitcoin handles it here.
Gitcoin can help as they are the experts in this field.
