Skip to main content

How to submit a DAO proposal

PUBLIC PREVIEW DOCUMENT

This document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.

In this how-to, you'll learn how to submit an Arbitrum Improvement Proposal (AIP) to the ArbitrumDAO. Familiarity with Arbitrum, DAOs, and Ethereum is expected. Otherwise, this how-to makes no assumptions about your experience with governance protocols.

Prerequisites​

To submit a temperature check using the off-chain governance UI, you must have an Ethereum wallet address with 500,000 votable tokens1; To submit a proposal using the on-chain governance UI, you must have an Ethereum wallet address that represents at least 1,000,000 votable tokens.

If you don't have enough voting power, consider delegating your votes to a delegate who can create a proposal on your behalf2.

Proposal types​

There are two types of AIPs: Constitutional and non-Constitutional:

  • Constitutional AIPs are those that modify the text or procedures of the Constitution or AIP-1, install or modify software on any chain, or take any action that requires "chain owner" permission on any chain.
  • Non-Constitutional AIPs are all other AIPs, such as those that request funds/grants or provide general guidelines or information to the community.

See Constitution for further details.

Proposal structure​

The Constitution of the Arbitrum DAO encourages proposers to include the following sections within Arbitrum Improvement Proposals:

  • Abstract - Two or three sentences that summarize the AIP.
  • Motivation - A statement on why the Arbitrum community should implement the AIP.
  • Rationale - An explanation of how the AIP aligns with the Arbitrum community's mission and guiding values.
  • Key Terms - Definitions of any terms within the proposal that are unique to the proposal, new to the Arbitrum community, and/or industry-specific. This section is optional, but recommended.
  • Specifications - A detailed breakdown of the platforms and technologies that will be used. This is where you can elaborate on the "why" of your design decisions. You can also use this section to describe alternate designs that were considered and related work, e.g. how similar specifications have been successfully (or unsuccessfully) implemented in other chains or languages.
  • Steps to Implement - The steps to implement the AIP, including associated costs, manpower, and other resources for each step where applicable. AIPs that involve transactions with third parties (such as grants) will need to ensure that applicable legal documentation and procedures are also included.
  • Timeline - Relevant timing details, including but not limited to start date, milestones, and completion dates.
  • Overall Cost - The total cost to implement the AIP. The overall cost section should include a breakdown of the total cost of the AIP, including any associated costs for each step where applicable. Consider both fixed costs and recurring costs.

Sometimes, AIPs aren't passed on the first try. If an AIP is not passed, the proposer may resubmit the AIP after addressing the concerns of the community. The proposer should include the following additional sections in the resubmitted AIP:

  • A link to the previous AIP - The link to the previous AIP should be included in the resubmitted AIP.
  • Reasons why the AIP was not passed - The reasons why the AIP was not passed should be included in the resubmitted AIP.
  • Changes made to the AIP - The changes made to the AIP should be included to address the concerns raised during the previous AIP submission.
  • Additional information - More detailed intentions, specifics and implication details can help the community understand the revised AIP, increasing the chances of it being passed.

Pre-proposal development​

Proposals that require code changes should include the code that will be executed when the proposal is passed. This code should handle the data structures, logic, executable data, and execution of the proposal. Refer to Governance Proposal Lifecycle: Example for an example.

Step 1: Conduct a formal temperature check​

The DAO governance forum facilitates discussions about ArbitrumDAO and governance proposals that are submitted by eligible token delegates. To submit your proposal:

  1. Go to the DAO governance forum.

  2. Create a new post with your proposal using the template located here. You can add additional fields to this template to provide more context for your proposal if you'd like.

  3. After at least 7 days, navigate to the off-chain governance UI to create a poll that will gauge the community's interest in your proposal.

    • Connect your wallet.
    • Create a poll that points to your forum post. The poll should run for one week and should be decided by a simple majority.
    • Navigate back to your forum post and share the link to your poll with the community.

  4. Allow at least one week for discussion and debate. Iterate on your proposal based on feedback from the community.

If your proposal passes the temperature check, then you can move to the second and final step: an on-chain vote facilitated by the on-chain governance UI. Ensure that you've incorporated feedback brought up during relevant forum discussions and temperature checks before proceeding.

Step 2: Submit your on-chain proposal​

If your wallet can represent at least 1,000,000 tokens, you can create an on-chain proposal using the on-chain governance UI.

To submit your proposal:

  1. Log in to the on-chain governance UI using the wallet that represents the $ARB tokens.

  2. Navigate to the "Proposals" section.

  3. Select "+ New Proposal”.

  4. Choose which governor you are targeting:

  5. Give the proposal a name and description.

  6. Add proposal actions to be executed if passed. For example, "transfer n ETH to 0x address".

  7. Preview your proposal and submit on-chain.

A proposal passes if two conditions are met:

  1. More votes are cast in favor than against

  2. The total number of votes cast in favor (including abstain votes) is at least the following percentage of the delegated tokens:

If the proposal passes, congratulations! After a delay, the proposal’s actions will be executed on-chain3.

If the proposal doesn’t pass, but there's interest in improving and resubmitting it, refer to How to resubmit your proposal.

If you have any questions or concerns, visit the ArbitrumDAO governance forum.

Welcome to the future of governance!

Important notes​

  1. The Security Council has the power to execute emergency actions and non-emergency actions, as delegated to it by the Constitution. These are unlike traditional AIPs in that they can be approved by the Security Council without going through the above process. See the Security Council page for more information.
  2. The threshold of support required for a proposal to pass can vary depending on the type of proposal and the quorum requirements specified in the Constitution.
  3. You can delegate your voting power2 to another address whether or not you have enough tokens to submit on-chain proposals. If you hold any $ARB tokens whatsoever, you can participate in ArbitrumDAO's governance.
  1. When we say "an Ethereum wallet address with at least 500,000 votable tokens", we mean that 500,000 or more tokens are delegated to this address. You can delegate the tokens to your own address and other $ARB token holders can delegate to you.↩
  2. Learn how to delegate your votes by visiting How to delegate your voting power.↩
  3. Refer to The Constitution of the ArbitrumDAO for additional details and conditions.↩