DaoDash

A dashboard to keep track of governance within and between DAOs

DaoDash

Created At

ETHAmsterdam

Project Description

DAOs increasingly move away from one unified governance process and start to move decision making authority to sub-groups. At the same time, Snapshot remains the go-to solution to elicit information on how the community feels about different topics. However, Snapshot doesn't really cater for this diversification of governance within a DAO. The main bottleneck is the fact that it is not possible to use different voting strategies for different proposals. A voting strategy is the method that is used to vote on a proposal, e.g. token voting, one-person-one-vote, quadratic voting etc. The diversity of tasks and social constellations can hardly be solved by a one-fits-them-all voting strategy. A commonly used workaround is to create multiple snapshot spaces, each with their own voting strategy. However, this creates "governance silos" as it becomes increasingly difficult to keep track what is going on within these different spaces. At the same time, it is very hard for passionate web3 aficionados to keep track with all the proposals of DAOs that they are involved with. With DaoDash we want to address both problems. It serves as a Dashboard where DAOs can unify multiple snapshot locations in one place and set up one EPNS channel for all of their snapshot spaces. Voters get notified if a new proposal is created, only if they hold voting power on the new proposal. They can keep track of proposals from multiple snapshot locations while being able to easily recognize the ones that they have voting power on. Ultimately, we hope that by making it easier for users to keep track of proposals and by making it easier for DAOs to deploy different voting strategies, this will overall increase engagement and quality of decision making.

How it's Made

This project consists of two parts: a Figma prototype that embodies the ultimate goal, and two code repositories that lay the technical foundation for its implementation. The technical architecture is as follows: A NextJS-based dapp interacts directly with the snapshot backend. It pulls information about proposals/votes/spaces from snapshot, but also allows for submitting new proposals. The dapp has integrations for Metamask and WalletConnect. Because we want to unify multiple snapshot spaces within one Dashboard, we have to save the information about which snapshot spaces belong together somewhere (as well as some more general information such as icons, descriptions). For this we use a simple Express (JS) backend. If a user connects to the dashboard, we would have liked to check their token holdings, e.g. via the etherscan API, or by querying the blockchain for the user's token balances for those tokens which are used for governance in the respective dashboard, so that we can indicate to the users which proposals are particularly relevant to them. We didn't quite manage to implement the EPNS integration, but the plan would have been as follows: when a user creates a new Dashboard they have the option to create a new EPNS channel. Using the dashboard specific information that had been entered by the user before, the dapp would have uploaded a descriptiion to IPFS. The IPFS hash would have been used to create a new EPNS channel by directly calling the respective function on the EPNS core protocol. Thiss would have created a new channel. Then we would have implemented a hook that would have made sure that everytime when a new proposal is created for one of the spaces that belongs to a dashboard, the dapp makes a request to the backend, which in turn would have sent out an EPNS notification via the EPNS backend sdk. URL to second repo: https://github.com/fabianschu/huudi-server

background image mobile

Join the mailing list

Get the latest news and updates