Skip to content

Feat: funded proposal submission#9

Closed
MarvinJanssen wants to merge 8 commits into
mainfrom
feat/funded-proposal-submission
Closed

Feat: funded proposal submission#9
MarvinJanssen wants to merge 8 commits into
mainfrom
feat/funded-proposal-submission

Conversation

@MarvinJanssen
Copy link
Copy Markdown
Member

Uses the treasury extension from #5.

Proposals have to be funded with STX before they can be brought to the voting phase. Funding cost is an amount set via a parameter. Members can request a refund at any time, for as long as the funding target has not been met. Tokens used to fund proposals to move them to the voting phase are deposited in the DAO treasury.

There are many interesting iterations possible with extensions like it.

@MarvinJanssen MarvinJanssen requested a review from mijoco-btc July 25, 2022 09:13
@orlandobtc
Copy link
Copy Markdown

Great idea for funding proposals and preventing proposal spam. Just to add some potential iterations here that focus a bit more on proposing spamming (as opposed to funding a specific proposal):

  1. Slashed funds go to the DAO: Members must lock up a certain amount of STX (or other SIP-010 token) in order to submit a proposal. If the proposal is approved, the STX can be refunded to the member. If it fails after voting, then the member's STX is "slashed" and the DAO's treasury can claim the funds. This may better incentivize more lower income members to submit proposals that they believe will gain support within the DAO without them fearing that they will lose funds for submitting a popular proposal. It also disincentivizes spam proposals since people will lose tokens for each failed proposal submission.

  2. Slashed funds go to vote winners: Same scenario as above, but instead of the funds being claimable by the DAO, members who voted correctly can claim the funds put up. This is kind of a form of "governance mining" and has the benefit of incentivizing more governance participation since members can earn for voting correctly.

There are trade-offs that need to be considered for both of these iterations. For example, option 2 may cause members to simply vote for the side that is winning in the beginning as they may be more incentivized to vote for the winning side as opposed to voting for what they believe is actually what's best for the DAO.

@mijoco-btc
Copy link
Copy Markdown

Closing this as this feature has been merged with the feat/baseline branch unit tested and function tested on stacks testnet.

@mijoco-btc mijoco-btc closed this Oct 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants