Lyra governance empowers LYRA token holders to actively participate in the decision-making process of the Lyra DAO.

Overview

Token rights

By staking LYRA tokens to receive stkLYRA, holders obtain governance powers proportional to their balance. There are initially two powers associated with the stkLYRA token:

1. Proposal right: Allows the creation of a new proposal.
2. Voting right: Enables voting on existing proposals.

Delegation
Holders can choose to delegate one or both of their governance powers. Delegation helps Lyra Governance retain the benefits of a council-based model, where less informed participants can delegate their voting power to more knowledgeable members without introducing the implementation risks associated with off-chain models.

LEAPs
A LEAP is any proposal that impacts the protocol, treasury or governance framework. It has been adapted from industry standard frameworks, such as EIP and BIP. Examples may include protocol changes (listing new markets and changing parameters), treasury actions (allocating LYRA tokens and remunerating service providers) as well as meta-governance updates (changing the governance process itself).

Each LEAP must include the following elements:

• Simple Summary: A clear and accessible explanation of the LEAP for a layperson.
• Abstract: A brief description of the LEAP.
• Motivation: A justification for the LEAP, explaining why the current system is inadequate to address the problem.
• Specification: A detailed outline of the proposal's process and structure.
• Rationale: An explanation of design decisions made, alternate designs considered, and related work.
• Test Cases: Test cases are required for code-related proposals (excluding treasury actions).
• Copyright Waiver: All LEAPs must be in the public domain.

Architecture

Governance Contract

The governance contract is to facilitate decentralized decision-making and enable the Lyra community to have a say in the development and management of the protocol.Some key features and purposes of the governance contract include:

1. Proposal Creation: It allows users to create proposals for changes to the protocol.
2. Voting: Token holders with sufficient voting power can vote on the proposals submitted. The governance contract takes into account the voting power of each participant, ensuring that the decision-making process is fair and transparent.
3. Proposal Execution: If a proposal receives enough support (based on the quorum and majority thresholds), the governance contract executes the proposed changes, updating the protocol as needed.
4. Delegation: Token holders can delegate their voting power to other users or entities, allowing them to participate in the governance process on their behalf.

Governance Strategy

• Contains logic to measure users' relative power to propose and vote.
• A user's power is calculated as their balance of stkLyra including any token power delegated to them and excluding any token power delegated to another address.

Timelocks

• The short time lock executor can execute proposals that changes part of the Lyra protocol or any treasury proposals.
• The long time lock executor can execute proposals that handles execution of stkLYRA and meta governance proposals.
• The Optimism Executor is able to receive cross-chain transactions originating from the short time lock executor and queue proposals to be executed on Optimism.
• The Arbitrum Executor is able to receive cross-chain transactions originating from the short time lock executor and queue proposals to be executed on Arbitrum.

Actors

• Proposers: Proposers are individuals or entities who create and submit proposals for changes or improvements to the protocol. These proposals can include updates to smart contracts, adjustments to key parameters, or new features that can enhance the protocol's functionality.
• Voters: Voters are stkLyra token holders who participate in the governance process by voting on submitted proposals. They have the power to approve or reject changes to the protocol based on their assessment of the proposal's merits and potential impact on the ecosystem. Voters can either vote directly, using their own tokens, or delegate their voting power to other users who can vote on their behalf.

Process

The process follows these main steps:

1. Creation
   Anyone can write a Lyra Request For Comment (LRFC) using the template available on the governance forums.
2. Community
   The LRFC is posted for community review and discussion. The authors should incorporate feedback and seek rough consensus.
3. Snapshot vote
   A snapshot shot vote is recommended to assess the sentiment before progressing to the slower, more expensive on-chain voting process. Any community member with more than 10,000 stkLYRA can create the snapshot vote. This requirement increases the cost of attacking the snapshot voting system. For proposals that don’t require an on-chain smart contract call, notably changes to the trading and liquidity rewards formulas, the snapshot vote is considered the binding and final vote.
4. On-chain vote
   The LEAP is submitted to the Lyra Governance system for stkLYRA holders to vote on.
5. Execution
   If approved, the LEAP's payload is sent to the relevant timelock for automatic execution. If rejected, no further action is taken.

Technical

Deployed Contracts

Audits
All contracts besides Lyra and the LyraGovernanceStrategy are unchanged versions of the AAVE governance V2 contracts, which can be found here. LYRA is a deployment of the openzeppelin standard ERC20 contract. LyraGovernanceStrategy was checked by IOSIRO in the following report (along with other future governance contracts):

IOSIRO Audit

Voting Process

1. Creation
   A proposal can be created by calling the create() function on the LyraGovernanceV2 contract. The caller must have a proposer power greater than the threshold and they must maintain it until the proposal is executed. After the proposal is created it assumes the PENDING state until the vote begins.
2. Voting
   Voting begins after the votingDelay has elapsed, a value which can be read from getVotingDelay(). At this point, a snapshot of voting powers is taken and can no longer be delegated/transferred for the proposal being voted on. The proposal state is ACTIVE and users can submit a vote for or against the proposal, weighted by the user's total voting power (tokens + delegated voting power), within the allotted [VOTING_DURATION].
3. End of Voting
   For a proposal to pass the voting power of for-votes needs to reach the quorum set by the [MINIMUM_QUORUM] parameter. In addition, the difference between for-votes and against-votes (in % of total voting power) needs to exceed the vote differential threshold set by the [VOTE_DIFFERENTIAL] parameter. If the proposal has passed, then the proposal state becomes SUCCEEDED, otherwise, it is FAILED.
4. Queuing and execution
   A SUCCEEDED proposal can be queued and will be executed after the execution delay and before the grace period expiration. The delay can be fetched from getDelay() and the GRACE_PERIOD can be fetched from GRACE_PERIOD().
   The validation and execution of the proposal are performed by the time lock executor. A queued proposal state is QUEUED. A successfully executed proposal state is EXECUTED. If a queued proposal has not been executed before expiration, then the proposal state is EXPIRED.
5. Proposal Canceling
   If the proposal creator's proposal power decrease and no longer meet the PROPOSITION_THRESHOLD, any user can cancel the proposal. In addition as an initial safeguard to the protocol, the guardian account, controlled by a community multisig, is able to cancel a proposal before a proposal is executed. A cancelled proposal state is CANCELED.