Backport from DAO DAO: optionally charge to make proposal

[ethanfrey]

cw3-flex-multisig may require a payment in order to create a proposal. This will often not be set on multisig-like implementations, and set on token-weighted voting to stop people from staking one token and spamming proposals.

Requirements:

• The proposal start_time will not be set (not be active) until the required funds are sent
• If the proposal passes, the deposit will be returned

DAO DAO implementation (you can use this, or do something better, but this is a reference):

• Optionally require a deposit to make a proposal DA0-DA0/dao-contracts#11 (to require deposit)
• Add refund option to dao contract #28 DA0-DA0/dao-contracts#35 (to refund even on failed vote)

Some notes:

• Don't use two fields in Instantiate but rather deposit: Option<Cw20Coin> and store Cw20CoinVerified. This is also more compatible with current instantiation
• Note: UpdateConfig needs to update this field as well (as in the original PR)
• They use TransferFrom that needs a previous authorization to do this. That is the least API breaking change and I would stick with it here. Other times I would say use Cw20 Receive interface, but that would be a lot breaking and have two different paths for with deposit and without deposit.

[0xekez]

For multisigs it seems reasonable that you'd actually accept either a cw20 or native token as a proposal deposit. Accepting cw20 tokens is fine, but accepting native ones as well would make these contracts more flexible.

I'd be happy to take this on. Want to add this to DAO DAO as well so it'll be good for me. @ueco-jb do you currently have work in progress for this or do you mind if I put something up?

[ethanfrey]

If it is easy enough to merge this PR, I am happy to merge it.

On the other hand, I am also happy to leave cw3/cw4 as a reference pattern not as a full product (this is a more product-level feature) and recommending people to look at DAO-DAO code for advanced use cases.

I would not block a release on this if it takes significant time

[0xekez]

@ethanfrey I am also happy to leave cw3/cw4 as a reference pattern not as a full product (this is a more product-level feature) and recommending people to look at DAO-DAO code for advanced use cases.

imo - this is probably a good approach. at least on the DAO DAO side, we've never had someone ask for proposal deposits for their cw4-groups based DAOs (despite the fact that we do support it as cw4 and token based daos share a proposal system). i may have some bias here, but i'm a huge fan of having less code.

that said, i'm always happy to backport code to cw-plus from dao dao when you'd like and i'll update the PR so it can be merged if we'd like. i've used cw-plus code extensively and want to give back where I can!

[uint]

If it is easy enough to merge this PR, I am happy to merge it.
On the other hand, I am also happy to leave cw3/cw4 as a reference pattern not as a full product (this is a more product-level feature) and recommending people to look at DAO-DAO code for advanced use cases.

@ethanfrey So, we have a PR from @0xekez that ticks off all your boxes (thanks BTW!) and only needs to be updated with current main. Do you want me to rebase and merge this before officially freezing specs? Or are we dropping it to have clean, minimal reference contracts here?

we've never had someone ask for proposal deposits for their cw4-groups based DAOs

If it's not a frequent use case, I'd vote to drop it too.

[ethanfrey]

that said, i'm always happy to backport code to cw-plus from dao dao when you'd like and i'll update the PR so it can be merged if we'd like. i've used cw-plus code extensively and want to give back where I can!

I very much appreciate this.

we've never had someone ask for proposal deposits for their cw4-groups based DAOs

It is a very important case for dao-dao, and may make sense for cw4-stake if people use/used that much.

My main point is that with dao-dao as a product, I see these more as reference. That said, if the PR is ready, we can merge it, then work to freezing them. Just don't aim to keep feature parity with dao-dao, but as a simple example.

I do think proposal deposits is good, and there is even an (unused) state for proposals waiting to collect enough deposits.

[ethanfrey]

TL;DR if not too much work, let's merge it and freeze spec after. no need to keep updating with dao-dao advancements, as these remain as simpler reference