Allo 2.1 => 2.2

[owocki]

Future of Allo

Authors: Ed Fleming, Kevin Owocki

Summary

TLDR: Protocol First => Product First

We collected a ton of feedback from partners over in our devrel channels, especially hackers from the devcon hacker house, and the message is pretty clear: There is conviction for design space, not conviction for Allo protocol 2.1. Allo 2.1 isn’t solving the problems that people have, and the purpose of this document is to talk about Allo 2.2 (which I define as whatever we ship by ETHDenver 2025)

We’re going through the journey of what to do with that information, and the conclusion we’re trending towards is to pivot from/to:

1. Onchain always => Onchain when its needed
2. Protocol First => Product First
3. Long development cycles => Faster OODA Loops which will mean faster iteration which will mean more success in market

Full Details

1. Where we’ve been
   1. QF => Multi Mechanism
      1. The market is going multi-mechanism! We were aware of this already. In some ways we’re still playing catchup with “how” to do it.
   2. Conviction for design space, not conviction for our solution
      1. “I get the need for a protocol but I’m not gonna use yours”
      2. DevEx subpar
      3. While Allo is composable, we don’t actually have modules for what ppl want to do.
      4. Too much complexity, too much centralization through Allo.sol, not enough ROI.
      5. Fee model is wrong. It shouldn’t be “gitcoin takes $$$”. It should be Gitcoin gets paid when the Funding Infra provider gets paid.
      6. Cool new things don’t fit the model.
      7. [Futarchy/Retro Funding provider] doesn’t want to touch us.
   3. The world has changed. What’s winning in market is lean/narrow experiments with up & coming founders at the helm.
      1. LottoPGF
      2. Protocol Guild
      3. Butter / Futarchy
      4. Impact Metrics Funding
      5. Dev Tooling Guilds
      6. We can empower them through next-gen Allo tools. From a dev tooling perspective, thats our customer.
2. Where we’re going
   1. Protocol First => Product First
      1. New emphasis is on solving for customer need first (main customer: round operator/funding deployer needs).
      2. Simply build the Contracts we need for our products (if it needs contracts at all)
      3. Ed Direction/ Visuals => full stack app focus
   2. Onchain always => Onchain when its needed
      1. (Deploy a pool => fund a pool => payout pool all onchain) => (deploy in memory)
      2. Only need onchain primitives for onchain things like staking or token transfers.
      3. While Allo is composable, we don’t actually have modules for what ppl want to do. Ex: Drips/superfluild payout, hats gating development
      4. Use protocols that already exist
      5. A la carte usage of allo protocols
      6. Don’t design/force products to be onchain if they don’t need to be
      7. Partners want to leverage a suite of protocols, it should be easy for Allo to fit in
      8. Onchain fee switch was the wrong approach. We could share fees with operators first and get paid when they do. And get paid upon payouts or via services.
3. Faster OODA Loops => faster iteration => more success in market
   1. Now that we dont need to do onchian primitives as often, no audit time/$$ cost = faster iteration baseline.
   2. We should always be seeking ways to iterate faster. Some examples:
   1. AI Augmented Software Develoment
   2. beta.* subdomains to show work earlier in dev lifecycle.
   3. Build our reusable app scaffolding for faster iteration.
   4. See Ed Visuals
   5. Gitcoin Services w docs/DevEx
      1. (Checker, SDK)
   6. Build out modular components for faster iteration.
   7. UI Kit
      1. Modules for project view, checkout
   8. Onchain
      1. Custom Strategies/ Voting
      2. Distribution modules

[gnomadic]

I’m really excited about this strategical shift and what it’s going to enable for Grants Lab Engineering.

Historically, we’ve started with the protocol—a Solidity implementation of an allocation strategy—and worked backwards to build the product around it. With this shift, we’re flipping that approach. Now, we’ll focus on the product itself—and what it enables—rather than starting with how it works.

Going forward, with this strategical shift, we are empowered to focus on the product itself, and what it enables, instead of “how” it enables.

This diagram attempts to represent our new mindset:

The vertical lines in the diagram represent our product offerings. Checker is green because it’s rolling out now (spoilers), and Retrofunding is light green because it’s next. What comes after that will depend on how the market evolves.

The horizontal lines represent shared challenges we’ll always face, like UI design, poll-based services, push-based services, and on-chain operations.

Instead of forcing every product to fit into a single framework, we’ll solve these challenges in ways that make sense for each product. This will let us build faster, more focused, and simpler solutions.

Stay tuned for more on how this comes together.