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