⚖️Governance Process
Step by step guide to participating in Shell DAO governance
Overview
There are four stages in the Shell governance process.
User posts an RFC (Request for Comment) to the Shell governance forum.
Open discussion so the community can provide feedback and revise the RFC. (Suggested 1 week minimum)
Anyone with at least 2000 veSHELL in delegation can put the Proposal on Snapshot for a community vote.
If the vote is successful and on-chain actions are required, the Shell DAO Multisig will execute it as specified in the Proposal.
Forum: https://commonwealth.im/shell-protocol/
Snapshot: https://snapshot.org/#/shellprotocol.eth
Proposal Template
All proposals must follow a standard format to be considered valid. At this time, only English-language proposals are accepted.
If a field is not relevant for a proposal, write in N/A. Additional fields may be added to the template if necessary, according to the author's discretion.
TITLE
Thread title should adhere to the format: RFC: [Your Proposal Title] (Category)
OVERVIEW
Title: [Your Proposal Title]
Author(s): Enter name(s) of authors.
Category: [Constitutional/Protocol Fee/ShUIP/Builder Program/Miscellaneous]
Related Discussions: Paste links here, if applicable.
DETAILS
Summary: Provide a brief, simple summary of your proposal in 2-3 sentences (aka the TLDR).
Link to Transaction Payload PR: If the proposal requires on-chain actions, include a link to the transaction payload PR on GitHub.
Motivation: Explain the key problems this proposal will solve.
Vision: Discuss your goals and examine ways this proposal might impact the ecosystem on a technical, financial, or governance level (or all of the above). How would it affect the Shell DAO, the protocol, or the veSHELL ecosystem? Include links for background reading, if applicable.
Specification: Follow guidelines in the Proposal Categories. Share a breakdown of implementation details, including any technology or platforms to be used. Describe each step with associated costs or development resources, etc.
Benefits (Pros): Summarize key benefits.
Downside (Cons): Disclose any potential risks or downsides.
Overall Cost: The total cost to implement this proposal.
Timeline: Specify important dates or deadlines (e.g., start/end dates, milestones).
VOTING OPTIONS
Abstain: Clearly define the terms/results of an "abstain" vote.
No: Clearly define the terms/results of a "no" vote.
Yes: Clearly define the terms/results of a "yes" vote.
Proposal Categories
Proposals may be of five categories: Constitutional, Protocol Fee, User Incentives (ShUIP), Builder Program, and Miscellaneous.
1. Constitutional
Constitutional proposals are meta-governance proposals designed to modify the Governance Process.
2. Protocol Fee
Shell Protocol has a singular protocol fee applied only to "unwraps" (liquidity that leaves the ecosystem). The fee has a hard-coded cap of 0.05% and is initially set to zero. Revenue from the protocol fee accrues to the Shell DAO.
Protocol fee proposals are solely about raising or lowering the percent fee.
3. User Incentives (ShUIP)
The DAO has the ability to use its treasury to incentivize the growth of the protocol’s users. These incentives will fall under the Shell User Incentive Plan (ShUIP).
High-level, a ShUIP will incentivize specific on-chain behavior. Rewards will be calculated off-chain. Periodically, these rewards will be pushed to a Merkle root on-chain where users can then claim their tokens.
Once a ShUIP has passed a Snapshot vote, a few extra steps will be necessary.
On-chain actions are tracked off-chain by the designated party, and hence so are rewards. In order to hold the designated party accountable, rewards will not be transferred from the DAO Treasury until after the exact rewards have been calculated.
After the reward Merkle root has been posted, there will be a holding period to contest the results. If no objections are raised within this period, the Multisig will disburse the rewards as indicated.
ShUIPs should include the following information in the Specification.
Which token(s) from the DAO Treasury will be used, and the amount (e.g. 1,000,000 SHELL)
The duration of the proposal (e.g. 100 days)
The on-chain actions that will be tracked (e.g. LPing in the SHELL+ETH pool)
How to calculate the reward based on the on-chain action (e.g. 10,000 SHELL each day, given out proportionally to the user’s share of the total LP token supply)
A designated party to track users’ on-chain actions off-chain (e.g. Cowri Labs). The designated party must also agree to carry out the ShUIP, should it pass
Length of holding period to resolve disputes (e.g. four days)
Designated party’s incentive/payment (e.g. 1000 SHELL tokens)
How often rewards will be released (e.g. every 2 weeks)
Whether rewards will be subject to a lock-up, and if so, for how long? (e.g. 2 year linear lock up)
4. Builder Program
The DAO can use its treasury to incentivize protocol and ecosystem development. Once a Builder Program proposal has passed a Snapshot vote, a few extra steps will be necessary.
Depending on how project milestones are tracked or reported, they may be monitored off-chain by the designated party, in which case so are rewards.
In order to hold the designated party accountable, rewards will not be transferred from the DAO Treasury until after the designated milestone is reached.
After agreed-on progress reports are released, there will be a holding period to contest the results. If no objections are raised within this period, the Multisig will disburse the rewards as indicated.
Builder Program proposals should include the following information in the Specification.
Project name
Project category (Protocol integration, Shell-native primitive, Dapp, Shell Protocol Improvement, Developer resources, etc.)
Team information (Include company or team members and relevant contact info)
Deliverables or metrics that will be tracked (e.g. product releases, media episodes, number of hackathon attendees)
Maintenance and Upgrade Plans
Budget breakdown, including which token(s) from the DAO Treasury will be used (e.g. 50,000 SHELL and 50,000 ARB)
How to calculate the reward, if it varies with deliverables or metrics
Whether rewards will be subject to a lock-up, and if so, for how long? (e.g. 2 year linear lock up)
How often rewards will be released (e.g. every 2 weeks)
Reporting requirements to track progress and maintain accountability, or the name of the party responsible for monitoring progress (e.g. GitHub updates or status briefs posted to the forum, or Shell Foundation)
Additional info
5. Miscellaneous
For all other proposals, use Miscellaneous.
Last updated