Support of L1 Validators is critical in building the marketplace and creating off-the-shelf product availability for buyers. As such, we have designed both the Marketplace and Product suite to align highly with their interests.
ETHGas is designed to unambiguously earn more than running MEV Boost alone with both minimal risk and minimal technical integration required.
Validators with staking enabled can enjoy certain % of trading revenue via our Staking Incentive Program (Details soon)
To get started, Validators must use Commit Boost and transfer the appropriate Collateral.
Commit Boost is a sidecar for proposers to create commitments. Validators need to run Commit Boost which uses a validator BLS key to sign messages signaling their intent to register on ETHGas exchange platform and delegate to more sophisticated parties (e.g. our Pricer server) to sell preconfs
Link: https://github.com/ethgas-developer/ethgas-preconf-commit-boost-module
As long as the validator can successfully propose a block obtained from our relay, the validator is not subject to any slashing risk. We ensure all blocks obtained from our relay honoring all commitments sold from our exchange. If not, we as the platform will be slashed.
missing a slot with commitments attached to it
not proposing blocks obtained from our relay
Validators are able to provide collateral by either:
Depositing ETH directly to our collateral smart contract on L1 (0x818EF032D736B1a2ECC8556Fc1bC65aEBD8482c5). Note that this collateral will not accrue Consensus/Execution layer rewards during such time, or
Collateral AVS - our Eigenlayer AVS that enables natively staked ETH to be provided as security. See the Collateral AVS page for further information.
Proposers are recommended to post at least 1 ETH collateral per slot as collateral held against the non-delivery of commitments. There are two metrics used for collateral calculation purposes:
Trading Account Collateral
Collateral per Slot
The Trading Account Collateral is the total possible amount of ETH that can be used as collateral. The Collateral per Slot is the total possible amount of ETH that can be used as collateral, per slot.
For example, let's assume a Validator posts 10 ETH as Trading Account Collateral, and then determines the Collateral per Slot to be 1 ETH. This then exposes the Validator to a maximum loss of 1 ETH per slot for up to a maximum of 10 slots of blockspace. In the event the Validator has say 15 slots within the look-ahead, the Validator will only be allowed to sell up to 2/3rds of the blockspace (in any order) accordingly. Once that threshold has been reached, the Validator would need to top-up additional collateral.
The Collateral per Slot will be broadcasted to the Buyers enabling them to price their counterparty risk accordingly. Higher collateral amounts will generally confer greater blockspace prices/rewards to Validators.
While the 1 ETH number is arbitrary, we feel it provides an accessible/sufficient threshold to Buyers in the near-term, and yet is still accessible to most larger Validators for which will be the early adopters. As more information is gathered, both preconf buyers and the market in general will be able to better understand and price counterparty risk accordingly. As such, collateral requirements may change subject to market conditions and further research.
The slashing happens when the block is finalized, i.e. 2 epochs after the block is proposed, our backend will debit certain amount of collateral from validators and credit proportional amount of collateral to the affected preconf/whole block buyers internally in our database where the user balance can be queried from our API. Then, users can request withdrawal to get back the ETH collateral to their on-chain wallets.
The total slashed amount of a validator in a slot = collateral per slot set by the validator * total gas limit of the missing preconf bundles / block gas limit
The Proposer must decide to sell either the Whole Block, Inclusion Preconfs or mix of Inclusion and Execution Preconfs in the future. The assumption is that Proposers will not take an active or dynamic approach to selling block space products however - and they will prefer a default setting which will automatically seek to maximize validator fees.
Default 1: As the Whole block is worth strictly more than any mix of the Inclusion and Execution Preconfs - the risk-neutral fee maximisation option is to sell the Whole Block provided there is sufficient information to price the block accordingly. The ‘sufficient information’ is currently defined as [ x ] liquidity in the previous [ 2 ] slots and at least two bids.
Learn more about the Flow in the Architecture section
The Collateral AVS will enable native ETH stakers and validators to restake their ETH and provide security to their blockspace commitments. More details to come in second half of 2025.
Loading...
To simplify the integration process for builders to support and fulfill the proposer’s commitments, we will provide a modified version of rbuilder, a blazingly fast MEV-Boost Rust-based block builder developed by Flashbots. Our changes will achieve 3 goals:
Stream the latest preconf transactions from the ETHGas exchange
Build a block that includes all preconf transactions of a specific slot
Ensure the correct positions of the top and bottom bundles submitted by the whole block buyers
Fill up the block with transactions from the mempool if the gas used is below the block gas limit and the block buyers haven't set the remaining blockspace as empty
Please refer to links below for modified rbuilder
Traders that are Whole Block owners may choose to Build/Sequence the block themselves, or delegate this to someone else: Specialist Builders, or the Fallback Builder. They may also elect for the Block to include no trades.
Traders who own the whole block are entitled to sequencing rights, conditional upon including the previously confirmed constraints/commitments. Before the start of the slot (T < 0 sec), traders build the block including their trades, and sequencing all the trades accordingly. They then send the block via our Relay upon which it then follows the standard PBS flow.
Unlike Self Building above, where the Block Owner is also the Builder, traders may elect to delegate the building to a 3rd party. This 3rd party may be either a Specialist Builder, or the Fallback Builder.
Prior to both delegation , traders must submit their transactions via API (subject to the amount of blockspace they own) so that the Builders know which trades to include accordingly.
Traders may delegate Building to a 3rd party Specialist or Dedicated Builder. Specialist Builders may or may not pass on priority fees or any other economics back to the Trader. This is at the Specialist Builder's discretion. Traders should negotiate with the 3rd party Builders about the fee distribution via other channels. [ More details shortly ]
ETHGas will perform the role as a Fallback Builder and sequence the block accordingly when:
The Block has not been Self Built, or
The Block has not been delegated to a 3rd party Specialist Builder, or
The Block built by the Builder does not conform to the commitment requirements,
Any priority fees from trades included in the block will pass back to the Block owner. More on the fallback sequencing algorithm in due course.
The Fallback Builder flow assumes that Traders will always want a block to be built with any residual value (i.e. remaining Tips/Priority fees from mempool transactions) being passed back to the Trader. There may be cases, albeit rare, where the Trader has sold no commitments and elects for no trades to be included. In these cases, traders must send an API request to this effect so that an empty block will be submitted to the relay and then proposed by the validators. There is a caveat that a completely empty block cannot be proposed by the validators so a 0-value self transfer transaction will be included in an empty block.
Relays serves as a trusted intermediary between validators and builders. In the standard PBS flow, builders constantly submit blocks to the Relay. Validators then retrieve the most profitable block header without the body from the Relay and then submit the signed header back to Relay in return for the release of the block body containing the transactions.
ETHGas' preconf flow is quite similar to the PBS flow, with the addition that the Relay will perform an extra set of checks on blocks submitted by the builders to ensure all preconf transactions of the specific slot are included. Validators have to connect to our relay or other authorized Relays to receive the block headers, otherwise Validators may end up signing a header without honoring all preconf commitments thus resulting in slashing.
Our relay will be based on the mev-boost-relay developed by Flashbots.
As a superset of Commitment Buyers, traders may submit their private orderflow via both API and RPC. Such orderflow will only be emitted at expiration of a Slot and only to the appropriate Builder/Sequencer at such point in time:
RPC: [ details coming shortly ]