LogoLogo
WebsiteAppDocs
  • Getting Started
    • πŸ€™Overview
      • Intro to Shell
      • White Papers
      • GitHub Repositories
      • Contract Addresses
      • Roadmap
      • Community
      • Ecosystem
    • πŸ—£οΈGovernance
    • 🀝Integrations
      • Protocol Adapters
      • Shell-Native Primitives
        • Stable Token AMMs
        • Volatile Token AMMs
        • NFT Fractionalizer
        • NFT AMMs
        • LBPs (Liquidity Bootstrapping Pools)
        • Managed Pools
        • Pools for Large Swaps
    • πŸ› οΈDevelopers
      • What to Build on Shell
      • Aggregating Pools
    • πŸ›‘οΈSecurity & Bounties
    • ❓FAQ
  • SHELL DAO
    • 🌺Overview
    • πŸ›οΈShell DAO Permissions
    • 🐟SHELL Token
      • Airdrop Eligibility & CRAB
      • Sablier Vesting Stream SHELL
    • β˜‘οΈveSHELL Staking
    • βš–οΈGovernance Process
      • Governance Stages
      • Delegating Votes
    • ➰Mutable Protocol Fees
    • πŸ”“DAO Multisig
    • 🍭Toucan Votes
  • User Guide
    • 🎟️Earn Rewards
      • Shell Points (Concluded)
      • Bro Kwon's Booty
      • Get Quota
      • Multipliers and Boosters
      • Dynamic Multipliers
      • Crafting
    • 🎁Wrap Tokens
    • βš”οΈLP in a Pool
    • 🐣Wrap NFTs
    • 🀺LP in an NFT Pool
    • πŸ”„Swap NFTs with an AMM
    • 🧭Shellscan
    • 🌴All About Toucans
    • πŸ§‘β€πŸš€Using Arbitrum
    • πŸš›Migrate from Shell v2 (Retired)
    • 🚚Migrate from Shell v1 (Retired)
    • πŸ–ΌοΈArt of Shell NFTs
  • How Shell Works
    • 🐚Architecture Overview
    • 🌊The Ocean: Accounting Hub
    • πŸ”±Proteus: AMM Engine
    • πŸ’ΈIntents (MEV Harnessing System)
    • 🌚Why Arbitrum
    • 🍧Shell v1 (Retired)
    • πŸ’§ShellDrop DAO (Retired)
  • Shell Lore
    • πŸ‘οΈHidden Fortune
Powered by GitBook
On this page
  • Stage 1: Request for Comment (RFC)
  • Stage 2: Discussion
  • Stage 3: Snapshot Vote
  • Stage 4: Results and Execution
  1. SHELL DAO
  2. Governance Process

Governance Stages

PreviousGovernance ProcessNextDelegating Votes

Last updated 1 year ago

Stage 1: Request for Comment (RFC)

In the initial stage, the author posts an RFC to the Shell governance forum on Commonwealth. Anyone may author and post an RFC. To create an RFC, navigate to the Proposals Category on Commonwealth and create a new topic.

  • Forum post title must follow the format: "RFC: [Category]/[Your Proposal Title]"

  • The text of the post must follow the format in .

  • Have an idea for an RFC? Before making a formal post, consider first sharing your thoughts, concerns, or goals on the forum to get early feedback or co-authors. You may then link to this discussion when you post the RFC.

Forum moderators will check that RFCs follow the correct format. If there are any issues, the author will be notified and invited to repost the RFC properly.

Stage 2: Discussion

During this stage, the community can provide feedback and help author(s) modify or revise the proposal. It is recommended to allow at least one week for open discussion. Complicated or controversial proposals may benefit from a longer discussion period.

  • Authors are expected to be active participants in the forum discussion.

  • As the author, you are the champion of this proposal! It's up to you to promote the RFC, get feedback and inspire voters.

  • Consider using supplemental discussion platforms, such as Discord or Twitter spaces.

  • Reach out to veSHELL delegates for their support.

  • Be open to making changes to your proposal as needed.

Stage 3: Snapshot Vote

Once the author(s) consider the proposal finalized, it's time to move to a vote.

The Snapshot process begins when an address with at least 2000 veSHELL (individually or by delegation) posts a Proposal that meets all of the required specifications.

A valid Snapshot vote must adhere to the following.

  • The proposal must provide a link to the forum post of the respective RFC.

  • The order of vote options must be as follows. (The order is important to reduce noise resulting from users who always just click the first option.)

    1. ABSTAIN

    2. NO

    3. YES

  • The vote must run for 10 days.

  • The vote must have a quorum of 10% of the total supply of veSHELL, as measured at the block it was proposed.

  • If the proposal receives more β€œYES” votes than "NO" votes, it will be considered β€œPassed”.

  • If applicable, the linked payload must match the specification.

One veSHELL token = one vote.

If a vote fails, it will not be executed. You may post it again to Snapshot for a re-vote, but you are encouraged to wait at least one month before doing so, unless other circumstances have meaningfully changed. This is to reduce spam and be considerate of the time and energy required for proper governance.

A Snapshot vote that fails to meet all of the above requirements will not be valid, even if it wins a majority of the votes.

If you're unsure, don't be shy! Ask for help.

Stage 4: Results and Execution

In case of a delay, multisig signers must post regular updates to the Forum on the Proposal's thread providing an explanation and relevant details.

Keep in mind the DAO's on-chain capabilities are limited. All other votes will be executed off-chain following the steps described in the proposal.

If a vote requiring on-chain activity passes, the must then execute the vote as soon as possible, at maximum within one week. Upon transaction execution, community moderators are expected to post a comment on the forum thread with a link to the transaction.

βš–οΈ
DAO Multisig
Proposal Template