This proposal is to enable governance to spend funds from the community pool as outlined here.
Draft proposal: https://ipfs.io/ipfs/QmNsVCsyRmEiep8rTQLxVNdMHm2uiZkmaSHCR6S72Y1sL1
This will be submitted soon; please post any final feedback or concerns here.
edit: Proposal submitted! Cosmos | Cosmos Hub 2 | Activate the Community Pool - deposits welcome.
When proposal that all future proposals must be submitted in Latex?
Very excited for this. If this needs deposit help I would be happy to support it!
Thanks for the proposal @cwgoes. I particularly like how the proposal remains abstract, namely in regards to how CommunityPoolSpendProposal can be structured and evaluated. Here are some thoughts that immediately come to mind:
Amount far exceeds the deposit minimum). There should be at least some entity/address validations, no?CommunityPoolSpendProposal address should be a vesting account? The proposal can perhaps dictate the vesting parameters. (ie. the proposal handler can validate the account is vesting and that the vesting fields are valid).Agree @bez also I think it would be good to have separate fields for the recipient rationale and the amount rationale.
I don’t think I quite understand the question. What does the proposal deposit minimum have to do with the amount spent from the community pool? Are you asking about what would happen if the community pool didn’t have enough funds? The proposal would just fail to execute (but it’s easy to check the community pool’s balance before making the proposal).
Sure, this seems like a useful feature. Perhaps we add a VestingPeriod to the proposal content, and if nonzero send the funds as cliff-vesting when the proposal passes.
We could have separate fields, but the proposal content needs a single GetDescription() string method (that’s how the interface is defined), so I don’t think it will make too much of a difference.
Yes @cwgoes, I suggest having vesting period fields in the CommunityPoolSpendProposal.
Ah, one complexity is that accounts cannot have funds with different vesting periods at once, so that would prohibit sending vesting coins to existing vesting accounts.
Let’s leave vesting for later, I think.
Revised version @bez - https://ipfs.io/ipfs/QmNsVCsyRmEiep8rTQLxVNdMHm2uiZkmaSHCR6S72Y1sL1
You’re right @cwgoes. Looks great. I’m in favor.
I was thinking the very same thing. 
The proposal looks great to meet. I appreciate the abstraction and clarity. Clearly the process to allocate the community fund will evolve over time, and this is the appropriate way to start that IMHO. I’ll be voting yes to signal support and then paying attention to see if the discussion brings up anything I am missing. Seems straightforward to me!
I think vesting functionality(divided payment) is necessary condition for community-fund expenditure. We cannot trust any 3rd party to give away all amount at once because of due dilligence and final output quality & deadline.
Doesnt it need deeper discussion and more functionality before adoption? We are not in a hurry yet.
Paying in vesting coins definitely seems like a desirable feature to me - this proposal doesn’t include it because the technical changes required are nontrivial (the current account system doesn’t allow an account to have multiple kinds of vesting coins at once), but future proposals could add such a feature.
This proposal doesn’t suggest any specific process for actually spending the funds, and you may be right that paying ahead of time doesn’t make sense in many cases, but there are other possibilities: prizes, multi-stage payments (a proposal for each stage), paying entities with a high amount of reputation at stake, etc. - I definitely think it’s more useful to have the option now, even if vesting coins aren’t yet supported.
Ubik Capital vote is Yes but we have to specify in detail how Community Pool will be used.
Proposal seems to be down right now @cwgoes
EDIT: Seems to be back up, but I got a 404 a few days ago. Maybe someone should run infrastructure to auto-pin all proposals with a fast machine