TL;DR
- Although the below contains parts of the official and ratified governance process, it is not in and of itself the officially recognized process for submitting a proposal to the Arbitrum DAO. Instead, it’s a compilation of knowledge and experience from existing participants that could be seen as ‘tips and tricks’ to submitting your proposal.
- You don’t necessarily have to follow every step word-for-word. Each individual and/or group as well as their proposal is unique and might need fewer or more steps based on the overall context.
- Making sure you’re an active part of Arbitrum DAO by participating in the forums, chats, and/or community calls before submitting a proposal can help you get off on the right foot with the community.
- Before submitting a proposal, seek to collect feedback in private from delegates.
- When publishing your proposal, make sure to adhere to the suggested format. Anticipate what questions delegates might ask and ensure you have adequate information for them not to.
- Be concise when explaining your proposal, but don’t overlook crucial information.
- If you do not have the necessary voting power to create a Snapshot or Tally vote, you can ask a delegate who does to create it on your behalf.
- The entire AIP voting process typically takes 37 days to complete for Constitutional AIPs or 27 days for Non-Constitutional AIPs
- If your proposal fails, you can always iterate based on delegate feedback and resubmit.
- This guide was published in April 2024 and is up-to-date until that time. The process might change as things evolve. We’ll come back and update the post as needed.
Considerations
The first thing you need to ask yourself before attempting to go through the process of submitting a proposal to the DAO is whether the proposal results in a win-win scenario. Simply put, what is the benefit that you will bring to the DAO through the execution of your proposal, and what do you stand to gain if your proposal passes?
If you have solid reasons to believe that the value created from your proposal justifies the organizational and/or monetary overhead created for the DAO, then you should proceed with the process as outlined below.
Oftentimes, it might be hard to assess your proposal in the context of the DAO. A good approach is to see whether there have been any similar proposals to the DAO in the past, or if there have been any similar proposals to other DAOs. Having a reference point can help put things into perspective both for you and also for the delegates when they are reviewing.
Frameworks vs Direct-to-DAO
Once you’ve assessed your proposal, it’s time to see if it fits into any of the frameworks that already exist. As is the case with most DAOs, Arbitrum has frameworks in place to facilitate governance proposals. The 2 main categories of proposals are constitutional and non-constitutional Arbitrum Improvement Proposals, or AIPs.
- Constitutional AIPs are those that modify the text or procedures of the Constitution or AIP-1, install or modify the 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.
If you’re reading this guide before proposing, chances are your proposal falls into the second category - and that’s where we’ll focus in this guide.
Two easy questions to help you narrow down even further on how you’ll approach the DAO with your proposal are:
- Am I requesting a grant for something I’m building on Arbitrum?
- Is this something that would require a framework, or is it a one-off thing?
- As a follow-up: if it does require a framework, does one already exist?
Requesting Grants
If you answered yes to the first question and you’re seeking a grant for something you’re building, then the choice you have to make is who you’ll request the grant from. There are several grant programs through which you can request funding without having to go through the governance process and a DAO-wide vote. You can find more information on different grant programs here.
Different kinds of proposal
If you’re trying to make a different kind of proposal, or looking to fund a governance initiative, then you first need to assess whether what you’re requesting would open the floodgates for other individuals, teams, or projects to also request. For example, if you’re a service provider and want to offer your services to the DAO, or if you’re a protocol looking for liquidity incentives, then you need to understand that you probably aren’t the only one out there with that idea.
When delegates evaluate these kinds of proposals, a factor they take into consideration is whether there needs to be a more holistic approach or a framework in place. If your proposal has a wide scope that could potentially be applied to others, then you should first seek to see whether a framework like that already exists.
If you’re a service provider, you should contact the Arbitrum DAO Procurement Committee (ADPC) and get whitelisted, and if you’re looking for liquidity incentives, you should be on the lookout for initiatives like Short-Term Incentives Proposal (STIP), or Long-Term Incentives Pilot Program (LTIPP).
If a framework doesn’t exist for what you’re seeking to propose, then you should either discuss with delegates and see whether one is being worked on or, if you’re feeling brave, start working on one yourself.
Pre-RFC (Request for Comment)
Before going to the forums and publishing your proposal as a ‘Request for Comment (RFC)’, you should first make sure that you’ve somehow established yourself in the Arbitrum DAO community. Ways to do that include:
- Having been active in the governance forums
- Having attended open governance calls
- Having talked with delegates online or in person
If you haven’t done any of the above, you might need to either have someone who’s already in the DAO introduce you to the right people or have a strong and credible out-of-the-DAO presence and reputation.
Although not explicitly required, having established yourself in the community will make it easier to attract attention to your proposal, and get the ball rolling in terms of discussion and feedback.
Ideally, you want to share your proposal with a few delegates before you even publish. Given their high context and experience in the DAO, they’ll probably have feedback to offer which will make your proposal better before you publish it.
While getting in direct touch with delegates might seem daunting at first, if you get a hold of one and ask them to connect you with others, the thread of contacts will start untangling pretty quickly.
Request For Comment (RFC)
First and foremost, you need to format your proposal in a way that is familiar to the DAO and easy to navigate. There’s a proposal template in the DAO’s governance docs here. Drafting an easy-to-understand yet solid proposal is more art than science. Below we’ve compiled some advice that will save you the time and effort of going back and forth with delegates and other community members that review your proposal.
- Include a TL;DR at the top.
The point of having a TL;DR of the proposal at the very top, similar to the one found at the start of this post, is so people can quickly get an overview and a refresh of the essence of the proposal without having to read through endless text. It doesn’t need to cover all the minor details, but it should include all the important ones.
- Avoid using “sales” language.
We’re excited that you want to build “the first in the world” or the “best-in-class” whatever, but the DAO is not a customer. The feedback you will receive will be based on the merit of the proposal rather than that of the pitch. If anything, you’re tiring both yourself and the delegates by adding unnecessary fluff. Be concise and to the point and it will be much better received.
- Get specific and don’t leave things hanging
While you want to avoid unnecessary fluff language, you do not want to be brief with the things that matter. Important information that pertains to your proposal should be extensively covered.
A non-exhaustive list of things that have been typically discussed in the past are:
- The total amount requested. You can denominate in either USD or ARB, but the funds you’ll receive will most likely be in ARB so keep that in mind.
- The timeline of your proposal
- A breakdown of how the money is going to be spent
- How will the funds be managed - will it be a multisig? If yes, who are going to be the signers?
- Will it be converted into stables or used as ARB?
- Is there going to be a milestone-based funding? If yes, what will the milestones be and how much money is it going to be unlocked at each?
- If there have to be some sort of elections relevant to your proposal, how will they be carried out? Who will manage the process?
- If there are smart contracts associated with your proposal, who is going to create them and audit them?
- If your proposal is meant to be a pilot or trial, what happens when it concludes?
- Contact info
Feedback on your proposal will typically be given publicly under your forum post. However, you might want to give delegates a way to reach you in case they want to discuss your proposal in more detail. Telegram is most delegates’ app of choice, but any line of communication is welcome.
Temperature Check on Snapshot
Once you’ve submitted an RFC to the forum, it’s generally a good practice to allow for some time (typically a week) before moving for a temperature check on Snapshot, unless the proposal is time-sensitive. If you’ve collected a lot of feedback under your forum post before the week is up, then you could move forward earlier so as not to waste time. If you haven’t collected enough feedback (or if you haven’t collected any feedback), worry not! Going to a temperature check on Snapshot is a sure way of getting delegates’ attention.
Creating a Snapshot vote
To submit a temperature check using Snapshot you must have an Ethereum wallet address that represents at least 0.01% of votable tokens (so 1,000,000 ARB). The Snapshot vote should run for 7 days and the outcome is decided by a simple majority with no required participation threshold. If you do not have that, you need to find a delegate who can post the proposal on your behalf.
If you’ve followed the steps above, you should already have a line of communication with a few eligible delegates by now. Don’t hesitate to reach out to them.
Updating your forum post
After creating your Snapshot vote, head back to your forum post and update it to include the link to the Snapshot. You can also add the link as a reply to “bump” your post to the top of the feed.
Discussing your proposal
There’s a bi-weekly call hosted by the Arbitrum Foundation where proposals are being discussed. You can find the calls on the Arbitrum Governance Calendar and attend one of those to discuss your proposal.
Disclaimer
Doing a temperature check on Snapshot is an optional, but strongly recommended step in the governance process. If an AIP fails this temperature check, the original AIP author is encouraged to refrain from proceeding with an on-chain vote, and voters are encouraged to reject it if the author proceeds anyway. If an AIP proposer decides to skip temp-check, voters consider it as a factor when casting their vote.
Formal Vote on Tally
After the temperature check, and given it was successful, the next step is to proceed with the on-chain vote on Tally. As with Snapshot, a Tally vote can only be initiated by $ARB token holders who hold (or represent) at least 0.01% of the votable supply. The Tally vote would run for 14 days and to be approved, more than 50% of the votable tokens that voted on the proposal must have voted in favor of the proposal; constitutional proposals must receive votes from at least 5% of all votable tokens in existence; non-constitutional proposal must receive votes from at least 3% of all votable tokens in existence.
Preparing up for an on-chain vote
The on-chain vote is executed permissionlessly after the vote concludes. For example, if you’re requesting funds from the DAO, successfully passing an on-chain vote doesn’t mean an entity will transfer the funds to you after the fact. You need to have the wallet that will receive the funds set up so the address can be used in the executable code associated with the proposal. The address and the requested amount will have to be a part of the on-chain proposal. If they’re not, no funds will be transferred, regardless of whether the proposal passes or not.
If it’s a multi-sig wallet (e.g. Safe), make sure it’s deployed on Arbitrum. While EOA wallets like Metamask typically share the same address across different networks, multi-sig wallets do not work in the same fashion.
Post-vote implementation
Keep in mind that if your proposal is successful, it won’t be executed for another 14 days after the on-chain vote has concluded. This waiting period is because of the L2 waiting period, the L2-to-L1 message, and the L1 waiting period. You can learn more about the lifecycle of a the proposal and the different waiting periods here.
Resubmitting a proposal
If your proposal fails to pass the temp check or the on-chain vote, you can always revise it and resubmit it. To do so, you need to reflect on the feedback received from delegates, especially the ones who voted against it, make amendments to your proposal, and resubmit it.
It is advised to create a new forum post for the revised proposal which will contain a link to the previous AIP, the reason why the previous AIP didn’t pass, the changes you made to the AIP to
address the concerns raised by delegates and any additional information that differentiates the new proposal from the old one.
Governance process for resubmissions
If your proposal passed the temp-check and failed during the on-chain vote and you only made minor changes based on delegate feedback, you could skip the temp-check phase and go for an on-chain vote directly when resubmitting.
If your proposal didn’t pass the temp check, then you should go through the entire process as outlined above as if the proposal is a new one.