da0-da0 / dao-contracts

CosmWasm smart contracts for Interchain DAOs.

DAO Contracts

This is a collection of smart contracts for building composable, modular, and upgradable DAOs.

For a detailed look at how these contracts work, see our wiki.

Overview

Every DAO is made up of three modules:

1. A voting power module, which manages the voting power of DAO members.
2. Any number of proposal modules, which manage proposals in the DAO.
3. A core module, which holds the DAO treasury.

For example, voting power might be based on staked governance tokens, staked NFTs, or membership and proposal modules might implement yes/no, multiple-choice, or ranked-choice voting.

Each module type has a standard interface. As a result, any voting module can be used with any proposal module, and any proposal module with any voting module.

The best way to get started is to create a DAO! We maintain an open source frontend you can find at daodao.zone.

Audits

If you believe you have found a problem, please let us know.

DAO DAO has been audited by Oak Security on multiple occasions. You can find all the audit reports here.

v2.3.0 is the most recent DAO DAO release; only new feautres related to tokenfactory and improved NFT DAOs have been audited. Our most recently full audited release is v2.0.0. Vesting and payroll were added and audited in v2.1.0.

Audited contracts include:

• cw-payroll-factory
• cw-tokenfactory-issuer
• cw-token-swap
• cw-vesting
• dao-dao-core
• dao-pre-propose-approval-single
• dao-pre-propose-approver
• dao-pre-propose-multiple
• dao-pre-propose-single
• dao-proposal-condorcet
• dao-proposal-multiple
• dao-proposal-single
• cw20-stake
• cw20-stake-external-rewards
• cw20-stake-reward-distributor
• dao-voting-cw4
• dao-voting-cw20-staked
• dao-voting-cw721-staked
• dao-voting-token-staked

Audited packages include:

• cw721-controllers
• cw-denom
• cw-hooks
• cw-paginate-storage
• cw-stake-tracker
• cw-wormhole
• dao-dao-macros
• dao-hooks
• dao-interface
• dao-pre-propose-based
• dao-voting

Why?

Our institutions grew rapidly after 1970, but as time passed their priorities shifted from growth, to protectionism. We're fighting this. We believe The Internet is where the organizations of tomorrow will be built.

DAO DAO is a global community working on Internet governance, and a real DAO. We've never raised money, and all our work is open-source. We hope you'll join us.

Links and Resources

• DAO DAO DAO
• Discord
• Docs
• Manually Instantiating a DAO
• Twitter
• What is a DAO?

Developers

Information about our development workflow and how to contribute can be found in CONTRIBUTING.md.

Testing

Unit tests

Run cargo test, or just test from the project root to run the unit tests.

Integration tests

Run just bootstrap-dev to spin up a local environment and just integration-test-dev to run tests against it.

See ci/integration-tests/README.md for more information.

Disclaimer

DAO DAO TOOLING IS PROVIDED “AS IS”, AT YOUR OWN RISK, AND WITHOUT WARRANTIES OF ANY KIND. No developer or entity involved in creating the DAO DAO UI or smart contracts will be liable for any claims or damages whatsoever associated with your use, inability to use, or your interaction with other users of DAO DAO tooling, including any direct, indirect, incidental, special, exemplary, punitive or consequential damages, or loss of profits, cryptocurrencies, tokens, or anything else of value.

dao-contracts's Issues

Dockerize

Need to make it easier for frontend folks to develop UI.

We should have a docker container:

• Running wasmd chain with right RPC and REST ports exposed
• Automatically deploys contracts onto chain
• Has a set of accounts created with balances

Generate TS types and publish them on NPM

Document running with docker

For quick local testing with the CLI

Initialize DAO with some of its own Governance Token

Currently, DAOs start with a balance of 0 for their governance token... would be nice if there was an option to give the DAO an initial governance token balance.

Native token voting

Would be nice to optionally use a native token for voting instead of a cw20.

Optional Proposal Deposit

Should be able to optionally require a proposal deposit. Refunded if proposal passes.

`query_proposal` should use total supply at time of proposal creation not at time of query

Currently this query will return a response based on the current token supply

dao-contracts/contracts/cw3-dao/src/contract.rs

Lines 429 to 430 in be81f7e

	let total_supply = get_total_supply(deps)?;
	let threshold = prop.threshold.to_response(total_supply);

A proposal being passed though depends on the amount of tokens available when the proposal was created:

dao-contracts/contracts/cw3-dao/src/state.rs

Lines 111 to 129 in be81f7e

	} => {
	self.votes.yes
	>= votes_needed(self.total_weight - self.votes.abstain, percentage_needed)
	}
	Threshold::ThresholdQuorum { threshold, quorum } => {
	// we always require the quorum
	if self.votes.total() < votes_needed(self.total_weight, quorum) {
	return false;
	}
	if self.expires.is_expired(block) {
	// If expired, we compare Yes votes against the total number of votes (minus abstain).
	let opinions = self.votes.total() - self.votes.abstain;
	self.votes.yes >= votes_needed(opinions, threshold)
	} else {
	// If not expired, we must assume all non-votes will be cast as No.
	// We compare threshold against the total weight (minus abstain).
	let possible_opinions = self.total_weight - self.votes.abstain;
	self.votes.yes >= votes_needed(possible_opinions, threshold)
	}

Tokens being burned or minted between when a proposal is created will result in the threshold returned by the query being different than the threshold that is required for the proposal to pass.

Use sub-account for proposal deposit balances

The current implementation of proposal deposits has a hidden foot-gun that the dao could create a proposal to spend all of its cw20 balance and accidentally spend the proposal deposit balances. Storing the proposal deposit balances in a sub account using https://github.com/CosmWasm/cw-plus/tree/main/contracts/cw1-whitelist would make this distinction more clear and make it unlikely the dao would accidentally spend proposal deposits. Of course, the DAO could always spend the deposits on purpose but such is the will of the people 🤷‍♂️ .

deploy_local.sh should use ujunox as denom

Now that we use junod it doesn't seem to make a terrible amount of sense that ustake is distributed to the default account as you can't pay for juno transactions with that (or at least this is what keplr suggests to me).

Implement vote delegation

This was previously done in cw20-gov: https://github.com/DA0-DA0/dao-contracts/tree/d883ee2db3cc0f5fffe8606d3d833ad1cc08a975/contracts/cw20-gov

Losing deposits should go to DAO

Credit: @bmorphism

Option to refund Proposal Deposits even on failing props

Might be nice for some communities to not have a penalty for creating a failing proposal. We can add an option to the DAO config for this. If it's enabled, in excute_close we include a refund message.

Optional CosmosMsg

Sometimes you just want a normal text proposal.

Quadratic Voting

QV is awesome, how can we support it?

Make deployment script

Add vote tally response type to @dao-dao/types

New response type was added in #99. Looks like this:

{
  "status": "open",
  "threshold": {
    "absolute_percentage": {
      "percentage": "0.5",
      "total_weight": "1000000000"
    }
  },
  "quorum": "0",
  "total_votes": "0",
  "total_weight": "1000000000",
  "votes": {
    "yes": "0",
    "no": "0",
    "abstain": "0",
    "veto": "0"
  }
}

Script to bootstrap data

Make some proposals and data for easier frontend testing.

Reduce entanglement with cw-dao-dapp

Currently, running a development environment (by our instructions) requires running the frontend repo in order to get a wasm address for one of your private keys. This links the two repos together a bit too tightly.

Ideally, developers should get a wasm address for their private key without the frontend repo.

Add name and description to DAO config

Would be nice to have the DAO name and description queryable from the contract.

Be able to update unbonding period on stake-cw20 and stake-cw20-gov

Use case: a DAO might want to vote to update the unbonding period of its governance token.

Similar to the mint method, this should only be call able by the "Minter" (imo, admin would be a better name), if one is defined.

Optional Whale Cap on vote size

Token based voting is great, but the downside is that whales can completely dominate some communities.

Would be great to potentially integrate an optional "whale cap" parameter. In other words the max vote size.

Ideally, whale sized votes would sill count towards quorum.

Test proposal logic edge cases

We should have some tests on contract edge cases. A few that have come up (more ideas welcome):

• A number of people make proposals, and someone makes a proposal that spends their deposits.
• User Alice makes a deposit, a proposal passes that changes the deposit amounts, Alice gets her original deposit back.

These are tests that should fail until we address the issue described in #12

Upgrade to cw-plus v0.11

https://github.com/CosmWasm/cw-plus/blob/main/MIGRATING.md#v0103---v0110

Update votes when determing if a proposal has passed to reflect current CW20 balances

This is a fairly large issue in the current implementation. After a user votes for a proposal, they can then transfer the cw20 to a different wallet and vote again. Effectively this gives anyone unlimited votes.

One fix is to update vote power when checking if a proposal has passed. We could go further and just record the voter address and only get the token balance when evaluating if the proposal has passed.

Another fix is to require voters to deposit their token when voting to be returned after the proposal resolves.

IMO, I think the first solution gives more flexibility to the token holders.

Staking

After some thought, it's better to stake the Gov tokens in order to participate in governance.

Use latest CosmWasm

Need to bump deps.

Address book

This could be a separate contract, but we need a way to know who is who in the DAO.

Get Cw20Balances for Multisig

Similar to cw3-dao, it would be nice to maintain a list of cw20 tokens for querying for cw3-flex-multisig.

cw3-dao supports the following query messages:

    /// Returns All DAO Cw20 Balances
    Cw20Balances {
        start_after: Option<String>,
        limit: Option<u32>,
    },
    /// Return list of cw20 Tokens associated with the DAO Treasury
    Cw20TokenList {},

It also supports a method to update the token list, which is only callable by the cw3-dao contract itself.

    /// Updates token list
    UpdateCw20TokenList {
        to_add: Vec<Addr>,
        to_remove: Vec<Addr>,
    },

Ranked Choice Voting

Would be great to think about what this looks like for proposals...

Allow using Native Tokens for voting

Had some great conversations at Cosmoverse that convinced me this is needed. DAOs should be able to cw20 or native tokens for voting.

Limit size of add and remove when changing governance tokens

dao-contracts/contracts/cw3-dao/src/contract.rs

Lines 359 to 365 in 8a8dd33

	for token in &to_add {
	TREASURY_TOKENS.save(deps.storage, token, &Empty {})?;
	}
	for token in &to_remove {
	TREASURY_TOKENS.remove(deps.storage, token);
	}

These are currently unbounded. What audits I've seen seem to really care about these things causing gas to run out. Lets limit these to the same MAX_LIMIT that is used when querying balances.

DAO instantiates it's own governance token

If the DAO instantiates it's own governance token, it can mint tokens however it sees fit. @the-frey, let us know if you want or need help with this. 🙏

Shareholder Distribution Contract

Think of it like a built in payment splitter, tokens come in and are distributed according to token ownership in the DAO.

Using this, DAO members could submit proposals to distribute a portion of the DAO treasury amongst DAO token holders. Alternatively, other projects could airdrop DAO token holder.

Better Threshold Validation

Currently this contract does not validate the the Threshold parameter upon instantiation.

Add testcase for when 0 deposit is needed

Add test to make sure proposals still work when the deposit is configured to zero. There should be no need to set an allowance on the cw20 token.

Figure out a way to handle errors in treasury token queries while listing token balances

Currently we just return a default value of zero if an error occurs during the query. This is good because it means that a misbehaving token won't cause queries to fail entirely but we might want to investigate ways that these errors could be displayed.

Use Selected Strategy for Snapshot

GetConfig query

Get DAO params.

Tally query

As a DAO member, I would like to know how close a vote is to passing.

Currently, from the queries included in the cw3 spec, it's a pain to figure this out (especially if there are a large number of voters).

So let's introduce a Tally { proposal_id: u64 } query, which will return info about the current vote tally. Imagine it would look something like this:

#[derive(Serialize, Deserialize, Clone, PartialEq, JsonSchema, Debug)]
pub struct VoteTallyResponse {
    // Current proposal status
    pub status: Status,
    // Required passing criteria
    pub threshold: ThresholdResponse,
    // Percentage of turnout
    pub quorum: Decimal,
    // Total number of votes
    pub total_votes: Uint128,
    // absolute number of votes
    pub total_weight: Uint128,
    // Tally's of the different votes
    pub votes: Votes,
}

We should be able to extend the existing proposal implementation in both cw3-dao and cw3-flex-multisig for this.

Transfer juno to the dao treasury in deploy_local.sh

We currently don't do this which means that when the DAO attempts to execute a proposal it will fail with insufficient funds unless you manually send some as the DAO does not have any coins to pay for the transaction.

Query to get DAO treasury balances

Would be convenient to get all the cw20 in the Treasury... may as well include native balances too.

Fork cw3 package?

We've added some new interfaces that are shared across both the cw3-dao and cw3-flex-multisig contracts... it might make sense for use to for the cw3 spec package. https://github.com/CosmWasm/cw-plus/tree/main/packages/cw3

Open to people's thoughts here. This is not urgent, but could reduce code duplication between cw3-dao and cw3-flex-multisig.

Use junod with deploy-local.sh script

Would be nice to be running Juno locally in docker rather than wasmd.

Query number of Proposals

@gavindoughtie wants to be able to easily query the total number of proposals for a multisig or DAO.

Optional Time Lockup for Voting

Potentially require people to lock up their capital to vote? Would any communities consider using this?

Multisig factory contract

As a user, I would like to see a list of the multisigs I'm a part of.

To achieve this, I think we need a factory contract that keeps track of multisigs created.

Vesting Contract

Can be separate, but would be useful for the DAO.

Delegate Votes

Would be nice to be able to delegate votes like in Compound Governance. This is an advanced feature and we should wait til #17 is resolved first.

Update Multisig Config

• Add name + description to config
• Add UpdateConfig method (similar to cw3-dao). This should only be callable by the flex multisig contract itself (i.e. a proposal would need to be passed to update the config)
• Add GetConfig query and be sure to also return the group contract address

Document Uploading and Instantiating Contract