Firing Assumption
Perhaps I did respond with the incorrect assumption that you are recommending firing everyone. You did suggest paying the ODC and potentially spinning out data science and maybe sybil analysis into Passport.
I’m really hoping that we agree upon some appropriate level of psychological safety as a first principle for Gitcoin. Think of this post from the point of the contributors of FDD.
- Perhaps this would be received better if you listed the individuals and where they would go?
- Who decides who stays and who goes? You? Other workstreams? (It is tough to say when the recommendation is putting them into the Passport team which you are a lead. You also suggest splitting GPC into two workstreams which you would be a co-lead of both?)
- What about personnel decisions already in motion by FDD? Shouldn’t we consider those?
Being transparent does not mean that we aren’t allowed to have a discussion before you post something that will impact multiple people in this way. This courtesy was given to Moonshot before winding it down, so why not FDD?
The Problems We Are Solving
Gr12-GR15 averaged over $500k in matching funds saved from misallocation by the work of FDD. This fraud is caused by around 25%-30% of the donors being sybil each round. The beta rounds coming up are likely to continue this trend.
Hopefully, Passport DOES fix a majority of it. This would mean FDD did a great job designing the algorithm! Let’s say passport reduced the fraud to half it’s previous volume. We might say that only 10% of matching is fraudulently allocated. Here is what the seasonal loss experienced by the ecosystem would look like using the forecasting model I shared here: An Interactive Model for Gitcoin Revenue Growth Forecasting
The columns in red are the SEASONAL amount lost to fraud! Not cumulative. The rows are seasonal loss based on a low, mid, and high growth rate over time (row 1 is the first season, row 6 is after 6 seasons).
At the same time, the protocol itself is launching after EthDenver. This means we don’t even know how many rounds will be run!
The biggest problem with fraud is that the marginal value is too low for anyone to fund the solution. Sound familiar? This is the age old public goods funding problem. If there is a problem with the grants protocol that the DAO should solve, it is sybil resistance!
Yes, there is a potential opportunity to spin out profitable entities from workstreams, but I am not pushing for this because I’m excited about the business opportunity. It’s because I think that Gitcoin should only consider protocol fees and/or UI fees for revenue but not services! The investment in worktreams recognizes a well known systems problem in cybernetics and offers a positive-sum solution. I’d rather FDD continue focus on solving sybil resistance and take mutual grants in the many businesses which might come from it’s open source data and tools.
This also seems like a very optimistic and humane way to wind down a workstream as it solves it’s core problem.
Refactoring the DAO
I agree that we should refactor around our core problems. If I was to just decide myself, Id say core problems are:
- How to increase the speed and satisfaction of Passport integrations to encourage growth?
- How to enable enough 1-click funding stack permutations on the Grants Stack UI to find product market fit and drive fee revenue?
- How to set best practices in program governance with the Gitcoin Grants Program?
- How to enable economies of scale learning across ecosystems using Allo (grants) protocol using open data to prevent capture at the data layer? (read: black box algorithms & single points of failure in data extraction)
- How to reduce DAO budgets and transition to dogfooding our protocol to fund Gitcoin ecosystem public goods while maintaining our core products?
- How to empower program managers by offering them a robust suite of tools and builders to help continually allocate capital better?
I’m guessing we are closer than farther apart on this. However, I would like to go through our essential intent exercise and then decide on a best way to refactor around our problems.
How We Might Move Forward
Maybe we should discuss 1 on 1? Perhaps there is a more personal reason you might want a neutral third party present? I’m open to working together to find solutions.