🕯️Governance Process

The Alchemix DAO is run through a developer multisig, signaling through the Snapshot app.

ALCX Tokens give holders governance rights over the direction of the protocol and use of the treasury. Community members may create proposals by following the community governance process. If you are interested in submitting a proposal to the Alchemix DAO, you must follow the process below. If you want to apply directly for a grant, please see Questbook.

Community Governance Process

Step 0 - Draft Proposal Discussion

Gather sentiment for your proposal idea through discussion with the community in the Discord server, fireside chats, DMs with other community members, and writing a draft document to share. Refine your proposals with the comments and interests of the community.

Step 1 - Proposal Draft

Post your proposal as a new thread in the #governance-proposals channel of the Discord server.

Step 2 - Community Discussion

Ping any relevant contributors thus far in the thread and engage in discussion related to the proposal. This step is important, as you want your proposal to gather as much feedback as possible.

Step 3 - Off-Chain Signaling Via Snapshot

After a minimum of 5 days after completing Step 1 AND Step 2, you may post your proposal to the “Alchemixed Opinions” Snapshot (the platform for Alchemix governance temperature checks). Snapshot link: https://snapshot.org/#/alchemixedopinions.eth

1. A minimum of 50 ALCX is necessary to post a proposal. If you do not have 50 ALCX, you can ask someone with 50 ALCX to post on your behalf.

2. Proposals will be live for 3 days.

3. Voting options must only be For, Against, or Abstain.

Step 4 - AIP

If greater than 50% of the non-abstain vote is “For” and a quorum of 5k ALCX voting is met, the proposal will move to the official Alchemix Proposal Snapshot as an AIP (Alchemix Improvement Proposal) at https://snapshot.org/#/alchemixstakers.eth

Step 5 - AIP Vote

Official AIPs will have a quorum of 35k ALCX. If the quorum is met, then the multisig will be directed to execute the most popular voting option unless directed otherwise by the voting parameters.

Supplementary Information

Common Proposal Types

1. A change to the protocol treasury and how it is utilized.

2. A change to protocol parameters (such as Transmuter flow rate).

3. A grant, donation, or funding request for a specific feature.

4. Deploying a new protocol-related contract or upgrading an existing one by the core team (e.g., introducing a new yield strategy or launching on a new chain).

What Makes a Good Proposal?

1. The proposals should have a structure or format that makes giving context and background information easy.

2. The first item in the proposal should summarize only the action items on what is being proposed. To be as brief as possible, it should not include any justification. This section intends to detail every step necessary to execute the proposal.

3. The introduction of the proposal should be an introduction giving context to the reason for the proposal and what the body of the proposal contains. This section should include the necessary background information or minimum context to understand the proposal.

4. The body of the proposal should include an in-depth analysis and justification for what is being proposed. This section should include the area of impact, justification, charts and analysis, in-depth technical specifications, budget allocations, and implementation.

5. The end of the proposal should state the voting options that will appear on the snapshot and what they mean (For, Against, Abstain). This section should clarify what each voting option means in precise and direct language.

6. Any proposal that requires a high level of effort (new features, new deployments, grant requests etc) should identify who will do the work or who exactly will implement the proposal. For example, a poorly written proposal might suggest a new feature, while a well-written proposal would not only suggest the feature but also provide verification that the Core team is willing and able to build it, or specify who will build it if a third party is involved. If a grant request is included, then there is more onus on the proposer to justify why they will be able to build the feature. Treasury actions and changing protocol parameters will typically only take a handful of multi-sig transactions - in these cases, it can be assumed that the multi-sig will carry out the proposal if passed.