-
Notifications
You must be signed in to change notification settings - Fork 355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backport from DAO DAO: optionally charge to make proposal #742
Comments
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? |
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 |
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! |
@ethanfrey So, we have a PR from @0xekez that ticks off all your boxes (thanks BTW!) and only needs to be updated with current
If it's not a frequent use case, I'd vote to drop it too. |
I very much appreciate this.
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. |
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 |
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:
DAO DAO implementation (you can use this, or do something better, but this is a reference):
Some notes:
deposit: Option<Cw20Coin>
and storeCw20CoinVerified
. This is also more compatible with current instantiationTransferFrom
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.The text was updated successfully, but these errors were encountered: