XGA: eXtensible Gas Auctions for enabling Preconfirmations without Restaking or ePBS

Proposals
1

XGA: Enabling Preconfirmations without Restaking or ePBS

XGA or eXtensible Gas Auctions is a platform developed jointly by Manifold Finance and 20[1]
Manifold Finance has operated the only original non-censoring Relay since the Merge and 20sq has done mechanism design and review using their open source “Open Games”[2] engine for projects like Flashbots regarding PBS (see https://github.com/20squares/pbs-auctions/tree/master/pbs-og) and more. They have additionally written extensively on the topics of Blockspace (see https://blog.20squares.xyz/correctly-pricing-txs-parallel/) and MEV (see https://blog.20squares.xyz/mev-cui-bono/).

The documentation for XGA is live at docs.xga.com & source via GitHub

Preconfirmations using a Forward Contract Market

The XGA platform revolutionizes the way block space is allocated to builders and searchers, making it more dynamic and accessible. The auction is implemented on a L2 Rollup based off the OP Stack with minimal changes. The Auction is currently deployed and live on main net[3] ethereum.

Validators simply need to connect to our new relay implementation, and run an updated Vouch or MEV Boost client. That is all the onboarding process really involves. There is no restaking, no risk to capital for the validators. This proposal would necessitate the adding of the new relay to the Relay must include the list for Lido validators. The onboarding process and current status is discussed more in the #roadmap section.

Call Market mechanics

XGA facilitates the allocation of blockspace by dividing each block into two parts instead of selling it as a single monolithic entity. One part is designated for high-priority, time-sensitive transactions (⍺-blockspace), while the other is reserved for less urgent transactions (β-blockspace). This segmentation allows users to select the most cost-effective and suitable space for their needs, enhancing transaction efficiency and user value.

MEV Boost compatibility

The second change includes the timing of sales. The first part of the block is sold through mev-boost as is common now for most blocks. The second part of the block is sold as a form of preconfirmation. That is, if a block gets minted at time t, the bottom part is sold in a pre-defined period before. This part is sold in a multi-unit way meaning that several bidders can win blockspace for this part.

Winners of the beta part of block b can then submit their bundles before the block gets actually minted. In effect, winners of the auction get an inclusion guarantee beforehand. Winners simply “burn” their position on the L2 and submit their L1 transaction.

In version 1.0, the final merging of alpha and beta portions of the block are handled by our specially designed relay. This relay is live on mainnet at https://mainnet-auction.securerpc.com. Version 2.0 eliminates this privileged service requirement.

Validator Participation without Slashing or Loss Risk

On the validator side, to participate, a validator must be permissioned to register with this service (the relay). Practically, the validator places the relay as a privileged service. This means that it will ignore bids from other relays during a defined time window, and if it fails to receive a valid response from our relay, it will then consider other bids from other relays. If the validator does not get a valid proposal from our relay, it then will pick the highest submitted block it has got from all other relays. Therefore, there is very little remunerative risk from the validator perspective. Any additional risk is covered by our “Captive Insurance” program, in which we cover any costs that are incurred due to assurance violations.

This logic is to ensure against potential service disruptions causing losses for validators. It also provides an enforcement mechanism for the forward contracts to begin with without resorting to slashing. This is why validators must also be approved to register with the relay to participate for version 1.0.

Captive Risk Retention protects Validator Revenue and Capital

Captive Risk Retention (or “Captive Insurance”) is our risk management protocol, which the primary purpose is to insure the risk related to the relay and auction. It provides a direct relationship between the insured and insurer, and is incentive aligned. The aim is to protect validator stake, earnings and market participants against service outages or other exogenous disruptions , ensuring continuity of potential profits and explicit protections for participating parties.

2.5% gross is taken from the ß-auction into the backstop fund. This amount can be adjusted. Should claims exceed the backstop fund, a pro rata charge is applied to the protocol vault of staked assets and liquidated into ETH to cover the shortfall.

Coverage Scope

Service Downtime

Provides compensation for any periods when the relay service is either inoperable or inaccessible.

Incorrect or Malicious Proposals

Offers protection against losses arising from incorrect or malicious block proposals made by the relay.

Performance Degradation

Ensures coverage in cases where the relay’s performance deteriorates significantly, affecting validator operations.

The insurance protocol seeks to provide coverage against a validator not having access to both MEV Boost Auction and the XGA Auction. The MEV Boost auction is protected by failover capacity of 3rd party relays (as described earlier). So long as this mechanism is correctly working, this greatly limits the liability in terms of potential losses that XGA could end up being on the hook for.

Additional MEV Improvements and Integrations

Builder/Searcher Separation

Searchers no longer need to vertically integrate with builders to enhance their inclusion rate. This is an important development in the market structure as it will lead to more truthful bidding (i.e. higher bidding). Searchers can now focus on their strategies without having to develop relationships with existing builder incumbents. Thus the barrier to entry is reduced, increasing competition overall and leading to higher validator MEV reward share.

Contract Bidding Strategies

By utilizing smart contracts for bidding and introducing a novel tie-breaking rule that emphasizes competitive pressure over simple high bids, the platform encourages fairer pricing and maximizes the value obtained from each auction. This has the added benefit of providing a way for smaller participants to avoid the latency game of request-response based bidding (i.e. API based).

Blockscout support for Preconfirmations

We are working with the Blockscout team to provide first class support for preconfirmations visualization and tracking for users out of the box. We are currently using Blockscout for the L2 rollup explorer.

Eligible Node Operators

The following Node Operators are eligible to participant in the first cohort. They are listed below in no particular order. Eligibility is determined using rated.network’s information regarding CL client usage. Due to the way that Prysm and Nimbus clients have implemented the Builder API v3 they would require changes to the CL client which we prefer not to do.

As a Node Operator, you only have to run a slightly modified MEV Boost client or a modified Vouch client. This modification is to ensure that the failover capability is handled by the node operator, and not a centralized load balancer.

Node Operator
CryptoManufaktur
Allnodes
Kukis Global
Attestant
Chainsafe
Klin
ChainLayer
Stakely
Chorus One
Figment
Sigma Prime
A41
Stakin
StakeFish
Staking Facilities

Legal Risks

XGA has retained the council of Michael Frisch[4], Mike’s experience with cryptocurrency began at the Commodity Futures Trading Commission (CFTC), where he brought one of the CFTC’s first enforcement actions involving cryptocurrency — CFTC v. Bitfinex — and was part of the team responsible for the CFTC’s action against Tether in 2021. While at the CFTC, Mike was part of the litigation team in CFTC v. Monex, a landmark case concerning the applicability of Section 2(c)(2)(D) of the CEA, and contributed to the CFTC’s Final Interpretive Guidance on Actual Delivery for Digital Assets.

Roadmap

XGA is live on mainnet Ethereum, today. We have already signed Frax as our initial launch partner for main net and they have been testing with us for the last 6 weeks on Holesky. We expect by late next week to begin adding their validator set to the relay.

XGA LST Chart May 25_1
XGA LST Chart May 25_11872×2736 562 KB

Contact

We maintain a community telegram channel that is active and participatory, join t.me/manifoldfinance or our forums.manifoldfinance.com

Disclaimer

The content and information presented on this post (here after referred to as "Content") is for informational and educational purposes only. The Content is explicitly not intended to be suitable for any specific purpose, including but not limited to commercial use, and it is explicitly not intended to meet any merchantability requirements. Furthermore, no warranty or representation, whether express or implied, is made as to the Content's suitability for any specific purpose. This Content does not constitute professional financial advice, investment advice, trading advice, and should not be relied upon for making personal, financial, investment, or trading decisions. The Content is provided strictly "as is" and "as available", without any warranties or representations, either express or implied. This includes, but is not limited to, warranties of accuracy, completeness, reliability, or timeliness. The post's authors and administrators, and any entity associated with them, do not make any representation or warranty regarding the Content and do not accept any responsibility for any loss, damage, liability, or expense suffered by you, the User, or any other person or entity as a result of reliance upon the Content.  The Content is general in nature and does not consider your specific circumstances, financial or otherwise. Before you make any decisions or take any actions that might affect your personal finances or investments, you should consult a qualified professional financial advisor or broker. This post is hosted on a website that is accessible globally, but this does not imply that all Content provided or offered through this website is appropriate or available for use in all jurisdictions. If you access this website (i.e. this post), you do so at your own risk, and you are responsible for compliance with local laws and regulations.  Please note, the laws and regulations regarding financial advice differ between countries, particularly between the United States of America, the United Kingdom and the European Union. Users should not construe any of the Content as legal advice and should consult a legal professional in their respective country to ensure adherence to local laws and regulations.  By reading this proposal, you accept this disclaimer in full. If you disagree with any part of this disclaimer, you should not continue to read this proposal.

Footnotes

  1. 20squares or 20 ↩︎

  2. GitHub - CyberCat-Institute/open-game-engine: Haskell implementation of open games ↩︎

  3. see https://mainnet-auction.securerpc.com ↩︎

  4. see https://crokefairchild.com/team/michael-frisch ↩︎

6 Likes
2

For Governance Consideration: XGA Proposal

In the proposal Lido on Ethereum Block Proposer Rewards Policy, we propose adding to this Policy explicitly support for XGA. As detailed in D.3 Implementation adding to the section ‘Available Infrastructure’ XGA[1]. The stated policy purpose and scope of the proposal includes Maximizing Staking APR, and Minimizing MEV hiding, goals that XGA extends further than MEV-Boost or any other alternative in the Ethereum Roadmap, including but not limited to ePBS, Execution Tickets, Inclusion Lists, and other variations of such proposals.

Please see the documentation, https://docs.xga.com for more detailed information about the auction and platform configuration.

Requirements Scope

This is for v1 of XGA

  • Participating validators must use the new XGA Relay Endpoint in a privileged manner. We define Privileged as being:

:round_pushpin: Using a specified external block builder without checking for circuit breaker conditions nor giving local block building any weight in scoring.

This behaviour is required for v1. In v2 of XGA we will have multi-relay support and it will no longer be the case for having this requirement. In fact some clients already have such features built in

:round_pushpin: Set PARAMETERS with the following for both mainnet and holesky using add_relay (0x2e21ecef) by an authorized address from the Lido DAO

MEV Relay Parameters

uri (string): https://0xad2c0074aa2bb6149340187906196f719bbac701a20d0cc88baefd2bbcc9fc970fb060d5eeb5fedf22024db6e69582da@mainnet-auction.securerpc.com

operator (string): Manifold Finance

is_mandatory (bool): true

description (string): non-filtering

MEV Relay ABI

/// 0xf95f069f9ad107938f6ba802a3da87892298610e
[
  {
    "type": "string"
  },
  {
    "type": "string"
  },
  {
    "type": "bool"
  },
  {
    "type": "string"
  }
]

Reference hex raw transaction data

0x2e21ecef0000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000180000000000000000000000000000000000000000000000000000000000000008868747470733a2f2f3078616432633030373461613262623631343933343031383739303631393666373139626261633730316132306430636338386261656664326262636339666339373066623036306435656562356665646632323032346462366536393538326461406d61696e6e65742d61756374696f6e2e7365637572657270632e636f6d00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000104d616e69666f6c642046696e616e636500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d6e6f6e2d66696c746572696e6700000000000000000000000000000000000000

Note, the Relay contract on Holesky contains an additional parameter indicating if the relay does ‘Filtering’. The relay is non filtering.

  • Develop a testing trial period for selected node operators for both test net and mainnet. XGA has been on Holesky for the last 2 months and producing correct blocks. Additionally, mainnet will have an existing validator base from FRAX at launch-open. Our proposed testing and validation period is no more than 6 weeks, the same period of time MEV Boost was given. Risks of service disruption are additionally explicitly covered by the Captive Risk Retention protocol, making the safety case analysis mitigated[3]. The testing trial period shall be a mix of both mainnet and testnet, with boundaries of the process being defined and driven by the Lido NOM committee.

  • A satisfactory trial period is defined as whether the primary claims of XGA are valid. This is where architectural and design decisions are normally validated.

  • Promote the usage of the platform for end users and protocols.

  • Mechanism changes shall only be effected by 20squares.

  • In furtherance of protecting the platform, a gross fee taken on only the beta-auction results of 2.5% is retained for the Captive Risk Retention protocol. This parameter is mechanism related

  • The relay will advertise a different gas limit than what validator registration typically submits. This is done for the purposes of the MEV Boost auction, the gas limit is still the combined normal 30 Million.

  • If desired, Manifold Finance will hire a 3rd party auditing firm to provide additional validation for the purposes of the trial period and for validating service operational claims are well behaved.

Defining Satisfactory Trial Period

This section may be updated as the trial period is underway based off of real observed events, etc.

  • The relay will not send blocks that could make validators get slashed.
  • The relay will not send blocks bigger than the gas limit used in validator registration.
  • The relay will not use a false bid value.
  • The relay operates as advertised, with service disruptions recorded.
  • No new risks related to increasing reorg risk substantively are observed.
  • Profitability assessments must be forecasted and extrapolated from the current validator set to at least the entire Lido validator set for the purposes of discussion regarding cost-benefit or other such revenue analysis. This is because the auction scales with more participating validators.

Any additional argument structures must be able to have demonstrable evidence to back such arguments claims. Eliminative Induction would not be an appropriate methodology in this case.

Contravening Points

The Rewards Policy states in

  • Be fully tested by all Node Operators prior to usage on mainnet

Our initial draft testing and mainnet onboarding explicitly does not include all node operators for the simple fact that there are two CL clients (Prysm and Nimbus) that do not conform correctly to the Builder V3 API as of May 2024. Modifications can be made to the respective CL clients, however we would prefer not to have to maintain such fork changes. We would like to advocate for those Node Operators whom are interested in testing to switch to a new client, Grandine. This can provide an opportunity to introduce a new, high performant CL client which would further CL diversity. The Grandine client in fact has support out of the box for our requirements for v1.

:warning: Important - It should be noted that this only applies to v1 of XGA, for v2 this should not be an issue, as multiple relay support will be available.

  1. The list contains MEV-Boost and Default Block Building as of 05.2024 ↩︎

  2. We have already submitted such changes to the Vouch repo. Thanks to Jim for being receptive and informative. ↩︎

  3. See ISO/IEC/IEEE 29119-1:2022(E) for terms related to risk-based testing, section 3.131 ↩︎

6 Likes
3

Thanks to Attestant (re: Jim) for accepting our PR for upstreaming the changes to Vouch: Merge pull request #206 from manifoldfinance/priority-builders · attestantio/vouch@4b15f5c · GitHub

A forked client will not be necessary to run now.

4 Likes
4

I would like to hear @Hasu or @vsh or anyone else from the Lido team’s thoughts given this has been 6 months and we have progressed to already V2.