@Callum-A @ezekiiel As in the audit written, admin can only withdraw the entire balance, not a partial withdrawal. I solved it by adding an amount field in ExecuteMsg::Withdraw that allows withdrawal of an amount token (0 < amount <= contract balance). Anh I also add test for invalid amount. Thank you guys for review. Close #326

Use case: SubDAOs where the parent DAO wants to maintain control over the child DAO.

This should probably go into the core DAO contract. Now some DAOs will not have any admin, but something like ExcuteMsg::AdminExecuteProposal could be very useful if a hierarchy is needed between a main DAO and its SubDAOs.

There could additionally be an UpdateAdmin only callable by the current admin.

Short description

So, what happened: we have a lib that wants to import voting, and then contract depend on that lib, what happens: cw-core gets imported (with everything)

Error

note: rust-lld: error: duplicate symbol: instantiate
          >>> defined in /code/target/wasm32-unknown-unknown/release/deps/duplicate_bug.duplicate_bug.8f61a3e5-cgu.0.rcgu.o
          >>> defined in /code/target/wasm32-unknown-unknown/release/deps/libcw_core-bfb32c933257001e.rlib(cw_core-bfb32c933257001e.cw_core.0b07bdab-cgu.0.rcgu.o)
          
          rust-lld: error: duplicate symbol: execute
          >>> defined in /code/target/wasm32-unknown-unknown/release/deps/duplicate_bug.duplicate_bug.8f61a3e5-cgu.0.rcgu.o
          >>> defined in /code/target/wasm32-unknown-unknown/release/deps/libcw_core-bfb32c933257001e.rlib(cw_core-bfb32c933257001e.cw_core.0b07bdab-cgu.0.rcgu.o)
          
          rust-lld: error: duplicate symbol: query
          >>> defined in /code/target/wasm32-unknown-unknown/release/deps/duplicate_bug.duplicate_bug.8f61a3e5-cgu.0.rcgu.o
          >>> defined in /code/target/wasm32-unknown-unknown/release/deps/libcw_core-bfb32c933257001e.rlib(cw_core-bfb32c933257001e.cw_core.0b07bdab-cgu.0.rcgu.o)

Minimal example

https://github.com/Buckram123/duplicate_example This is minimal template from here: https://github.com/InterWasm/cw-template One difference is here: https://github.com/Buckram123/duplicate_example/blob/57859b4e0997b7eba359b3da393ae55f2b563d30/duplicate-bug/src/msg.rs#L1 And instantiate method

Reproduce

To reproduce on my machine, simply run optimizer or just wasm

cargo build --release --target wasm32-unknown-unknown

docker run --rm -v "$(pwd)":/code \
  --mount type=volume,source="$(basename "$(pwd)")_cache",target=/code/target \
  --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \
  cosmwasm/rust-optimizer:0.12.6

Version

rustc 1.63.0 (4b91a6ea7 2022-08-08), (optimizer uses 1.60.0) 5.19.8-arch1-1

Addresses #136

Adds proposer field to the Proposal which is populated by the sender of the propose message. Noticed the CW3 ProposalResponse struct does not have a proposer field. Does this need to be addressed separately?

This PR should replace #305 .

The approach here is much simpler with the authorizations integrated into the proposals. We can discuss if this is the right approach, but the middleware approach added so much complexity that I don't think it's worth going that route.

The most interesting part of this PR should be the message-filter contract implementation and its tests. Additionally the proposal tests should give an idea of how this would be used in a more realistic scenario.

The PR is not production-ready, but I'd like to get some feedback before moving forward with the implementation.

This PR adds the ability to add hooks to the staking contract, which are contracts that will be notified when users stake and unstake funds. This will allow cool features to be built on top of the staking contract such as delegated voting and external staking rewards.

I have also taken made some improvements to the governance of modifying hooks as it is extremly high risk as an improper hook contract would lock all funds until the hook is removed. To better enable this, I have split the admin role into an owner and manager. The owner can add/remove hooks, change the owner, change the admin, and change the unbonding duration. The manager can do all of this excepct change the owner. This allows the DAO to delegate responsibilities of managing hooks to a more reponsive party such as a multisig while maintaining authority to remove the manager in case they attempt to lock funds.

This is especially important in the wasmswap context as a staking contract would need to be instatiated and managed for each pool. The amount of management will most likely exceed the capacity of the whole DAO to make each individual contract change.

TODO:

Need to write actual tests for the hooks, but this requires a dummy contract to ensure hooks are functioning as intended.

Some users understandably want to "dissolve" or "delete" a DAO.

Making 'deletion' work in practice will involve both the UI and the contracts. But, we may want to consider what we want that to look like from the contract perspective.

I'm imagining a governance proposal with a message that changes

• the title to "DEPRECATED - IGNORE"
• the description to the same
• maybe some other stuff?

What do folks think?

Hi all, this is my first foray into contributing to dao-dao, thanks in advance for considering.

This is a generic vesting contract for locking up DAO tokens and releasing them to vestees over time according to per-vestee schedules. The vesting contract stakes tokens internally to accumulate funding rewards accrued before vested tokens are claimed. This contract integrates modularly with cw20-base and cw20-stake; there is no overlap in functionality with either. cwd-voting-cw20-staked required some changes in order to grant vestees full control over the voting power of their unvested shares.

In a vacuum, usage of this contract goes like this:

1. The contract is instantiated with a token contract, a staking contract, and a list of (address, vesting_schedule).
2. The contract is now in an unfunded state. Once the contract is funded with the full amount to be vested over the lifetime of all vesting schedules, the contract "activates".
3. Once the contract is activated, users can call "vest" on the contract begin the unstaking process for their vested shares. The unstaking_duration still applies here, but with some changes to cw20_stake that could be avoided.
4. Finally, once a user's tokens in c20-vest are unstaked, they can be claimed with a call to "claim".
5. From here the user will likely opt to restake the tokens or sell them.

I also made changes to cwd-voting-cw20-staked to support instantiating/configuring cw20-vest at deploy time.

A vesting schedule is a list of monotonically increasing points (timestamp, amount) which may be piecewise linearly interpolated to describe the total amount vested at any given time. Vesting cliffs can be implemented by making the first point's amount greater than 0 and in the future.

Testing

• cw20_stake has decent test coverage right now but I will be adding much more.
• cwd-voting-cw20-staked has no tests of this functionality yet (hence the draft status)
• existing tests are passing :)

Open Questions

• cw20-vest currently assumes usage with a cw20-stake contract. Is this a good assumption or should staking be optional?
• I'm curious whether my query API design passes snuff with respect to conventions.

Related to #65.

This is the simple version. Basically, we just implement the VotingPowerAtHeight query by querying a user's staked balance. AND THAT'S IT!

Now querying a user's staked balance might be a bit tricky, but the AllDelagations query should return a list of the user's delegations and you can sum them up.

We're so close to being able to do bug bounty contracts (though a regular spend proposal would do in the meantime). It would be neat to have a "github is the oracle" integration so when the bug closes the (approved) contract auto-executes.

An image can really make a DAO pop, and it's in the designs... so we should add support for an optional image URL.

IMO we might as well also do this for the multisig too...

Currently, while migrating from v1 to v2, we do not check that the migration has not already occured. This allows DAOs to vote to migrate more than once which is a bit of a footgun as migration overrides dao_uri and activates all proposal modules.

Oak has kindly provided a test case for this <3

#[test]
fn test_replay_migrate() {
    // reproduced in contracts/dao-core/src/tests.rs
    use cw_core_v1 as v1;
    let mut app = App::default();
    let govmod_id = app.store_code(sudo_proposal_contract());
    let voting_id = app.store_code(cw20_balances_voting());
    let core_id = app.store_code(cw_core_contract());
    let v1_core_id = app.store_code(v1_cw_core_contract());
    let cw20_id = app.store_code(cw20_contract());
    let proposal_instantiate = dao_proposal_sudo::msg::InstantiateMsg {
        root: CREATOR_ADDR.to_string(),
    };
    let voting_instantiate = dao_voting_cw20_balance::msg::InstantiateMsg {
        token_info: dao_voting_cw20_balance::msg::TokenInfo::New {
            code_id: cw20_id,
            label: "DAO DAO voting".to_string(),
            name: "DAO DAO".to_string(),
            symbol: "DAO".to_string(),
            decimals: 6,
            initial_balances: vec![cw20::Cw20Coin {
                address: CREATOR_ADDR.to_string(),
                amount: Uint128::from(2u64),
            }],
            marketing: None,
        },
    };
    const OAK: &str = "oak";
    // let oak become the contract admin
    let v1_core_instantiate = v1::msg::InstantiateMsg {
        admin: Some(OAK.to_string()),
        name: "DAO DAO".to_string(),
        description: "A DAO that builds DAOs.".to_string(),
        image_url: None,
        automatically_add_cw20s: false,
        automatically_add_cw721s: false,
        voting_module_instantiate_info: v1::msg::ModuleInstantiateInfo {
        code_id: voting_id,
        msg: to_binary(&voting_instantiate).unwrap(),
        admin: v1::msg::Admin::CoreContract {},
        label: "voting module".to_string(),
    },
    proposal_modules_instantiate_info: vec![
        v1::msg::ModuleInstantiateInfo {
            code_id: govmod_id,
            msg: to_binary(&proposal_instantiate).unwrap(),
            admin: v1::msg::Admin::CoreContract {},
            label: "governance module 1".to_string(),
        },
        v1::msg::ModuleInstantiateInfo {
            code_id: govmod_id,
            msg: to_binary(&proposal_instantiate).unwrap(),
            admin: v1::msg::Admin::CoreContract {},
            label: "governance module 2".to_string(),
}, ],
    initial_items: None,
};
// init contract with creator as migration admin
let core_addr = app
    .instantiate_contract(
        v1_core_id,
        Addr::unchecked(CREATOR_ADDR),
        &v1_core_instantiate,
        &[],
        "cw-governance",
        Some(CREATOR_ADDR.to_string()),
) .unwrap();
// creator performs normal migration
app.execute(
    Addr::unchecked(CREATOR_ADDR),
    CosmosMsg::Wasm(WasmMsg::Migrate {
        contract_addr: core_addr.to_string(),
        new_code_id: core_id,
        msg: to_binary(&MigrateMsg::FromV1 { dao_uri: None }).unwrap(),
}), )
.unwrap();
// oak disables one proposal module
app.execute_contract(
    Addr::unchecked(OAK),
    Addr::unchecked(core_addr.to_string()),
    &ExecuteMsg::ExecuteAdminMsgs {
        msgs: vec![WasmMsg::Execute {
            contract_addr: core_addr.to_string(),
            msg: to_binary(&ExecuteMsg::UpdateProposalModules {
                to_add: vec![],
                to_disable: vec!["contract3".to_string()] })
                .unwrap(),
            funds: vec![],
        }
.into()], },
    &[],
).unwrap();
// oak pauses the contract
app.execute_contract(
    Addr::unchecked(OAK),
    Addr::unchecked(core_addr.to_string()),
    &ExecuteMsg::ExecuteAdminMsgs {
        msgs: vec![WasmMsg::Execute {
            contract_addr: core_addr.to_string(),
            msg: to_binary(&ExecuteMsg::Pause {
                duration: Duration::Height(10),
            })
.unwrap(),
            funds: vec![],
        }
.into()], },
    &[],
).unwrap();
// cannot do anything when paused
app.execute_contract(
    Addr::unchecked(OAK),
    Addr::unchecked(core_addr.to_string()),
    &ExecuteMsg::ExecuteAdminMsgs {
        msgs: vec![WasmMsg::Execute {
            contract_addr: core_addr.to_string(),
            msg: to_binary(&ExecuteMsg::UpdateConfig {
DAO".to_string(),
config: Config {
    dao_uri: None,
    name: "The Empire Strikes Back".to_string(),
    description: "haha lol we have pwned your
    image_url: None,
    automatically_add_cw20s: true,
    automatically_add_cw721s: true,
}, })
.unwrap(),
                funds: vec![],
            }
.into()], },
        &[],
    ).unwrap_err();
    // creator replay migrate function to update dao_uri and enable all proposal
modules
    let bad = Some("malicious".to_string());
    app.execute(
        Addr::unchecked(CREATOR_ADDR),
        CosmosMsg::Wasm(WasmMsg::Migrate {
            contract_addr: core_addr.to_string(),
            new_code_id: core_id,
            msg: to_binary(&MigrateMsg::FromV1 { dao_uri: bad.clone()
}).unwrap(),
        }),
) .unwrap();
    // dao_uri is modified in PAUSED state
    let dao_uri: DaoURIResponse = app
        .wrap()
        .query_wasm_smart(core_addr.clone(), &QueryMsg::DaoURI {})
        .unwrap();
    assert_eq!(dao_uri.dao_uri, bad);
    // proposal module can be re-enabled in PAUSED state
    let new_state: DumpStateResponse = app
        .wrap()
        .query_wasm_smart(core_addr.clone(), &QueryMsg::DumpState {})
        .unwrap();
    let proposal_modules = new_state.proposal_modules;
    for (idx, module) in proposal_modules.iter().enumerate() {
let prefix = derive_proposal_module_prefix(idx).unwrap();
assert_eq!(prefix, module.prefix);
assert_eq!(ProposalModuleStatus::Enabled, module.status);
} }

Github is going to drop support for actions running <NodeJS 16 by "Summer 2023".

You can see the deprecation warnings in the CI job summaries.

Sadly we need to entirely stop using actions-rs/cargo as it has been confirmed to be no longer maintained will just stop working.

i'd like to be able to write a testing helper method like make_proposal() -> Result<u64, ContractError> which i can use in both cwd_proposal_single and cwd_pre_propose_single.

i'd also like the following to be true:

1. i can use cw_multi_test in my make_proposal function.
2. cw_multi_test does not get compiled for non-production builds.

Starting some documentation for how I suggest architecting private voting into the DAO DAO design.

This is very WIP. If I get more time available during the week, will write up more on circuit design / other constraints!

Rendered readme - gives higher level overview, and where its expected to sit in with other modules

Rendered Spec - Intended to go into more details of cryptographic constructions, merkle trees involved, and client side UX. Still have a ways to go on this unfortunately

Code - Not started yet