Governance Process

This document is meant to provide clarity on the processes involved in governance. Once ratified, these processes are not meant to change frequently in order to maintain stability in the DAO, though it will be possible to surface potential adjustments as appropriate.

Voting Process

Note: These are meant as a starting place. We will together tweak the voting process with feedback from the DAO

There are different categories of proposals that Scroll DAO participants may vote on. Some directly result in onchain activities executed by the timelock; others serve primarily as signals for actions to occur offchain.

Feedback & Iteration

In either scenario (onchain and offchain execution), proposals will typically begin with the proposer drafting and sharing a proposal on the ScrollDAO forum. There, the proposer will receive feedback from other participants until the proposal is endorsed as ready for voting by at least 3 others.

Putting Things Up For A Vote

Once a proposal has been deemed ready for voting, the Governance Manager (an address controlled by an Scroll Foundations’s governance facilitator) may choose to include the proposal in the next voting cycle. The governance facilitator may, in good faith, execute judgment around which proposals to include. For example, the governance facilitator may exclude a proposal that has 3 endorsements from accounts that are suspected of astroturfing. To make it abundantly clear which proposals the DAO is likely to support, it is encouraged to express your endorsement for proposals (as “ready for voting”) even if a proposal already has 3 endorsements.

Voting cycles will typically occur every 4 weeks, but this may be tweaked over time based on the feedback from DAO participants.

Proposals are grouped in ‘voting cycles’ to eliminate the need to constantly be watching for new proposals. The goal is to help reduce voter fatigue and increase delegate engagement, yielding votes that better represent the will of the DAO.

Proposal Types

The Governor Admin (discussed below) can create proposal types in consultation with the DAO. Different proposal types will have different quorum (participants needed for a vote to be valid) and approval thresholds (% of participants voting for a proposal to pass). Proposal Types are selected and socially enforced; if a proposer selects the wrong proposal type, voters should vote against a proposal.

At inception, there are 4 proposal types:

1. DAO Treasury Transfer Standard Vote
   • E.g. Grants & DAO Transfers
   • How it works: Proposal passes. Governor executes automatically via timelock after the timelock delay (3 days).
2. Change Governance Parameters Supermajority Vote
   • E.g. Upgrade governor
   • How it works: Proposal passes. Governor executes automatically via timelock after the timelock delay (3 days).
3. Protocol Upgrade Supermajority Vote
   • E.g. Non-emergency protocol upgrade
   • How it works: Proposal passes (signaling DAO’s support). Security Council executes manually.
4. Social Ratifications
   • E.g. Changes to Constitution / Rights Amendment Supermajority Vote
   • E.g. Updating DAO’s governing documents, processes, etc. Standard Vote
   • How it works: Proposal passes (signaling DAO’s support). Scroll Foundation member executes the will of the DAO and updates appropriately.

Onchain Voting

Once the Governance Manager officially posts votes live on the governance platform (gov.scroll.io), it enters phases:

• Voting delay (3 days) — Once the proposal is first visible on the platform, there is a “voting delay.” During this period, participants can acquire and delegate new voting power, but nobody can vote. At the end of the voting delay, a snapshot occurs. This snapshot captures exactly how much voting power each address has for voting in this proposal. Snapshotting voting power helps prevent vote recycling (e.g. person A votes with 100 tokens, sends them to person B, who then votes with those same 100 tokens).
• Voting period (7 days) — After the snapshot, participants can vote on each proposal.
  • There may be different proposal types which may have (1) different quorum requirements (% of voting supply participating in vote) or (2) different approval thresholds (% of participants who vote for a proposal to pass).

Execution

• If a vote fails, nothing happens.
• If a vote passes, one of several things may happen.
  • Votes that can be executed by the timelock are sent to the timelock (for example, treasury transfers for grants, or changes to the governor parameters (described below). After a passed proposal has been in the timelock for the sufficient amount of time, the proposal may be executed manually by the Governance Manager.
  • Votes that are intended for signaling and not for onchain execution will be executed by the appropriate party. Examples:
    • Social ratification (e.g. amendments to essential DAO documents or processes) will be updated by the appropriate party.
    • Protocol upgrades (e.g. the Security Council will take the suggested changes and execute the upgrades).

Governor Parameters

The Governor is the smart contract that enables the voting process, and officially resolves proposals as passed or failed. The Governor, powered by Agora, is an upgraded version of OpenZeppelin’s governor, which itself is the standard trusted by top protocols to secure billions in value.

The Governor has a variety of configurable parameters that are detailed below.

Note: These values are meant as a starting place as the Governor is initialized. Quorum values may be tweaked depending on the # of $SCR tokens that are delegated.

Governor Manager & Admin

The Governor smart contract accepts two addresses that are granted additional permissions: the Governor Manager, and the Governor Admin.

The Governor Manager’s key permission is the ability to create proposals without regard to the address’s voting power. This address is controlled by the Governance Facilitator.

The Governor Admin is a much more highly permissioned role. It can skip the governance process for the following actions:

• Update the deadline of an active proposal
• Update the voting delay
• Update the voting period
• Update the proposal threshold
• Update the admin address (replaces the current admin for a new one)
• Update the manager address
• Update the proposal type of an active proposal
• Cancel a proposal
• Create or modify a proposal type (altering quorum and approval thresholds)
• Enable or disable a voting module (external contracts that allow you to override the proposal creation and voting logic to enable new types of votes)

Due to its extensive powers, the Governor Admin is a multisig represented by the Security Council (itself a multisig with a high signature threshold).

The Governance Timelock is also always able to access the same functions as the Admin. The Admin can be disabled by transferring the Admin role to the zero address, and re-enabled via a governance proposal to transfer the admin from the zero address to an actual address. The same applies for the manager role.

Emergency Responses

The entire governance system has been designed to mitigate threats posed by bad actors. From requiring certain quorums and approval thresholds to enabling the Governor Admin to be able to veto/cancel malicious proposals, the system has a variety of safeguards built in. Additionally, all smart contracts have been thoroughly audited by the industry’s leading auditors.