Integrating Allo Protocol into Giveth

SCROLL TO THE BOTTOM FOR THE TL;DR :point_down:


Allo Moto :robot: :wave:

As part of the ongoing SuperFluid integration we would like to integrate Allo Protocol’s project registry system. This presents a great opportunity to collaborate with Gitcoin and push forward a collective vision of a universal registry of public goods projects and impact analysis.

However this also aims to solve a more nuanced problem relative to Giveth.

Problem

Currently on Giveth we have an interesting setup where a project owner - the person who logs into Giveth & makes a project - can be a different address than the one that actually receives the funds.

And this recipient address can change at any time, the project owner just needs to change the recipient address and we update our database with this information, no permission required.

This creates a tricky situation where when we add new layers onto Giveth such as SuperFluid and even GIVfi at some point because there is no connection on the blockchain to say: “this address is the project owner for X project with Y recipient address.” . Not having this relationship on chain makes it hard/unsafe to give extra permissions to a project owner to manage certain advanced block chain actions for the projects they own.

Regarding SuperFluid this is the process for receiving a stream of tokens and being able to actually claim the underlying regular tokens to the recipient address (e.g. to turn in your sDAI (Streamable DAI) donated your project into regular DAI that can be off-ramped or used for DeFi), and how to handle when a project owner needs to update their recipient address.

We ran into the same issue during GIVfi development and we couldn’t find a great solution until eventually the product was shelved… for now.

Then Kurt introduced me to Allo Protocol v2.

Solution

Allo Protocol is a smart contract system developed by Gitcoin, it consist of two parts, the Allo contract for managing pools, treasuries and rounds and the other part is the Registry, Giveth will only focus on using their Registry (along with Anchor.sol).

You can find these contracts on Github here:

Using their registry will allow Giveth to register our projects on-chain, which will establish who the project owner is, allow us to give it a name, add addresses of its members and even attach data for it from IPFS. However, the most important & useful part for us will be able to deploy an “Anchor address” which will act as a sort of go between for the project owner & the recipient address.

This anchor address will give us more options in terms of doing those advanced blockchain operations and make our user experience in general WAY BETTER for this kind of stuff in the future.

Other Cool Stuff

Another cool side effect is that with this process we can create a shared registry of public goods & impact projects with Gitcoin and many more protocols by using the same registry contract.

This will open up many possibilities of doing impact measurements & analytics on top of creating a source of truth & transparency for the web3 public goods ecosystem.

The Gitcoin team is nearly completed a professional audit of their code & it’s awesome we can piggy back off of well written & reviewed smart contracts to improve Giveth.

Gitcoin is also willing to put in dev work as needed to make this work for Giveth’s unique quirks.

Implementation

For most projects, having all of this fancy registry & anchor address whatever is more than they need, I believe it adds needless friction at this point to do it for every single project.

We as Giveth also don’t want to force our users to join this registry nor be responsible for deploying thousands of on-chain registries for each Giveth project.

My intention is that we add it as an optional step into the project creation flow, user’s can opt-in to create an entry into the Gitcoin registry once they have completed creating their project on Giveth.

We will also add it into the flow for when a project receives its first recurring donation using SuperFluid since this is the original reason we needed it.

Risks

There is a risk to note; since Giveth will be using contracts developed & owned by another entity that we could risk having breaking changes to our smart contract system if Allo protocol makes any updates to the implementation contracts - which is to say - changing the code base to make it do something else or do the same thing, but in a different way.

Gitcoin’s team told me they are implementing an AIP process (similar to how Ethereum introduces changes through EIPs) so we will have ample opportunity to weigh in on proposed changes and be aware of any upcoming breaking changes.

Here is there documentation on this AIP process:

The other side of the coin is that if we need to make changes to accomodate features we want to add, it could add complexity. Since we do not have direct control over the code we could not change the contract system to directly meet our needs, we may have to engineer something more complex as an added layer to Allo Protocol.

I don’t foresee any tough problems but another thing to consider!


This is sort of a long-winded mostly technical thing but I wanted to put it out here for transparency, comments & questions!

Let me know what you think :smiley:

TL;DR

  1. Integration Goal: Integrate Allo Protocol’s registry along as part of SuperFluid Integration for a universal public goods project registry.
  2. Problem: On Giveth, project owners and fund recipients can have different addresses, with no on-chain connection.
  3. Allo Protocol: A smart contract system by Gitcoin to manage pools, treasuries, and registries of public goods.
  4. Solution: Use Allo Protocol’s Registry to register Giveth projects on-chain, establishing clear project ownership.
  5. Anchor Address: A bridge between project owners and recipients, improving user experience.
  6. Shared Registry: Collaborate with Gitcoin for a combined registry of public goods and impact projects.
  7. Gitcoin’s Support: Their team is auditing their code and willing to assist Giveth’s integration.
  8. Implementation: Add registry as an optional step in Giveth’s project creation, especially for SuperFluid donations.
  9. Risks: Potential breaking changes if Allo Protocol updates its contracts.
  10. AIP Process: Gitcoin’s method to introduce changes, allowing Giveth to be informed and provide input.
6 Likes

This kinda blew my mind, I couldn’t stop thinking about the future Gurves, I believe superfluid and eventually GIVfi are the foundation for a bigger thing.

I have many questions on how this would work from an UX perspective - working at the moment with the gnosis safe interface there’s plenty of distinctive code that we have to adapt to reach a goal, in other words is not very composable, would love to see a basic current use case but can’t find any besides their idea to bring it for the grants.

Love the project, just thinking how the composability part would work in the UX side of this, what an Anchor address would look like and how a DAO (gurve) may use it. Will keep reading.

Thanks @mitch and kurt for bringing this up

3 Likes

:laughing:

from Imgflip Meme Generator

Silliously, though, this is my favorite proposal in a long time because it addresses a critical usability feature in Giveth, allowing the separation of project administration and access to funds, while also enhancing our implementation of it to provide:

  • A unique identifier for the project that is neither the administration wallet OR the fund-holding wallet so that either can be changed
  • The ability to easily join project registries between our aligned partners in crypto philanthropy, which we know can be challenging as we saw bringing in the Giving Block projects.
  • Reduced overhead for adding functionality by leveraging of open source ecosystem tools built by others, just as we offer our own tools to be leveraged as well.

Boom, we get better together.

I LOVE THIS.

3 Likes

Hey !

I’m the tech lead for Allo and wanted to give a quick update on our thinking based on our call with @mitch and Kurt
After hearing out the use-case to allow optional creation of an on-chain representation , we went back to the drawing room and came up with a proposal on how to allow Giveth to create profiles

  • by the owner themselves
  • when a contribution on behalf of the owner

The second usecase was something which we realised might be something which many products may want to use and figured we’d bake this into the protocol as opposed to having a middle man contract.

Here is a PR with those changes chore: profileId is generated using owner by thelostone-mc · Pull Request #326 · allo-protocol/allo-v2 · GitHub

This would make the integration into Allo for Giveth that much simpler allowing Giveth to enrich the registry by adding profiles but also allow existing users from Gitcoin (and other products as they migrate) to use their profile for Giveth

1 profile to manage them all kinda thing :smiley:

5 Likes