Single choice proposal approval contract

This contract implements an approval flow for proposals, it also handles deposit logic. It works with the cwd-proposal-single proposal module.

Approval Logic

This contract is instantatied with an approver address. This address is allowed to approve or reject the proposal.

text ┌──────────┐ │ │ │ Account │ │ │ └─────┬────┘ │ │ Makes prop ▼ ┌────────────────────────┐ ┌────────────────────────┐ │ │ │ │ │ Pre-propose Approval │ ◄─────────────┤ Approver Address │ │ │ Approves │ │ └───────────┬────────────┘ or rejects └────────────────────────┘ │ │ Creates prop │ on approval ▼ ┌────────────────────────┐ │ │ │ Proposal Single │ │ │ └───────────┬────────────┘ │ │ Normal voting │ ▼ ┌────────────────────────┐ │ │ │ Main DAO │ │ │ └────────────────────────┘

The approver may also register a ProposalSubmitHook, which fires every time a proposal is submitted to the cwd-pre-propose-approval-single contract.

Deposit Logic

It may accept either native (bank module), cw20 tokens, or no tokens as a deposit. If a proposal deposit is enabled the following refund strategies are avaliable:

1. Never refund deposits. All deposits are sent to the DAO on proposal completion.
2. Always refund deposits. Deposits are returned to the proposer on proposal completion and even rejection by the approver.
3. Only refund passed proposals. Deposits are only returned to the proposer if the proposal is approved and passes. Otherwise, they are sent to the DAO.

This module may also be configured to only accept proposals from members (addresses with voting power) of the DAO.

Here is a flowchart showing the proposal creation process using this module:

Resources

More about the pre-propose design.

More about pre-propose modules.