Element’s Governance system was introduced in a previous post, where we highlight the state of decentralized governance in DeFi today, summarize the key features for governing the Element Protocol, and detail our engineering and socioeconomic considerations while building out the system.

In case you missed that first post, the TLDR is that we have built a simplified and participation-minimized form of governance that leverages:

• Vote delegation (i.e. a refined form of representative democracy).
• Capital-efficient voting.
• A community entrusted Governance Steering Council (GSC).

We decided to start with a simple base governance system that allows for improvements, flexibility, and experimentation while successfully maintaining the security and robustness of the protocol.

The core governance system consists of:

• On-chain vote counting.
• Proposal thresholds.
• Custom quorum requirements.
• A timelock for executing security-critical votes.

Additionally, we developed a novel concept called Voting Vaults, which we believe brings a key new primitive to DeFi!

Voting Vaults allow governance users to delegate assets to participate in governance while retaining the ability to use the same assets for any other purpose in DeFi, such as earning yield or leveraging. This means that users can now participate in governance without sacrificing their liquidity!

A look at the Governance Smart Contracts

In its simplest form, a governance system is a mechanism that organizes and makes on-chain calls. These calls are normally permissioned in some way, such as having multiple signers for a multi-signature wallet or token votes in governance systems.

Element’s governance system introduces new ways to manage the delegation of voting power, and the execution of proposals, while keeping it simple. This is accomplished by taking a different approach to how voting power is allocated and introducing different options to execute transactions at various security levels.

Element Governance Architecture Overview Diagram

The Core of Element’s Governance System

The Core of Element’s Governance System is a set of smart contracts that can only execute a call if a vote is in place.

Element’s Governance System is similar to other voting systems such as Maker or Compound, where votes must be collected before making smart contract calls.

Once collected, the votes are counted and a call can only happen when the threshold has been met. However, unlike other governance systems, it does not have a static threshold to make a call. And does not make assumptions about how the votes are allocated, meaning that votes can be allocated in any way the system has agreed to define them.

The core voting contract contains a mapping that checks the threshold needed for a call to be executed and has a default for when the threshold is not set. When a proposal is put forward, the voting results are recorded, and the proposal only passes if the previously observed quorum was met.

Thresholds and custom quorums

The voting threshold needed to pass any call to any individual function in another contract can be reset by governance via a transaction to itself, effectively opening the possibility of having custom quorums.

• Once the threshold is met, a proposal passes on a simple majority check, and anyone can execute it. This means that governance can vary the security threshold on any on-chain action with very high granularity, giving a broad spectrum of possible access control.

In addition to enabling custom quorums, the core voting contract also allows votes to be allocated in highly customizable ways. For example, when a user calls the vote method, they indicate a smart contract (ex: a voting vault), which records how many votes a user has. Afterward, the core voting contract validates if it is an approved contract or not and calls the contract to validate how many votes/voting power the user has.

Since these contracts are external and modular, many possible vote allocation strategies can run in parallel. The system will start with only a few standard voting vaults but could quickly expand to do many custom vote-counting strategies.

Last but not least, the core voting contract can queue its most security-critical votes through a timelock, which adds extra minimum review time to each proposal. If a call is queued to the timelock, it is frozen for ~ 1 week and, during that time, governance can make another vote to recall that proposed group of actions. The most security-critical actions in the protocol, such as upgrades, major spending, and protocol/governance incentives must be executed from the timelock.

Voting Vaults (To Start)

As a summary, the creation of a voting vault begins with defining a strategy for counting votes / providing voting power.

The first voting vault contracts that will allocate voting power in the Element governance system are ones whose mechanisms are familiar to most people who have participated in past or current DAO governance: locking and vesting vaults.

The Locking Vault

The 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. The vault tracks the historical voting power of each address and, when asked for voting power, searches the historical record of that address’ voting power at the time when the vote was proposed.

The Vesting Vault

The vesting vault has the same functionality that the locking vault has, but for vesting. This 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.

As an example of how voting power can be made more general, consider a rewards smart contract we have written. This contract is a play on an optimistic rollup:

1. A proposer proposes a Merkle root which is the rewards balance at the time of the proposal.
2. Then there’s a one week challenge period where the Governance Steering Council (GSC) or governance vote can invalidate that root.

This model allows rewards to be an arbitrarily complex deterministic off-chain program without writing any complex logic into solidity. Since the governance system is abstract enough, you can also vote from confirmed but non-claimed rewards by voting with the rewards contract as vault and giving a Merkle de-commitment to your rewards balance.

In terms of future voting vaults, once the process for establishing logic for counting votes / providing voting power is complete, governance will vote to approve the method, and if successful, the integration is complete, and users can start voting!

Some of the possible future voting vaults consist of:

• Compound/Aave Vault — use tokens as collateral and/or earn interest while keeping voting power.
• LP Vault — get voting power while providing liquidity.
• Ouroboros Vault — deposit Element principal tokens to get more votes than your current balance.
• Identity Verified Vault — verify your digital identity as a unique person to get voting power.
• L2-L1 Synthesis Vault — L2 posts balance tree hashes and L1 votes using the merkel balance proof of L2.

If you have any other creative ideas for future voting vaults, let us know in Discord!

Governance Steering Council (GSC)

The primary role of the members of the GSC is to facilitate off-chain processes, but they also have special on-chain powers (and more may be granted by governance in the future):

• The GSC can propose on-chain votes directly without meeting the minimum requirement of votes (aka spam threshold). As long as a proposal follows the proposal process properly, it can move directly to on-chain voting. This is in contrast to the rest of the governance community’s approach; following the proposal process, an off-chain poll, and lastly an on-chain vote.
• The GSC will have the ability to make calls for actions such as providing grants, operational gas refunds, and bug bounty payouts.

The GSC will have its collective version of a core voting contract with only one voting vault. Anyone with enough voting power in the core voting system (individually or deleted to them) can join the GSC and get one GSC vote within this vault. The membership of the GSC is managed by a ‘king of the hill’ (rolling basis) method, where members can be kicked out from the GSC if they fail to maintain the defined voting power threshold.

The GSC can make calls that have any custom GSC consensus requirement, ranging from one GSC member vote to a supermajority. This means a wide variety of committee-based vote systems can run in parallel to the main voting system! This is accomplished by using a copy of the core voting contract.

Security Roadmap: Audits In-progress!

We are undergoing audits of the core voting system, voting vaults, and initial features from Runtime Verification and ChainSafe. Any bugs identified will be mitigated before the contracts are widely open-sourced and opened for a bug bounty program.

While no system is perfect, in combination with high coverage unit and integration testing, we hope this review will help build confidence in the security of the Element governance system.

What’s Next

As a next step, we are actively talking with our community about our governance model, future voting vaults and governance experimentation. In terms of what’s to come, we will be rolling out more content and updates on our progress, such as:

• Understanding the GSC
• Element Governance Core Principles
• Optimistic Grants Explained
• The Element Proposal Framework and Off-chain Governance
• Security Roadmap Updates

We’re excited about the future of governance and want to hear from you! Join our #governance discord channel and get involved in the discussion!

Join Our Community! 🧝

We want to hear from you! You can always ask questions in our Discord if you need any help, feedback, or just want to learn more about Element.

Twitter | Discord | Website | Github | Docs