TEMP CHECK - Rapid Prototyping @ Gitcoin 🧪


In this post, I would like to talk about the history of new market exploration & product innovation at Gitcoin. I will then float some ideas around Rapid Prototyping. A Rapid Prototyping pod/workstream. could be in charge of creating value for Gitcoin by way of 0 to 1 product innovation.

History of Product Exploration at Gitcoin 2015-2023

Gitcoin has had a rich history of exploration in the web3 design space through the years. As the market cycled through bull + bear + back again several times, Gitcoin has explored the design space organically.

Here is what the history of product exploration at Gitcoin looks like in my minds eye (and in the case of 2015-2017 cycle, what led to the creation of Gitcoin):

Some patterns I see:

  1. In bull markets, I’ve typically shepherded many bets forward. By casting multiple bets, we are able to see what sticks without going all in on one idea…
  2. In a bear market, there is hard work to do regarding which projects to focus and double down on.
    1. This has meant that projects that are ngmi get shut down (codefund, Gitcoin Labs 1.0, original dGrants, etc).
    2. This means that projects that are gonna make it, but are not within Gitcoin’s core focus (hackathons, KERNEL), get spun out…
    3. What is left is what we focus on + double down on in the next cycle.
  3. Repeat until mission achieved!

Now that Gitcoin has matured into an organization of dozens of contributors + thousands of users…. We have an opportunity to double down on maturing the projects that have been created by this cycle of innovation.

In many ways, maturing/scaling products is very different from proving product market fit for them. For example, I am very good at bringing products to market rapidly (skills needed: code quickly, validate market needs, get the first few customers), but I am very bad at scaling them (skills needed: code documentation, writing clean code, staffing them, designing an org that can serve them).

I believe that the existing product workstreams can continue to bring the latter skills (scaling Grants products at Gitcoin), but that there might be an opportunity to complement the scaled products with prototypes that complement them (especially when they are both built on the same Allo Protocol v2). One good example of this is https://reportcards.gitcoin.co/ - which is a total prototype, but compliments the more mature Grants Stack very wall.

Past Successes

  • Gitcoin Labs 1.0 (2019)
  • Gitcoin 2020 spinouts
    • Hackathons
    • KERNEL
  • Moonshot Collective Era (2021-22):
    • Moonshot Bots: Raised $3m
    • ProofofStake.gitcoin.co - Raised $1m
    • ID Staking - 1m GTC Staked, foundation of ID staking v2
  • Supermodular Era (2023):
    • Report Cards - Made it easy for Round Managers to show progress.
    • EasyRetroPGF - Got us into RPGF, new market trend.
    • Grants-ETL - Foundation for data scientists + created conditions for Cluster Mapping to take off.
    • Hypercerts - we assisted in the conception/launch.

Past Learning Experiences

  • Gitcoin 2020 era
    • Codefund
    • Gitcoin Quests
    • Gitcoin Kudos
    • Themes: Many of these died on the vine because we could not support them in a small team that was already spread across Hackathons/Grants/KERNEL. If we had been able to build teams around each product category, I am curious to see if in that counterfactual version of the world if Kudos could have become a POAP competitor, or Gitcoin Quests could have become a Rabbithole competitor.
  • Moonshot Collective Era (2021-22)
    • Coordination Party Kit
    • Partnership Protocol
    • Themes: Lots of builders with energy, but we hired the wrong project manager. Gitcoin was also fairly aimless at this point (had no essential intents) so MSC was similarly fractured in attention. Once Owocki left it was a long slow wind down into becoming GPC. But a few ppl still here!
  • Supermodular Era (2023)
    • PGN Bridges
    • Quadratic Honey
    • Quadratic Yeeter
    • Funding.Social
    • Many more…
    • Themes: Hard to build on top of Allo/Grants Stack when its wet cement. We had a higher hit rate than before tho. Lots of learnings that led to Gitcoin Labs.

Rapid Prototyping Workstream (RPW) in 2024

Now that we have studied the history of innovation in the Gitcoin ecosystem, I would like to show off my latest thinking about Rapid Prototyping for the current era.


Why do this?

  • Create Value for Gitcoin by Rapid Prototyping in Highest Value Areas.
  • Create Alignment among stakeholders.

How does it serve Gitcoin?

  • Acts as a 0-1 booster/assist for 0-10 product workstreams
    • (0 to 10 involves going through 0 to 1).
  • Gives Gitcoin More Agility in Rapidly Changing Market
    • If we are successful, we preempt the next hot trend that has historically left Gitcoin behind (some good examples of things that have traction and that have left Gitcoin behind: MACI, RPGF, Hypercerts).

Success KPIs

  • Higher Hit Rate than past Rapid Prototyping workstreams. Hit rate 5/10 instead of 2/10.
  • Hits are bigger hits > base hits

The Process

  1. Idea Conception - this is already happening normally.
  2. Prioritization.
    1. The Priority Council meets on a regular interval to stack rank the ideas.
    2. An output of this step is alignment. The priority council, instead of working in 5 different directions, we can now align on less directions.
    3. Emergently, executive sponsors will emerge to fund active builds.
  3. Active Builds
    1. Kevin will maintain a roster of builders who are web3 native.
    2. He will make intros to them.
    3. Others are welcome to do the same.
    4. Whomever is the executive sponsor of an idea coming out of prioritization brings their own budget for the build.
  4. Graduation
  5. Projects will do a retrospective and decide to
    1. Sunset ⇐= default
    2. Hand over to workstream
    3. Be given a maintenance budget


Initial thoughts: $0/mo in overhead. Each Priority Council BYOB (Bring Your Own Budget) to fund on a project by project basis.

I wanted to specifically avoid having a slush fund ppl can draw from. BYOB aligns incentives between the ppl who pay + those who get value.

Initial Priority Councils.

  1. Grants: Meg, Owocki, Kyle, Rena
  2. Passport: Jeremy, Kyle, Rena, Owocki
  3. RegenLearnings.xyz: Kevin, Carl Cervone, Jonas
  4. Allo: Nate, Zakk, Kevin

If we are successful in this,

  • throughput should roughly equal costs
  • confidence can grow/scale linearly to budget.


  • Cultural aversion to 0 to 1 style working in 1 to 10 style workstreams.
  • Lack of sense of urgency to compete more aggressively or be more agilie in market.
  • How do we open up Allo/Grants Stack to more community contributions?
  • Talent might be tight in a bull market.
  • Cultural differences between 0 to 1 teams and 1 to 10 teams. In case of a handoff from 1 workstream to another, the ability to knowledge transfer between RP builders + next builders may be a risk.

Open Questions

  • Should RP be a standalone protocol/process or is this a new team we’re forming?
  • If it is a new team, what should its budget be, and how do we solve for accountability?
  • If you are a workstream lead, do you need RPW enough that you’d request a line item in you budget for it? @meglister @Viriya @kyle @deltajuliet @jeremy

Please give me feedback on this Temp Check post!


Many projects have a Foundation + Labs + DAO setup to since it has proven to be an effective way of coordinating talent while minimising governance overhead.

  • A lot of the dev work can be done more efficiently in a centralized company setup like Gitcoin Labs.
  • While Labs can be a core contributor to the DAO, it does not have to deal with the same governance overhead and can raise funds from the market.
  • It makes sense for this entity to be focused on 0 to 1 and handover products with PMF to the DAO for going from 1 to 10.

I do like the idea of an in-house special forces team that workstreams can draw upon for rapid iteration of ideas. I do wonder how we keep availability of such a talented team if there is no dependable sustenance that they draw.

It may be helpful to draw an analogy to the state of investigative reporting. with the decimation of ad dollars for print media, these reporters faced the first newsrooms cuts. So do we have less adversarial journalism?

Not quite. Because nonprofit newsrooms stepped up. So investigative reporting nowadays usually has 1 reporter from NYT or WaPo and ~5 from a nonprofit newsroom like ProPublica.

The NYT or WaPo here would be the workstreams while the ProPublica would be Gitcoin Labs. Ideally, Gitcoin Labs is able to raise its own funding similar to the nonprofit newsrooms. We would still however require skin in the game from workstreams for it to work, either in the form of assigning team members to work full time during the rapid sprint period or also giving a budget to Labs.

I did have a question though on overlapping roles - since there is already an entity like Gitcoin Foundation that has done rapid iterations of strategic projects like PGN, how is Gitcoin labs different from the foundation?


In the $0/mo (no overhead) budgeting scenario for Labs, teams BYOB to Labs. So as long as Grants Stack/Allo/Passport are putting $$$ in, there will be enough funding going through Labs.

In a scenario in which a team of devs is kept on staff (or perhaps on a recurring stipend), talent retainment will be easier. But I’m not quite sure how to structure that.

Afaik the Foundation is chartered to be the legal/administrative wrapper for the DAO. Whereas Labs would be chartered more for rapid experimentation.

(Keep me honest Foundation team members, but it seems like PGN was a one-off strategic project, but lmk if wrong. FWIW some of the folks that built parts of PGN, like @carlb, will be contributing to Labs )


I’m in support of this workstream – I like that it leverages your strengths on rapid prototyping and innovation while remaining lean and staying tuned into business priorities through the Priority Council. I would budget some $ each season to fund Grants-related builds through this. In using previous engagements (like bootnode/direct grants) and % of product-related spend (~5-10%) as a benchmark, I’d plan to budget 150-200k annually.


Sounds like a good dogfooding project to start with. RFP flows are supported in AlloV2 - not sure if there’s a frontend available that supports the flow from RFP to milestone based payment?


is EasyRetroPGF not the front end to PGF part of the Allo stack?


We are considering building Allo into EasyRetroPGF soon.

Yes I agree this is a great dogfooding opportunity. We can either use Grants Stack for this (I think that @meglister does grants through GS already, so maybe Ill copy her strategy ) or another Allo based webapp.


Some assumptions + potential hybrid model:

  • Kick-off with RP as a protocol/process without the overheads of a full-time team before ironing out a few end-to-end lifecycles from conception to graduation
  • Ideas can flow top-down from the council or bottoms-up from RP builders pitching a concept
  • RP Builders own early risk until the potential is proven to the council
  • Non-linear rewards to incentivize impact to user and business by staying vested in making the next-in-cycle team successful, not just successful 0-to-1 hop

The milestones below are just a sample indicative of progressively reducing risk and increasing reward for an idea that gets built and handed over to the workstream.


I’m really excited about the spin up of this entity. The way that @owocki listens and responds to market trends is like no other and I think it is his super power. I saw him lean into easyRPGF and take that from 0-1 and I’ve also seen him develop offerings that add a lot to the customer experience of Grants Stack.

Really excited to have this kind of team focused on innovation and experimentation at the DAO so other teams can work on 1-10 work.


I’d avoid handover at all costs unless this is an administrative trick of who-pays. As much as possible I want to maintain continuity of context from the people who pick things up to operationalize. This is often not possible because of different styles requirements of the work anyway, but I wouldn’t canonize that process