Council Protocol 101

The current state of most on-chain governance is often a monolithic contract with little room for adaptability, customization, or scalability.

Most on-chain contracts require large transaction and audit costs. Monolithic on-chain contracts also create significant friction in conducting routine operations. Each transaction, update, or change to the core protocols requires the consensus of the entire DAO, leading to governance fatigue, slow-moving operations, and overall inefficiencies.

Consequently, DAO governance has skewed heavily towards hybrid governance, which foregoes on-chain execution in favor of off-chain signaling tools such as Snapshot. DAOs employing this model typically verify the chain's status to endow voting power. Once consensus is achieved, they often depend upon trusted community members to manually execute those decisions using multisigs, introducing a single point of failure for operations and a potential security risk.

The Council Protocol introduces a new governance system that allows for improvements, flexibility, and experimentation while successfully maintaining the security and robustness of the Protocol. It entails a set of foundational contracts designed with modularity in mind. Modular governance frameworks allow for customization, enabling DAOs to add and remove modules based on their evolutionary needs. It empowers decentralized governance by leveraging:

• Voting power delegation (i.e. a refined form of representative democracy)
• Capital-efficient voting via a novel governance primitive called Voting Vaults
• A community entrusted Governance Steering Council (GSC)

Core voting and delegation of voting power provide basic functionality for the governance system while voting vaults allow the governance ecosystem to be more inclusive and give governance participants a capital efficient way to be active in protocol governance without sacrificing yield opportunities across DeFi. Delegation, Voting Vaults and the GSC will be explained in more detail later in this guide.

Core Voting

Central to the Council Protocol is the Core Voting Contract. The Core Voting Contract defines voting power, tracks proposals, and measures voting power prior to the execution of any proposal. It also allows various contract parameters to be configured:

• Customizable Voting Strategies: When a user votes, the Core Voting Contract will reference a pre-approved list of voting strategies. These strategies define the calculation of voting power and validate a user's voting power for that particular strategy, enabling multiple methods to exist simultaneously.

• Customizable Quorum: A customizable quorum threshold can be set which checks that the minimum amount of votes required for a proposal's voting results to be considered valid before a contract call to be executed. The quorum value may change as governance begins to understand participation rates but all changes to quorum requirements must be ratified by the governance community. Ultimately, this means that governance can vary the security threshold on any on-chain action with very high granularity.

• Optional Timelock: A timelock is typically only used for security-critical votes. This means increased efficiency for more minor proposals and measured protections for highly sensitive proposals.

An overview of governance roles, voting vaults, and delegation will provide the reader with the requisite knowledge to understand how the baseline framework works and what properties can be configured to suit the particular needs of a DAO.

Governance Roles

Delegates

You can assign all of your Voting Power in the governance system to yourself or someone else, and they can vote on your behalf. This is called Delegation. It's important that you select a delegate who is aligned with your vision for how the DAO should evolve, as your votes would be counted towards their selection.

Governance Steering Council (GSC)

The GSC is a group of delegates, each of whom has reached a pre-established threshold of delegated voting power, giving them additional governance powers within the system, and as a result, additional responsibilities.

The opportunity to be on the GSC is open to anyone and can be earned by garnering enough delegated voting power. GSC members must stay aligned with their delegators and relate to the general sentiments of the governance community to maintain their positions on the Council. Otherwise, they risk losing their delegated votes to another GSC member or new governance community member aspiring to better represent the interests of the community. Removal from the GSC happens as a result of failing to maintain delegated votes and could indicate the outgoing GSC member’s lack of impact or disconnect to the general community of voters.

It is possible for the DAO to change the function of the GSC, including the possibility of adding special functions (propose votes directly on-chain, spend a portion of treasury funds at their discretion, etc.), and various responsibilities (DAO2DAO relationships, collaborations, treasury management, community engagement, etc.), and might (depending upon a vote) be compensated for the time and effort that they dedicate to improving the governed protocol. All of these functions and responsibilities must be defined and ratified through the governance process.

Note: being a delegate and a GSC member is not necessarily mutually exclusive. Learn more in this blog post.

Voting Vaults and Delegation

What are Voting Vaults?

Voting vaults are smart contracts that allow any programmable logic to be used for allocating voting power to governance participants. Some example metrics include:

• Reputation or merit-based systems
• User protocol usage metrics
• User governance participation data
• Token-holding
• Positions in DeFi protocols (staked assets, collateral, LP positions, etc.)
• Any other metric or combination of metrics

Voting Vaults provide the ability to assign voting power to specific types of tokens/positions. The result is beautiful — governance users can maximize capital efficiency while maintaining the ability to delegate or vote when the time comes. Voting vaults are designed to be upgraded, allowing for voting vault logic to be updated by governance and to avoid the pains that come with governance upgrade migrations.

The creation of a voting vault begins with defining a strategy for counting votes or providing voting power. Once the logic has been established, governance will vote to approve the method, and if successful, once the integration is complete, users can start voting.

Examples of commonly used Voting Vaults include:

• Locking Vault – allows users to deposit their tokens into a contract in exchange for voting power, which can also be delegated to a different user.

• Vesting Vault – allows locked / vesting positions to have voting power in the governance system and does so by using a defined multiplier for the vested tokens over unvested tokens.

• GSC Vault – enables a mode of governance that is distinct from other voting vaults; it provides one vote to each member of the GSC. Members can create, vote, and execute proposals if the GSC quorum is met, with quorum set by the DAO.

Learn about some of the possible voting vaults that can be created in this blog post.

How does delegated voting work?

Anyone with Voting Power can assign all of their Voting Power in the protocol to someone else (i.e., a delegate), who may vote on their behalf. This is called Delegation. It is important that the assignor selects a delegate who is aligned with their vision for how the protocol should evolve, as the assignor’s votes would be counted towards their voting selection.

This alleviates the issues of having to keep up with the multitude of discussions that happen surrounding the protocol, and having to interact with on-chain contracts for each decision that needs to be made. Reducing the governance load on each participant ultimately helps to reduce some of the friction and encourage higher levels of voter participation in governance decisions.

Parameters that Governance Operates

General Governance

• Quorum: The required minimum number of voting power in support of a proposal for it to succeed (this value is fixed and not a percentage of total voting power).
• Timelock Duration: The timelock is a speed bump for calls. It requires calls to wait for a defined period before they can be executed. After a call is registered, the call can be removed during the waiting period, and an authorized address can extend the waiting period only once.
• Voting Period: The total voting period in which votes can be cast. [Minimum voting period][extra voting period] is the layout of the total time for voting.
• Minimum Voting Period: The minimum voting time before a vote can be executed.
• Extra Voting Period: The remaining time beyond the minimum voting period in which votes can be cast.
• Proposal Threshold: The amount of voting power needed to submit a governance proposal on-chain.
• Vesting Vault Token Multiplier: The vesting vault contract is used to set up long-term grants for core contributors to the DAOs ecosystem. It is also a voting vault so that community members can vote with vested but unclaimed tokens and unvested tokens. The multiplier for voting power on the vesting vault allows locked / vesting positions to still have voting power in the governance system and does so by using a defined multiplier for the vested tokens over unvested.

GSC Parameters

• GSC Delegation Threshold: A threshold of delegated voting power, giving delegates a seat on the GSC. This comes with additional governance powers within the system, and as a result, additional responsibilities.
• GSC Quorum: The required minimum number of GSC members needed to support a proposal for it to succeed.
• GSC Proposal Threshold: The amount of GSC members needed to propose a GSC vote on-chain.

Protocol Parameters

• Protocol Upgrades: Should the governed DAO community decide to upgrade the governed Protocol, it will go through governance. These types of changes will go through the process defined for Protocol Proposals.