[LRFC] Introduce Lyra V2 and Establish Lyra Foundation

[mjs]

Authors: Mjs, Sean Dawson

Simple Summary

Introducing Lyra V2 and establishing the Lyra Foundation.

Abstract

This proposal outlines “Lyra V2”, a platform that can facilitate the settlement, margining and matching of derivatives. It consists of three main parts:

1. Lyra Chain - an Ethereum rollup built with the OP Stack.
2. Lyra Protocol - A generalised risk engine.
3. Lyra Matcher - An open-source order-matcher.

Lyra V2 is governed by the Lyra DAO which earns trading fees from the Lyra Protocol and transaction fees from the Lyra Chain. Trading fees accrue to an insurance fund to foster the robustness of the protocol and rollup. If approved, this proposal will fund the Lyra Foundation in preparation for launching V2. It will not deploy the Lyra Chain or Protocol.

Motivation

Lyra has captured the majority of the on-chain options market with 70-80% of volume. However, it remains a tiny fraction (1%) of the centralized crypto options market, which in turn is dwarfed by markets in traditional finance. This divide is primarily because on-chain protocols lack the performance of their centralized counterparts, which are cheaper to transact on and offer superior margining systems. This lack of performance rules out many if not all professional users. In addition, myriad usability issues deter users from moving their trading activity on-chain.

The challenge for the Lyra community is to meet the market where it is, retaining the benefits of a decentralized protocol - self-custody, transparency and composability - whilst improving performance and usability. The rest of this proposal describes Lyra v2, designed from the ground up to grow the on-chain market by 100x.

Specification

3.1 Lyra Chain

Lyra Chain is an Ethereum rollup built using the OP stack and is the home of the Lyra Protocol. It is a permissionless smart contract platform that boosts performance whilst inheriting Ethereum’s security. In this section, we describe the performance, usability and security benefits of Lyra Chain.

3.1.1 Performance

Lyra Chain will offer Lyra’s users a dedicated execution environment for the protocol, improving several facets of performance relative to the experience on Optimism and Arbitrum. Users can expect the following benefits:

1. Faster confirmations (reduced latency) due to having a dedicated sequencer.
2. Cheaper transactions and a clear path to an order of magnitude reduction with EIP-4844 which will be adopted by Lyra Chain.
3. Less congestion due to not having to compete with other protocols and their users.

3.1.2 Usability

Lyra Chain is being built to provide one of the best user experiences of any on-chain project:

1. It will include a fast bridge that enables users to deposit and withdraw from Ethereum and rollups including Optimism, Arbitrum and others.
2. Users of Lyra Chain won’t have to understand or manage gas. Meta transactions enable users to trade without directly paying gas fees, enabled by third-party relayers.
3. Lyra Chain will proactively integrate native account abstraction features to build a best in class transaction experience.

3.1.3 Security

Like any rollup, Lyra Chain inherits the security of Ethereum by moving computation off-chain to a centralized sequencer while ensuring sufficient data is available to reconstruct valid state in the event of maliciousness or downtime. In its final state, Lyra chain will be able to provide the following guarantees:

1. Liveness - Providing a trustless escape hatch that allows users to withdraw assets in case of sequencer downtime.
2. Censorship Resistance - The ability to transact via Ethereum if the sequencer is actively censoring the user.
3. Dispute Resolution - Creating a fraud-proof to challenge an invalid state root in the case of a malicious sequencer.

It is important to note that these security features are still under active development.

3.2 Lyra Protocol

The Lyra Protocol is a series of smart contracts deployed on Lyra Chain. There are three main components to the Protocol: subaccounts, managers and assets. The Protocol is modular by design, allowing for swift iteration, meaning many of these layers will be further enhanced over time. We now outline the protocol at a high level (for further detail, see the whitepaper).

3.2.1 Subaccounts

Subaccounts are the base unit of the Protocol. All users will be able to permissionlessly mint a subaccount entity which houses all of their supported assets. Subaccounts are ERC-721 compliant NFTs and have two main functionalities:

1. Ensure only authorized parties are able to change the subaccount’s balances.

2. Inform all relevant parties about any trade involving the subaccount.

This was made possible through the use of hooks; external function calls to relevant contracts that occur during and after any asset transfer. There are two such hooks:

1. the asset hook (invokes the asset to validate transfers) and

2. the manager hook (which calls the manager to authenticate the final state of the subaccount).

3.2.2 Assets

An asset contract is responsible for determining the results of a transfer, trade, deposit, withdrawal or settlement. To support deposits and withdrawals, as well as interest accrual, an asset has the privilege to update its own balances in any subaccount.

At launch, there will be four types of assets available:

1. cashAsset: Each manager supports one cashAsset. This is referred to as the quote asset.

2. option: European options on a given underlying asset.

3. perp: Perpetual futures on a given underlying.

4. wrappedERC20: Wrapped ERC20 tokens like wBTC.

Balances for wrapped assets can only be credits (longs) whereas all other assets can be credits or debits (longs or shorts).

Assets and managers are linked; certain assets will only be supported by specific managers and vice versa. This relationship is maintained via the aforementioned hooks.

Each risk manager supports a single quote asset. As with options and perpetuals, users can hold credit or debt balances of the quote asset. Unlike these other assets, users with debit balances will have to pay interest on this sum. This interest is then paid out to all other users with credit balances. Thus, the quote asset facilitates a native lending market over its supported managers.

At launch, USDC will be the only supported quote asset.

3.2.3 Managers

Managers are smart contracts that govern the margin requirements of subscribed subaccounts. At launch, there will be two managers available: the standard risk manager (SRM) and portfolio margin risk manager (PMRM). When creating a subaccount, the user must subscribe to one of these risk managers.

Managers fulfil the following functions:

1. Setting Margin Rules: Managers set the margin requirements of all supported subaccounts. To avoid being subject to liquidation, users must satisfy their maintenance margin mandate. To open a new position, the user must fulfil their (stricter) initial margin requirements.

2. Liquidations: Managers define the conditions for and enforce liquidations.

3. Settlement: The managers are responsible for settling all trades.

3.2.4 Standard Risk Manager

This supports USDC, various base assets (say, wBTC), options and perpetuals and has the following key features:

• Cross Margin: traders use all quote and base balances as collateral for all open positions in a subaccount. Isolated margin is obtained by opening a separate subaccount.
• Multi-asset collateral: traders will be able to use various base asset to collateralize their perpetuals and options. For instance, a user will be able to collateralize a short BTC perpetual with ETH.
• Capital Efficient Spreads: Single short options will the require mark-to-market value of the option and a percentage of the spot as margin. However, the SRM is able to cap the margin requirement of spreads to their maximum loss. This means, for example, that a long $1500/$1800 call spread will require precisely $0 of collateral (and the short spread will be capped at $300).
• Leveraged Perpetuals: Perpetuals can be traded using the SRM with high capital efficiency.
• Borrowing: If enabled, users can borrow the quote asset against their wrapped ERC20 base assets

3.2.5 Portfolio Margin Risk Manager

This also supports USDC, a single denominated base asset and corresponding options and perpetuals. Consequently, if a user wishes to use portfolio margin to trade ETH options and BTC options, then two PMRM subaccounts will be required.

Margin requirements are set using portfolio margin, where the entire portfolio is holistically evaluated at many spot and volatility shock scenarios. The scenario which results in the greatest loss is used, along with extra contingency margin, to set the margin requirements.

Note that both managers use the Black76 pricing model to mark options. Options settle to a weighted combination of the twap of spot and forward price.

Finally, we note that due to the large number of Black76 function calls, portfolio margin computations are very gas intensive. To avoid limiting PMRM account sizes, entities approved by governance called trusted risk assessors will be able to bypass all but one risk (namely, the mark to-market, i.e. solvency) check on chain.

While it is possible for trusted risk assessors to approve transactions that result in liquidatable (but not insolvent!) positions, such accounts can be immediately liquidated by any willing participant, removing this risk from the system. Further, the trusted risk assessor role can be revoked if the party in question is found to be acting improperly.

3.2.6 Partial Liquidations

Users who fall beneath their margin requirements are subject to a partial liquidation. Liquidations will be a transparent process and open to all participants, i.e. any user can act as a liquidator and the user being liquidated will be able to monitor their subaccount throughout this process.

The liquidation mechanism is designed to expeditiously remove risk from the system while at the same time ensuring the most beneficial user experience for traders being liquidated.

Any user can call the function liquidate on any subaccount that is not meeting its maintenance margin requirements. The following then takes place:

• The user’s entire portfolio is put up for auction by its manager.
• The auction begins at a small percentage discount to the portfolio’s mark-to-market value and progressively increases to incentivise liquidators to take on the account.
• Liquidators can agree to take on any percentage of the portfolio at the current discounted auction price. However, this percentage is capped. This bound is a function of the mark-to-market value of the portfolio and its current margin requirements.
• If the portfolio is not liquidated after a sufficient period of time, an insolvent auction begins. Liquidators are paid by the Security Module to take on the portfolio.
• If the Security Module runs out of funds to pay off insolvent debt, then the debt is distributed to all traders via a temporary withdrawal fee.

3.2.7 Protocol Fees

Every risk bearing entity in the architecture can receive fees for doing so. The protocol has three main sources of fee generation, all of which accrue to the protocol owned security module which, when developed, will improve the robustness and resiliency of the protocol:

1. Trading fees: All transactions that increase the open interest (and therefore risk) of the system will be charged a fee. This fee will be a function of the spot price of the underlying asset and size of the trade.
2. Liquidation fees: Users who are liquidated will be charged a small fee that scales with the risk of their account.
3. Interest rate spreads: A percentage of all interest paid by negative cash holders is reserved for the security module.

Entities approved by governance can bypass the trading fee in exchange for, say, a different fee scheme pledge. These approvals can be rescinded if the entity does not meet its requirements.

3.2.8 Parameters and Governance

There are many parameters that govern the protocol; this is especially true for the managers. These parameters also have to be updated whenever there is a market shift to ensure both capital efficiency and security for traders.

All parameters in the protocol are controlled by a smart contract that will b owned by Lyra Governance (i.e. the short executor).

3.2.9 Data Feeds

The managers require oracles to provide the following data in order to accurately assess and control risk:

• Implied volatility (IV): IV for supported tenors will be provided as raw stochastic volatility inspired (SVI) surfaces. These are specified by 5 parameters: (a, b, ρ, m, e).
• Forwards: The forward price for supported tenors is also supplied. Close to expiration, this becomes a linear combination of the TWAP of the underlying and forward price. The weights, as well as the length of the TWAP, are dependent on the time to settlement.
• Risk free rates: This is an interest rate curve defined at each supported tenor.
• Spot: This is the spot (index) price of the underlying assets (ETH, BTC) sourced from multiple outlets.
• Perpetual Price: This is the market price of the perpetual.

Each piece of data supplied also has an associated confidence score. Low confidence feeds result in extra initial margin being required for both the SRM and PMRM.

3.3 Lyra Matcher

Lyra Matcher is an open-source order-matching engine that enables high-performance and low-latency matching at zero cost. It will support all major order types as well as REST and WebSocket APIs for developers. More information on the matcher will be released in a subsequent proposal.

3.4 Governance

Lyra DAO has an on-chain governance model that enables stkLYRA holders to govern Lyra Chain, Lyra Protocol and the treasury. This system also enables service providers (anyone adding value to the ecosystem) to apply for funding. Service providers range from core contributors that work on the protocol to market makers and infrastructure providers.

3.4.1 On-chain Governance

In Lyra V2, on-chain governance will be responsible for various functions across the protocol, chain and treasury:

Protocol

• Setting Parameters
• Launching and deprecating markets

Chain

• Accumulating transaction fees from transactions
• Acting as owner of the sequencer
• Upgrading code

Treasury

• Approve/reject funding requests from service providers

3.4.2 Foundation

This proposal introduces the Lyra Foundation, a not-for-profit legal entity that aims to support the Protocol’s decentralized growth. The Foundation will be able to contract with other entities to provide services for the DAO. The reason for the existence of the foundation is that some service providers cannot deal directly with the DAO via on-chain governance. Some examples are:

1. Those hosting off-chain infrastructure (rollup sequencer and order book) on behalf of the DAO.
2. Agreements and incentive structures to foster liquidity on the Lyra Chain.
3. Providers related to licensing and compliance objectives.

Thus the foundation can help Lyra DAO bootstrap the success of V2 much faster. Over time, these functions are expected to be replaced by service providers who can interface with the DAO. At this point, the foundation will be decommissioned. If this proposal is successful, the following assets will be transferred from the DAO to the foundation:

Asset	Amount
LYRA	100,000,000
OP	750,000
USDC	1,500,000

3.4.2.1 Foundation Key Activities and OKRs

Inspired by Uniswap governance. We propose a number of initial OKRs for the foundation. Its possible that these OKRs will need to change in the future, and if they do, the Foundation must communicate that to the community.

Objective	Key Results
Grow protocol activity	Allocate 50% of LYRA funding, and 70% of OP funding to construct long-term aligned liquidity agreements via market makers and protocol integrations on the Lyra Chain. Success will be measured by metrics including (but not limited to): volume, new users, security module fees generated per incentive.
Support continuous protocol development	Allocate 20% of LYRA funding, 30% of OP funding and 100% of USDC funding to contract with relevant service providers (including core contributors) to develop protocol functionality, including (but not limited to): AMM design and development, automated strategy vaults, new collateral onboarding, autonomous hedging vaults, new partnerships. Success to be measured against metrics including (but not limited to): number of new integrations, integration time for developers, integration volumes.
Act as an advocate for the protocol	Take advantage of beneficial opportunities on behalf of the protocol. Offer service providers clarity, accountability, and competitive contract opportunities.
Treasury Diversification	Facilitate diversification of the DAO treasury to ensure it has sufficient capital to fund long term development and growth of the protocol and ecosystem.

Rationale

Rationale has been addressed throughout the specification.

Test Cases

Test cases will be included in a subsequent proposal with the implementation.

Copyright Waiver

Copyright and related rights waived via CC0 .

[ksett]

so excited to see this proposal go live! what is the rationale for open-sourcing the order matcher? Will V2 and the order matching be launched under some licensing to prevent unauthorized forking of the protocol?

[AlvaroHK]

Great job and good to see the core contributors keep delivering!

A few questions from me:

• What are going to be the trading fees? how much of them will go to the Lyra Protocol?
  If for example fees are 0.025% (options) and 0.05% perpetual, how much is going to Lyra Protocol?

• Security Module/Insurance fund. What initial size would be desired? Will it depend on the trading volume? Will it need to be filled before fees are transferred to Lyra Protocol?

• There are references that Lyra Chain will earn fees from transactions, but also there is reference that transactions are gasless. Could you clarify?

• There are references about AMM and licensed options orderbook build. Are they going to be built by Lyra or by independent 3rd parties?

• Licensing. Is there any way to protect the use of the new protocol only on Lyra Chain? 2 years protection similar to Uni v3 or AAVE v3 would be enough. Builders and developers are welcome but copy forkers could harm the protocol.

[jake]

Thanks Alvaro! Answered below:

1. What are going to be the trading fees? how much of them will go to the Lyra Protocol?

   • Specific trading fees amounts are TBD, but we aim to make them competitive with other exchanges’ maker / taker fees.
   • All trading fees accrue to the protocol-owned security module to rapidly grow its insurance fund, which will act as a backstop and prevent socialized losses in case of insolvencies. This liquidity is governed by token holders.

2. Security Module/Insurance fund. What initial size would be desired? Will it depend on the trading volume? Will it need to be filled before fees are?

   • Great question. I think seeding the security module with some of the DAO’s remaining treasury is the best way to bootstrap confidence in the protocol but this would be specified in a followup proposal to actual deploy v2. IMO $1m USDC would be a good starting amount.

3. There are references that Lyra Chain will earn fees from transactions, but also there is reference that transactions are gasless. Could you clarify?

   • The Lyra Chain will earn L2 gas fees as ETH which accrue on mainnet to the DAO’s treasury, you can read about the L2 gas algorithm here: Configuration | OP Stack Docs
   • Transactions will be gasless for end user, just a simple signed limit order from their wallet, but the matcher which matches orders and submits trades to the protocol / chain will pay for gas in ETH by taking some USDC out of the trading fee.

4. There are references about AMM and licensed options orderbook build. Are they going to be built by Lyra or by independent 3rd parties?

   • This is a great question for the call tomorrow! Will queue it up.

5. Licensing. Is there any way to protect the use of the new protocol only on Lyra Chain? 2 years protection similar to Uni v3 or AAVE v3 would be enough. Builders and developers are welcome but copy forkers could harm the protocol.

   • We’re exploring licensing options for the smart contracts before open sourcing them, agreed that some time-limited protection is a sensible idea.

[mjs]

All DAO-owned software is open source and we would like anyone to be able to run a matcher. This is essential to ensure that V2 can be properly decentralised. Some sort of open-source business license for the protocol (ala Uniswap) could be useful, although I don’t think it’s necessary. Happy to discuss this further as we get closer to launch.

[jake]

Agreed for the matcher and interface, but I think we should explore the possibility of a time-limited business license for the smart contracts for 2 reasons:

1. Liquidity fragmentation: If the protocol is forked we end up with competing / fragmented liquidity across different deployments which hurts UX. Granted this is also true of many matchers being deployed, but we also lose composability between assets since there will be duplicate instances of assets for quote, base, options and perps with every deployment.
2. Security: Similar to the liquidity fragmentation problem, if USDC is fragmented across many security modules it makes every deployment less secure by increasing likelihood of socialized losses in case of an insolvency. Especially in the first 1-2 years, consolidating all fees into one security module will make the protocol extremely robust.

[ksett]

Since the foundation is the one running the matcher and its centralized components, I disagree that this should be open sourced at launch and certainly not if it isn’t protected under a business use license. The DAO should require more information on the matching engine before committing to it being open sourced in this initial proposal. The foundation should be able to charge matching fees to support the infrastructure costs long term and contribute to the security module so I wouldn’t say that the low-latency matching would be at “zero-cost” but maybe more accurately “not for profit”.

I am not supportive of this proposal in its current form and would need the matcher section amended to vote yes.

[Nick]

Agree with @ksett that we should explore the options first. Both protocol and matcher will be groundbreaking, I think it’d be preferable to ensure that the Lyra has a chance to develop network effects before fully open-source.

Other thing I’d like to add the proposal and the foundation’s remit is the ability to engage in treasury diversification activities on behalf of the DAO. Some diversification I think is prudent to de-risk and ensure that the DAO has adequate funding to execute on the v2 go-to-market and beyond.

[mjs]

Agreed with respect to the foundation being able to engage in treasury diversification on behalf of the DAO.

Have updated the proposal to reflect this.

[mjs]

With respect to open-sourcing the order matching engine, the proposal makes no reference to when this would occur, only that it will be open-source at some point. I think the community can decide on a reasonable strategy before launch.