As we launch the Gitcoin Protocol, I wanted to try and document the journey we went through. Partly to help share our process. Partly to help me remember how this evolved. I’ll be putting out a series of posts here, hopefully some folks will find it interesting.

All funds from this series of posts will be donated to the Gitcoin matching pool.

At the start of 2022, we at the Gitcoin Product Collective (GPC) were asked to look into how to take apart Gitcoin and rebuild it as a decentralized protocol.

There had been a previous attempt by the DAO to build a project called dGrants that had managed to run a few grants rounds, but the sense internally was that this hadn’t been a successful project. I wasn’t there, and honestly can’t say I had an opinion at the time. I was only aware that it was being shut down, and the ball was getting passed to us. Something of an ominous start 😅

But at that point in time, Gitcoin was a 4-year-old monolithic python/django codebase that had had been built out by bounties, with dozens of contributors, dozens of experiments launched and left in some state of operation, and was really at least five products under the hood. Did you know you could tip people directly in Gitcoin?

We needed to get a handle on the scope of this project, and hopefully reduce the problem space to make this manageable.

It’s worth giving some organization context here too. Gitcoin Holdings was the original company that built Gitcoin. Mid 2021 the Gitcoin DAO was spun up and they launched a token (GTC). The plan was that the DAO was going to run the charitable business (Gitcoin Grants), and Holdings (now supermodular.xyz) was going to be the for-profit entity (Hackathons).

With the disaffiliation of Gitcoin Holdings and GitcoinDAO finalizing in early 2022 the decision was made to fully move the charitable products into the DAO. This included moving the GPC team. But importantly, this meant our focus for rebuilding Gitcoin was exclusive to Grants. So we could take bounties and hackathons off the table. Kudos and Quests (remember those?) were planned to be sunset, and Kernel was about to be spun out.

So, with Grants as the focus, we had a place to start.

But, this was a chance to rebuild Grants from the ground up, not just rewrite what we had, and we needed to understand our domain.

Our first decision was to bring every core team at Gitcoin involved in running the Grants program into a multi-day Event Storming workshop. If you’re not familiar, this workshop format is built around the practice of Domain Driven Design, and is really built for this work - quickly understanding an end to end system, to understand the bounded contexts of the domain, and to architect a software system FOR that process.

This was our first time getting everyone who had a hand in running the Grants program in one place to tell us, in detail, EVERYTHING they did to run a round. We had Public Goods Funding, Grant Operations, Fraud and Defence, Support, Marketing, Engineering, Product, and Design get everything out on the table.

It was a lot.

And worse, a lot of it was a combination of off-platform tools (google docs and notion), backend exports from metabase, or data dumps piped through scripts, extensive use of the django admin (no real business logic, practically just CRUD on the DB), and just plain human processes.

Additionally, we had this new permissionless protocol thing to design for. With Gitcoin as a protocol, anyone could run a round with any criteria, receiving applications from anyone else, and letting any community vote on these funding allocations.

We were fully unbundling the Gitcoin Grants product and needed to build a plan to let Gitcoin work AND let any other community work.

We’d known for a while, but it was especially clear after the Event Storm, that Gitcoin had become a ‘round of rounds’. By GR12 we were running a dozen or more grant rounds in parallel. Not just one!

Gitcoin was facilitating these rounds centrally with shared and overlapping team resources.

To bridge these conflicting use cases: any community funding it’s shared needs vs. Gitcoin runs the round of rounds. We embraced the design decision that each ecosystem round on the Gitcoin program(Gitcoin main, Polygon, ETH Infra, Climate, etc.) was an independent round, running concurrently, unified through a single interface.

This gave us the modularity to design a system that worked for us and the independent grant ecosystems we hoped would benefit from the protocol.

After mapping the Grant program we saw a grants protocol had three primary users:

• The Round Operator - the person or group who raises funds, defines eligibility criteria, does grant review, and orchestrates payouts

• The Grantee - the folks who have projects and are seeking funding.

• The Donor - the folks who are there to fund and support public goods.

These were mapped to the protocol as two main projects: The Round Manager (which has a donation frontend called the Grant Explorer) and the Grant Hub.

If you’re familiar with Quadratic Voting, Quadratic Funding, or any attempt at Democratic decision-making in crypto you’ll know that the biggest weakness of these mechanisms is proof of personhood. In the highly anonymized and privacy-preserving space we work in, these systems are easy to game by creating sock puppets and stuffing the ballot box (Sybil attack the system).

Knowing we would have this issue in the protocol, we took one additional component from Gitcoin (the Trust Bonus) and pulled that into its own decentralized product, and our third project: Gitcoin Passport.

With the users, the projects, and the team structures in mind, we announced our plans to the Dao in March 2022

https://gov.gitcoin.co/t/gitcoin-grants-2-0/9981

To create focus of the coming work we did a some deep dives with the Gitcoin teams to try and fix some of the most egregious issues with the platform. We launched these updates updates to the Bounties and Grant flows in GR13.

After GR13 in March 2022, Gitcoin was officially in maintenance mode, and we were committed to put all of our efforts into Decentralizing Gitcoin.

This period was tough. I was new to the team. We had pressure to show results immediately. And given that this was the second attempt at decentralizing Gitcoin, there wasn’t a lot of patience left. It was a project that felt late before it had even started.

The reactive instinct would have been to put a small team on this and just start writing code. It’s a rewrite, just make a dapp that does what Gitcoin does, how hard can this be? Maybe we could have even grabbed the dgrants codebase and just started from there.

I have to give my co-lead Lindsey a huge thank you at this point. I think she had the strength and steadfastness to make the argument to do this the right way, not the fast way. If it hadn’t been for that solidarity from Lindsey we woudn’t have done the hard work to understand our problem deeply, set up the teams for success, or be in a position to bring the DAO over to the protocol.

For almost two months we’d been working across the DAO to understand how a protocol future could look, testing hypotheticals, learning the constraints of our ecosystem, and holding steady on the need for this work.

But we were finally ready to build.