EtherGov

This platform was developed as a PoC for the ETHOnline 2023 hackathon. Feel free to contact @delken_ on Twitter if anyone is interested to discuss the possibility of taking things further.

PROBLEM

There exist huge technical barriers for prospective evangelists to launch a DAO in the first place, specifically the complexity of initializing (and managing) their own set of contracts — whether through forks, integrations, or even building from scratch. In addition, DAOs are not chain-agnostic by nature: it is currently not possible for a DAO to engage in any arbitrary transaction on a chain that is external to where their treasury is based (unless DAO members are willing to subject their bridged treasury funds to additional trust assumptions, effectively foregoing decentralization and autonomy).

SOLUTION

EtherGov is a chain-agnostic treasury account for DAOs, with fully customizable payload to enable the execution of any arbitrary transaction on any chain, and extensible plug-and-play governance primitives to allow for composable voting logic on a per-proposal basis. It is a DAO-as-a-Service (DaaS) platform, lifting the heavy operational burden of DAOs while also enabling their treasury to be “chainless” for the very first time. DAOs no longer need to concern themselves with infra-setting — EtherGov abstracts away infra management complexities of DAOs, allowing them to solely focus on what matters most: the community.

Currently, EtherGov is equipped with the following governance primitives out-of-the-box:

• NFTs as the principal identity for a DAO voter: anyone who wants to participate in a proposal needs to own and lock an NFT associated with the DAO (defined within its treasury params);
• Sismo Connect for reputation-based services: proposal participation can be further gated by any data group within Sismo Factory (if not available, one of the council members can always create a new Sismo data group that would better serve the needs of the DAO);
• Governing Council (inspired by Polkadot’s OpenGov): only people that is part of the council will be allowed to initiate proposals and remove fellow council members — anyone can make their case and submit a council candidacy (alongside an arbitrary self-bond amount), and if the candidacy proposal collects enough votes, the candidate is admitted to the council list.

EtherGov has also enabled the following abstractions in a bid to ease user onboarding and voting experience for a non web3-native DAO participant:

• Biometric wallets: instead of using seed phrases, Cometh Connect allows voters to vote on proposals via biometric authentication in a gasless manner (voters do not need to pay anything to vote — gas fees are abstracted and sponsored by the DAO’s gas tank);
• DAO gas tank: while every DAO will use EtherGov’s gas tank during initial deployment, they reserve the option to deploy their own gas tank and update the gas tank address within its treasury params (the change will get reflected once the DAO’s proposal passes);
• Payload abstraction: instead of mandating non-technical council members to define complex payload inputs pertaining to a transaction, EtherGov has provided a list of commonly-used transaction presets for the proposal initiator to simulate the transaction as if it’s conducted via the front-end of the protocol itself (the payload will be automatically generated based on selection of the proposal initiator via the EtherGov widget, representing the transaction).

EXAMPLE USE CASES

EtherGov’s chainless DAO treasury accounts are most suitable for any use case that requires the collective management of a shared pool of funds meant for a certain purpose / cause, and that nobody is allowed to have “sudo control” over this treasury. Some examples:

• Decentralized investment / VC fund;
• Decentralized on-profit / charitable foundation;
• Shared treasury for an NFT project;
• Shared treasury for a university club;
• Shared treasury for an events organizer;
• Shared pool of funds amongst a group of friends;
• etc.

REMARKS

Due to time constraints, we weren't able to properly connect our front-end with the application. Hence, the front-end that you see in the video is our first iteration, the minimum "bare bones" version.

However, the application is in fact working as intended – only the front-end in the video demo is not up to what we're trying to achieve. We have attached screenshots of our "real" front-end, for anyone's reference. It'd be appreciated if you could take a look at our GitHub!

Thank you!

Every EtherGov deployment fundamentally consist of safeAA, govContract, and chainModule: safeAA to hold treasury funds (and to execute payable), govContract encapsulates the primary voting logic governing the safeAA, while chainModule is a generic “pass-through” (built on top of Hyperlane) handling payload generation (with the help of our custom backend) and transmission (so that it is securely relayed and is executable upon arrival on the target chain’s chainModule).

Sismo Connect is used to enable second-layer voter validation involving reputation-based services (via Sismo data groups). Cometh Connect is also integrated to allow voters to vote using only their biometrics for authorization, as well as being completely gasless (DAOs can specify a dedicated gas tank to sponsor the onchain transactions of eligible voters of a proposal).

You can refer to our GitHub repo for more details.