Engineering

Objective: Research and spec out technical implementation. The following are examples from other projects' contracts, scoring systems, and UI components that we can learn from and build upon.

Contracts Needed

Delegating Voting Power

• How did Gitcoin do forced delegation to claim tokens?

  • https://gitcoin.co/blog/architecting-buidling-the-gtc-token-distributor/

• Compound-style governance fork with forced delegation (inspired by Gitcoin DAO) to ensure high participation

Claiming Governance Tokens

• Merkle root contract to allow eligible participants to claim their governance tokens within the eligibility timeframe (e.g. 30 days)

  • https://fravoll.github.io/solidity-patterns/pull_over_push.html

• We will make the governance token non-transferrable to keep decision-making power in the hands of the chosen cohorts and prevent gaming.

Allocator Score System

DAO Drops proposed a program to score addresses based on past on-chain activity past on-chain activity (dapp usage, development, event attendendance) that gives them influence over fund allocation decisions. The following are examples of how other projects have determined which addresses to give governance power to.

Script to scrape Ethereum to get cohorts of voters

During the development of the DAO Drops prototype, we first worked to generate scripts from scratch, by running a full node on a raspberry pi cluster. The main data set we started with was who had deployed a contract on chain. We built a data mining script that connects to an RPC and pulls that data by monitoring transactions sent from the zero address that tells that a contract was deployed. (We couldn't use The Graph for this, since there is no event emitted when a contract is deployed.) Syncing the full node takes a long time, and we also ran into an issue with Infura limits how many calls you can make to their servers.

Originally we had wanted to pull all the data ourselves - we found that it's doable but quite the process. This method would be ideal to pull specific types of contract data sets, to make more targeted sets of funding allocators.

For Drop 1 we decided to go with existing data sets provided by 3rd parties who had already generated them. This achieved a secondary benefit of bringing them on as collaborators and supporters of the project.

NFTGalaxy/shadowy-super-coder's data set:

Looks like they used SQL and google queries

Combinations:

• We could run a similar query and assign scores instead of grouping them into two tiers, and possibly just go with that as the pilot set.

• Alternatively we could integrate this data as-is to a broader formula (e.g. shadowy super coder = 50 points, super coder = 10 points) that incorporates other scoring factors as well (Devcon/ETHGlobal POAP = 5 points, High Gitcoin Giver = 25 points, Mid-level Gitcoin Giver = 10 points, etc)

Other approaches:

Giveth:

• asked groups for addresses, and trusting them

• Gitcoin data, with boundary of donated to at least 2 rounds before round 8

• their own data from people that interacted with the Giveth DApp

• Charity DAO participants

• asked Wetrust, The Giving block, and CLR fund for their data

UI Components

Examples we can use out of the box and fork

DAO Deployment

Game Maker DAO: During DAO Drops initial R&D, more complex approaches were ideated, including running several DAOs in parallel, focused around different themes, with more complex game dynamics.