[Ideation] SCP-152: Extend ShapeShift DAO with EIP-4824

Incubation post


If passed, this proposal will extend ShapeShift DAO to EIP-4824 by deploying a new registration contract through a contract interaction with the EIP-4824 factory maintained by DAOstar.


The EIP-4824 standard defines common interfaces for DAOs via daoURI, akin to tokenURI for NFTs. In order to adopt EIP-4824, ShapeShift DAO will need to deploy a new smart contract that stores the DAO’s daoURI.

Note that adopting EIP-4824 does not require any parameter changes to ShapeShift’s existing DAO contracts, nor is there any cost besides gas to call the factory contract. The proposal does not in any way change the way that ShapeShift’s governance works. DAOstar, with the help of a recent grant from Optimism, will help generate a daoURI to help ShapeShift adopt EIP-4824.


The motivation of this proposal is to build a much needed piece of infrastructure for the DAO ecosysystem.

The absence of a DAO metadata standard has been holding back the ecosystem. Many new DAOs and DAO frameworks have zero visibility on aggregators, most tooling providers have a hard time ensuring compatibility for different types of DAOs, there is no comprehensive, self-maintaining registry that stores DAO metadata, etc. EIP-4824 is an approach to solve all these problems and more.

When a DAO adopts EIP-4824, it deploys a registration smart contract that holds a daoURI. This daoURI contains information about the proposals, members, governance framework, contracts owned, etc. of the DAO. It is up to the DAO to decide what to publish via its daoURI. Even registering an empty daoURI is a significant step towards the much needed standardization in the ecosystem as it announces to every indexer that the owner of that registration contract is a DAO and it needs to be indexed.

Adopting the EIP-4824 standard will enrich the on-chain information availability of ShapeShift’s governance contracts, making it easier for existing and future DAO tools to seamlessly interact with the contracts. Some of the tools that are digesting or committed to digesting this enriched information include Snapshot, Tally, Etherscan, DeepDAO, and other members of DAOstar One

  1. .

    Recent EIP-4824 Updates:

    Snapshot X, Aragon V3, Moloch V3 and multiple other governance frameworks have integrated EIP-4824.

Optimism awarded DAOstar a mission worth $100k to help DAOs on Optimism adopt EIP-4824.


The EIP-4824 registration factory is located at 0x37df3fc47c1c3a2acafd2dad9c1c00090a8655bc. If this proposal passes, to upgrade to EIP-4824, execute the following call to this contract:

Call EIP4824RegistrationSummoner.summonRegistration(salt, daoURI, manager, contracts, data)

In the above contract call, the metadata needs to filled in. DAOstar will help ShapeShift build a daoURI. It can, for example, contain data from just ShapeShift’s Snapshot. It may also be partially empty, with the intent of updating later. A daoURI for ShapeShift is given below. More data can be added to the daoURI easily, including a link to ShapeShift, a link to the governance doc, a list of contracts owned by the DAO etc. We encourage the community to comment on this.

Demo daoURI for ShapeShift: https://api.daostar.org/immutable/QmT2bpbRtf2b3kpEoABY8iozSfk4N6fzczUR6EKDYyyHEK

New clones are deployed to predictable addresses using the message sender and a bytes32 value combined as a salt.

Transaction simulation: you can see that the above call successfully deploys ShapeShift’s registration contract to 0x58e593f2100fa06da34935c1b35fd78aaa32479a


  1. Adopting EIP-4824 would greatly improve discoverability and interoperability for Shapeshift DAO. For example, consider the DAO’s multisig. Etherscan currently would not be displaying any info about the DAO which owns that multisig. Using EIP-4824, an indexor like Etherscan would be able to access ShapeShift DAO’s metadata and enrich its profile. After speaking with countless DAO tooling providers, many of whom are DAOstar members (there are 50+ DAO Tooling providers in the DAOstar Round Table), the existence of such a standard would greatly improve the ecosystem.

  2. Access to infrastructure that is being built on top EIP-4824. For example, Gitcoin is building a grant management standard; Karma, Tally, Uniswap, etc. are building an on-chain delegate registry, etc. Adopting the standard would mean access to all these important pieces of infrastructure and more that'll come up.


  1. Gas costs required to call the registration factory.


For: adopt EIP-4824

Against: do not adopt EIP-4824

Thanks for the proposal!

Regarding the Incubation that mentioned a Manager, this seems to do away with it or at least not mention it, does that mean we would need to ask our multisig Signers to make changes to the daoURI or to designate a Manager at a later time?

I’m generally in favor of this standardization, we could even at some point become a consumer of this data if we ever decide to provide a similar service as one of our competitors, Zapper, which maintains their own list of DAOs.

Thanks for your question, @Fireb0mb1.

You’re correct that I didn’t mention a Manager in the proposal because we’d previously discussed setting a relevant ShapeShift Workstream as the manager. To set this up, their address would be included in the call to EIP4824RegistrationSummoner.summonRegistration(salt, daoURI, manager, contracts, data)

This designated manager would have the sole responsibility of updating the daoURI. Either the manager or the DAO contract deploying the registration (which I’ve simulated as eth:0x90A48D5CF7343B08dA12E067680B4C6dbfE551Be) would be able to make these updates. Importantly, the manager role can be revoked at any time.

I would appreciate feedback from you and others on which Workstream would be most suitable for this role. Perhaps the Operation Workstream, as with the Push Protocol?

Additionally, the DAO can add more admins in the future by calling the deployed registration contract, if desired.

Thanks for clarification! (for snapshot, maybe add ‘manager, if desired, to be designated by Shapeshift DAO’ sorta thing. leave it open but in the DAO’s control. :wink: i would like some risk assessment (on our end) before implementation. (as i have no clue myself) so someone i trust.

with that sign off, seems ok to me.

Operations is a good choice, but team has shrunk a bit, have to make sure not overwhelming with small things. Leaving it open to DAO to pick, we can change who is manager (or add more as i see thats possible)

Thanks for proposal!

gm @amanwithwings, thanks again for this proposal. i’ve heard some contributors mention in private convos that they are not clear on what the use case for this is and what the benefits would be, so while this may not have a financial cost, it still may not be worth the time and effort to implement. i shared the benefits you listed here, which i think are valid, but if there are any others worth noting, please note.

@Giantkin re potential risks:

only risk i’m aware of is that the ‘dao manager’ could post something bad (purposefully or not), and any apps/interfaces that use the data would then display it. not aware of any smart contract risk because we’re not depositing funds nor approving any allowances on ERC20s from the treasury.

@amanwithwings provided a tx simulation too that everyone can review to see what states change when that gets executed; can you share a link to this simulation on Tenderly please? not an auditor though and would be curious to hear if there are any other risks worth noting. I did hear that if we do do this, we should not user daostar’s domain for the URI. i also think it’s worth designating a workstream or workstream leader to be the dao manager to mitigate this risk; the only added burden is needing to execute the transaction any time we want to update our info, and i imagine that won’t be very frequent (maybe once or twice a year?)

This seems like more risk than reward and also a distraction from what the DAO is focusing on.

I would not feel comfortable with any arrangement that had a non-DAO contributor acting as a manager or signer on behalf of the DAO. If we were to manage updates, having a multisig would be a preferred method of security to assure prevention of malicious uploads.

I don’t see how there is a utility for this information to be served via web3 services specifically, nor any benefit the DAO from doing so at this time.

I believe the added potential risk at worse and added distractions at best (if all responsibility is assumed via a DAO controlled multisig) are not currently a benefit to the DAO and our missions currently.

If this service sees more adoption and a future utility that could be beneficial to the DAO, I would be in favor of considering it at a later time.

{:ShiftEnter=>true}Thanks for your thoughtful concerns, @Tyler2. I understand where you’re coming from, but let’s dissect these issues.

Risk vs Reward: You mention the proposal seems more risk than reward. I’d love to know what specific risks you’re thinking of. We suggest a ShapeShift Workstream or multi-sig to manage the responsibility.

  1. There's no question of external control.

Utility and Relevance: Prior to contributing to DAOstar, I used to lead growth at DeepDAO

  1. , one of the leading analytics engine for DAOs. I still remember the countless hours we spent digging through fragmented, scattered data on multiple DAOs and how difficult it was to accumulate even basic information if the DAO had a few different treasuries, more than one governance module or presence in multiple chains. Imagine doing this for 20,000 DAOs, some of which are not even on EVM native. This is a common problem shared by all tooling providers that support a lot of DAOs and it's only going to get worse as the ecosystem grows. EIP-4824 offers a clean, standardized solution for everyone.

Immediate Benefit: This isn’t just about solving a future problem; it’s about setting the stage for a more efficient, more transparent DAO landscape. We have the backing of some of the biggest names in the industry: Ethereum Foundation, Solana, NEAR, Polygon, Optimism Foundation and so on. They’re not just jumping on board for the fun of it; they recognize that the need for this standard is urgent. Also, a ton of infrastructure is being built on top of EIP-4824, with participation from teams like Gitcoin, Tally, Uniswap and OpenZepplin. You can find the full list of members here:

  1. https://daostar.one/

Resource Constraints:

  1. With our Optimism grant, ShapeShift DAO would spend zero additional resources for a transaction that would enrich the entire DAO ecosystem.

Now let’s talk about timing. Snapshot X, Aragon V3, Moloch V3, DAODAO, Superdao, Kali, etc have adopted the standard. Still I agree that adoption is in its early stages. But that’s exactly why now is the time to act. We have a chance to be among the pioneers, shaping the landscape for every DAO that follows.

I invite everyone, including all core contributors, to consider the larger picture and the long-term benefits. Let’s not postpone the future; let’s build it.

@willy , EIP-4824 promises to significantly enrich the DAO ecosystem. Here are leads of both Aragon and DAODAO speaking about its benefits for the Optimism grant: https://youtu.be/fPrVsMW05Ho?si=JDMsEIpafnrxfhWr&t=76.

The unfortunate thing about standards is that they operate a level beneath the typical consumer. Consider Bluetooth as an analogy. If every manufacturer used a different frequency band, Apple devices couldn’t connect to Samsung ones. You and I do not need to concern ourselves with the wavelength our phones are transmitting, but in the early-stage web3 world, we’re both creators and consumers. That obliges us to think deeper, to ensure foundational infrastructure exists to support the ecosystem as DAO numbers soar from 20k to potentially a million. EIP-4824 (or some metadata standard) is one such crucial element.

RE Tenderly, here is the link: https://dashboard.tenderly.co/amanwithwings/project/simulator/73a3d0cf-8171-4097-b749-440456c96cc3

For the daoURI, you’re welcome to not use DAOstar’s domain. This will truly decentralize data publishing, and we’re fully behind this move. While this may require extra dev work, we’re happy to assist. Registering even an empty or partially filled daoURI is a significant step toward standardization; it signals to every indexer that the contract owner is a DAO that needs to be indexed.

As for managerial updates, they would be infrequent. A daoURI only needs updates when there are significant changes to the published metadata, like a V2 governance document release, for instance.

@willy , I just spoke to our front-end dev and here is some interesting info:

DAOstar does not host the data for daoURIs. DAOstar API service handles the registration and validation of the submitted DAO URI fields. After validation, it stores it on IPFS and gets a CID. The DAOStar API is just fetching data from IPFS and displaying it. To get IPFS CID from DAOstar API, look for (the format of the URI is https://api.daostar.org/immutable/ ). Once you get the CID, you may use any other IPFS gateways like IPFS.io, Pinata or host it yourself. Hope this helps.

thanks @amanwithwings, really appreciate the answers and will gladly vote Yes as long as a ShapeShift workstream is willing to accept the DAO manager responsibility (or potentially we just set this to the DAO treasury if no workstreams volunteer). Awesome to see that the standard is already being adopted by so many leaders in the space, and appreciate you making this proposal so shapeshift so we don’t have to figure all of this out ourselves :slight_smile:

Thank you for the support and feedback, @willy.

you bet, hope to see you at the governance call in ~1 hour @amanwithwings

Ah bummer I missed it😕! I’ve marked the next one on my calendar

Thank you all for your support and feedback on this proposal! ShapeShift is your DAO, and I fully understand the caution exercised by some community members. I want to reassure everyone that EIP-4824 is an extremely low-risk proposal. It operates independently of other components in the ShapeShift system and doesn’t alter any existing configurations.

Now that the poll has concluded, could someone guide me on the next steps?

Hello, happy to see the Ideation phase pass with a majority of Yes/Yes with changes. I do think the issue with most standards is getting the ball rolling at first, and I do see value in trying to index DAOs and their attributes/members/proposals on-chain. If ShapeShift can help with this at the cost of a single initial transaction to record basic information about the DAO I’m all for it.

Since there seem to be a large portion of voters who want changes, you should add the ones you think are in high demand (from what I read mainly it’s about designating a Manager address controlled by one of the DAO’s Workstreams) to your final proposal and submit the updated proposal with the same SCP# on our SnapShot (minimum 3 days of voting but I’d recommend more): https://snapshot.org/#/shapeshiftdao.eth

You could attempt to get in touch with our Operations Workstream (on Discord, check the #role-selector channel to reveal the Operations Workstream channels) and see if they have an address ready for managing such records/systems. I know at some point they have setup something to manage our Push Protocol channel, or maybe @TylerShapeShift could answer here. If it’s not possible with Operations, I’m not sure which other Workstream could do it, in a way it’s a form of Marketing to assure our presence in public listings… and if I remember correctly Marketing has already been delegated that power from Operations for Push.

Or maybe leave it open and just say ‘shapeshift’ to manage, and we can set it up from our side as we see fit. (if its ‘designated’ to a WS, then we technically need a proposal to move it to another. setting ‘shapeshift’ means we could move it around etc. or just a small sub group, etc)

just my 2 sats.

oh and when/if you do the snapshot make sure to drop a link in here, and in the snapshot (top?) link to this discussion.

Everything @Fireb0mb1 said is correct. My preference would be a multi-sig address with DAO contributors owning all addresses in a 2 of 3 configuration. Perhaps this is a multisig that could be co-owned between Marketing, Operations, and Product (Or Marketing and 2 Operations addresses) to allow the relevant Workstreams access to publish changes when necessary.

More than happy to coordinate this in discord, or get consensus here in the forum.

Ahh sounds good! Let’s continue on Discord

Edit: I’ve changed the numbering to SCP-154 as someone mistakenly created another proposal under SCP-152.