Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
ETHGas is a marketplace to source and trade blockspace commitments, alongside the Base Fee itself. It operates as a hybrid exchange - a centralized venue, where the central limit orderbook (CLOB) matches buyers with sellers, alongside a non-custodial smart contract where the collateral is held to backstop validator commitments. ETHGas is a neutral party offering end-to-end privacy.
Blockspace commitments come in three forms
Whole Block where the buyer has the exclusive right to sequence and include any valid transactions up until ~36mm gas units. The buyer has the option to subdivide and sell a combination of Inclusion Preconfirmations or Execution Guarantees (coming soon). Whole block market open at most 64 slots in advance.
Inclusion Preconfirmations (or Inclusion Guarantees) where trades are guaranteed to be included in a block up to a specific maximum number of gas units. Validators ‘create’ Inclusion Preconf markets by providing an initial sale. From then on, secondary trading of such instruments may occur between various parties. Inclusion preconf market opens 32 slots in advance.
Execution Preconfirmations (or Execution Guarantees, coming soon!) where trades are additionally guaranteed to have a specific state or result attached to them. These markets are structured as a progressive auction. While we have looked at other auction mechanics (e.g. VCG and other forms of GSP) further research is warranted to optimize this for both parties accordingly.
Base Fee Markets: (coming shortly)
Block Construction: By the 2 second mark before the start of the slot (subject to Validator Timing Adjustment), each Buyer is required to have submitted their trades to be included alongside their Preconfirmations, at which point the Builder will request to get a list of Preconf transactions.
The Block Builder will then construct and optimize any remaining portions of the block accordingly including, amongst others, private transactions and public mempool trades accordingly. These Blocks will then propagate via the ETHGas Relay and onto the Proposer accordingly.
See more details in the Inclusion Preconf Flow in the Architecture section
ETHGas is proud to introduce real time blockspace commitments, enabling Ethereum to guarantee settlement as fast as 3ms, and as frequently as 100k per second (subject to blockspace limitations).
Blockspace Commitments is a broad term describing a suite of products that provide more customization around how and when users get their orders executed. Do you want your order guaranteed to be included in this slot? Do you want it to come with a specific result or state?
While these commitments give end-users more choice, it can also result in higher fees for the validators that provide such an array of options. As a validator, do you prefer to build vanilla blocks? Do you opt-in to MEV-Boost? Would you want to offer a broader product suite, and as a result, earn higher fees?
ETHGas is compatible with the existing PBS / block construction process making it easy to integrate with existing infrastructure and systems.
We envision a future where end-users can insulate themselves against gas price volatility, where they can get real time / instant settlements (vs waiting 12 secs) - basically getting what they want, when they want it. Over time, we'll enable Protocols, Wallets and their end-users to store gas, remove the concept of gas altogether, and much, much more.
Real time Gas Markets enable Ethereum and its based Rollups to hyperscale providing an experience that is as fast as it’s CeFi counterpart, but decentralized and privacy centric. LFG 🚀🚀🚀
Quick Start:
For Researchers:
For All Users:
For Traders: & Developer Docs on:
For Validators:
Gas represents the economic fabric that binds blockchains together. Validators supply blockspace (and compute) for transactions, and Buyers pay for this blockspace, to process transactions. While Gas may ‘fuel’ blockchains, or be seen simply as ‘transaction fees’, the onset of Gas Markets very much changes this definition.
At a macro level, gas prices move rapidly and are often seen as a barometer for industry volatility. The early motivation behind gas markets in this context is to remove the volatility/uncertainty, so that both the risk of transacting in DeFi is reduced, and more importantly, so that the end user experience can be streamlined. Gas Markets enable Chains, Protocols (via B2B sales), and Wallets to abstract gas prices away entirely removing gas vol from the end-user altogether
At a micro level, the concept of gas extends beyond just ‘blockspace’ into a market perhaps more analogous to Oil Refining or Real Estate. How much gas should Validators (called Proposers) sell? When do they sell? Which ‘parcels’ of gas to sell? Do they enter into revenue sharing agreements? Do they securitize their blockspace? And so forth…there are countless comparisons to Commodity Trading and various forms of offtake agreements.
In DeFi, most of the trades and Validator Execution-Layer Revenues are driven by Institutional/HFT players. These traders need realtime precision and will pay handsomely for custom order execution - for example, guaranteeing inclusion into a specific block (called an Inclusion Preconf), guaranteeing a result or ‘state’ in a specific block (called an Execution Preconf), or the option to guarantee either of the above.
Custom order execution is not new - some of this is done already via private or OTC markets with Block Builders. Block Builders play an essential role in PBS but don’t ‘own’ the blockspace however, and so they are limited in their capacity to offer and support certain guarantees.
With Validators now able to structure markets as they choose and delegate this accordingly, gas markets will not only increase the choices that gas buyers have, it will dramatically increase the fees that Validators earn triggering a paradigm shift for both blockchains and onchain actors in general.
Note that the terms Validator and Proposer may be used interchangeably.
A Whole Block purchased in the primary market reserves the entire block, ~ 36mm gas units (remark: gas limit can be dynamically adjusted by validators), for the buyer. Buyers may decide to strip apart and sell a mix of Inclusion Preconfirmations or Execution Guarantees. At such point, the Whole Block instrument now comprises a mix of other commitments whereupon subsequent secondary market sales of the Whole Block will be defined to be contingent upon including those other commitments.
Sequencing Rights are also conferred to the Block Buyer making a whole block buyer a synthetic Block Builder as articulated in The Design Process. Should a block buyer looking to retain key positions/guarantees in a block be unable to Sequence a block accordingly, they may include their own Execution Guarantees or Inclusion Preconfirmations, and either:
Not sequence the Block, following which ETHGas will be the fallback Builder,
Sell the Block, or
Delegate the Sequencing to a specific Builder
Market Details:
Transaction Fees: [ 10% ] on Primary sale, [ 30 ]bps on secondary market trading TBC
Inclusion Preconfirmations (or Inclusion Preconfs) are commitments whereby the Proposer guarantees to include your transactions within a specific block N. Bids are for a fixed amount of blockspace (e.g. 200k gas units), may be included anywhere in the block, and do not carry any reversion guarantees.
Inclusion Preconf markets are created only when a Validator/Proposer has performed an initial, primary market sale of the Preconfs into the market. That is, it is not possible to ‘short’ an Inclusion Preconf.
Transaction Fees: [ 10% ] on Initial Sale, [ 30 ] bps on secondary market trading TBC
ETHGas has four distinct products: Inclusion Preconfirmations, Execution Preconfirmations, Whole Blocks, and Base Fee Trading.
Conventions:
Prices are denominated in GWEI
Settled in ETH
Referenced in USD
Minimum Size: 10k Gas Units
Minimum Increment: 1k Gas Units
Minimum Price: 0.01 Gwei
Minimum Tick Size: 0.01 Gwei
Order Types: Market Orders, Limit Orders, All-Or-None
The basis for our market construction and product design prioritizes maximizing Validator income taking into consideration (among others):
the feasibility / ability for what Validators could sell
the near-term roadmap for Ethereum L1
the customized orderflow that traders would desire
Making the gas markets accessible (and of interest) to as many players as possible
At a micro level, we look to introduce as few new concepts or terms as needed while also limiting any possibility of fragmentation. The result is as follows…
In a risk-neutral environment, it is optimal to sell an entire block, and where possible, to sell consecutive blocks whenever sufficient market information has been factored into the price.
Assuming perfect information, an entire block captures the most information and affords the buyer the most flexibility to insert and prioritize any combination of their own trades (alongside bundles including public mempool trades) into the block
As a prerequisite for a marketplace, it is essential that we standardize Gas Market Products as much as possible. While there may be many future variants and permutations, to the extent we can reduce these to as few types as possible, the easier it will be to establish a sufficient number of both buyers and sellers for a marketplace.
Secondary markets are important for any asset or instrument with value. When you have a secondary market, the economic cost turns from the purchase price (i.e. absolute cost) to the carrying cost (i.e. relative cost). That is, if you buy an instrument at T=0, and sell at T = 1 sec, then the carrying cost is only the difference in price between those two periods (alongside the time-value of money to be pedantic).
A Secondary market further enables price discovery answering the question of “what is the right price” for an instrument - the right answer of course being the ‘market price’ having digested (theoretically) all the available information to arrive at that specific level. Without price discovery, both the buyer and seller risk not maximizing their utility which invariably hurts both sides leading to deadweight loss.
For these reasons, product standardization and a secondary market are important, if not critical for gas market products to be priced properly, and for the market as a whole to reach its full potential.
A block is worth more than the sum of its parts.
While entire blocks may have secondary markets, there are times of imperfect information (and/or imperfect execution, or irrational exuberance) whereby it would be optimal to deconstruct or decompose a block into its constituent parts. This is where product standardization comes into play again.
In these scenarios, external parties value parts of the blockspace (for unknown reasons, e.g. private order flow) moreso than the holder of the current block. This then enables the original buyer the ability to strip down and sell off portions of the block thus decreasing their carrying cost or increasing the inherent value of the block accordingly.
There are three possible scenarios from holding the whole block:
Note that the following scenarios are not too dissimilar to what an integrated Block Builder faces today - they are easily able to buy the whole block when it makes sense, albeit with some uncertainty. This uncertainty ultimately results in a less-than-optimal value capture for the Proposer.
Scenario 1: The Buyer composes the block however they like, potentially capturing value greater than the original purchase price.
Scenario 2: The Buyer is unable to capture most of the value themselves. They meanwhile see strong demand for blockspace beyond their current capacity/knowledge and so they strip the block into it's constituent parts and sell them off accordingly.
Scenario 3: The Buyer is very much unable to capture any of the value. While at a slight loss, they are still able however to salvage some value by decomposing it into an array of different blockspace products accordingly.
By standardizing or commoditizing products, creating secondary markets, and allowing for decomposition, we enable market participants outside of the typical PBS players to enter these markets, for example, Market Makers.
Market Makers do not necessarily need to know how the PBS flow works, they only need to know that there are Four Products: Whole Blocks, Inclusion Guarantees, Execution Guarantees, and the public mempool, that they can simply rearrange and optimize for on an ongoing basis.
This is quite similar in principle to Options market making. In a perfect world, one can trade Options (i.e. the singular instrument), or one can trade the Greeks (e.g. Vol, Delta, Theta, Gamma, etc...) for which Options can be decomposed into.
As such, our Product Roadmap is designed to start with larger gas-market products (with greater potential value) and then strip these down only when necessary.
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.
ETHGas is an out-of-protocol initiative that broadly intermediates Validators (called Proposers) alongside their Gas Market Products with Buyers of blockspace (Builders, Traders, Searchers, Wallets, End-Users, and more) looking for custom order flow types.
Coming est. 2nd half of 2025
Execution Preconfirmations (or Execution Preconfs) are Inclusion Preconfs but with a guarantee by the Proposer of a specific state or result. Bids are for specific Trades or Bundles, requiring both a certain amount of Blockspace.
Execution Preconfs are only for the current slot. More details coming shortly.
Est. Dec 2024
Base Fee futures are Calendar Futures for a specific slot that enable trader to go Long or Short the Base Fee accordingly
Settlement: Cash
Initial Margin: [ 100% ]
Maintenance Margin: [ 50% ]
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.
ETHGas Exchange also posts collateral as a liveness bond to insure against our platform going offline
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.
Learn more about the Flow in the Architecture section
Buyers, that is, Traders, Searchers, Wallets, Protocols, and other End-Users of blockspace products directly submit Bids via API to the ETHGas exchange. See our API Docs.
Validators (called Proposers) are recommened to post 1 ETH of collateral for an entire block, though they can post whatever amount they prefer. In the event the Proposers do not include certain commitments in their block, this triggers a ‘default’ upon which their collateral will be slashed accordingly. The proceeds from slashing will then be distributed to Commitment buyers proportionate to the size of the commitment. More details can be found in Collateral & Slashing.
To further help Buyers assess counterparty risk, we have assigned a Counterparty risk metric denoted CTPY which is a function of the Percent of all the previous commitments honored. [ More, soon ]
While Whole Blocks and potentially Execution Guarantees & Consecutive Blocks (in the future) inherently carry more counterparty risk than Inclusion Guarantees per unit of gas, we feel it is not warranted to institute a dynamic collateral or margining mechanic for fear of overcomplication. We may explore this in the future to the extent it is relevant.
Buyers could purchase whole blocks up to 64 slots in advance but they can only buy preconf commitments up to 32 slots in advance.
Commitment Buyers submit a signed transaction object via API to the ETHGas Exchange. Following this, Builders may constantly fetch the list of preconf transactions from ETHGas, build the blocks and submit them through the relay accordingly. The timeline is as follows:
Whole Block and Preconf Markets close at T = - 4 secs where T = 0 sec is the start of the slot
Trades/Bundles to be submitted to the Exchange by T = - 2 secs
Block Owners / Builders must submit the block to our relay before T = 0 sec
There are 3 types of bundle, i.e. single transaction bundle, basic bundle and mev bundle.
The first one is the bundle containing only one transaction. The second one is the bundle with multiple transactions and all their sender addresses are the same. The third one is the bundle with multiple transactions and at least 2 of their sender addresses are different.
The single transaction bundle and the basic bundle are at the same priority which means the block owner cannot kick away those bundle after those bundles are accepted by exchange. Normal users are welcomed to submit single transaction bundle and basic bundle but not mev bundle though they can still submit it without any guarantee because mev bundles can be kicked away by the block owner without any compensation or notification.
Users can also set whether the remaining purchased but unfilled blockspace can be filled by the block owner/builder or not. This is a per-slot setting and the default value is that the unfilled blockspace can be filled by the block owner.
For blob-carrying bundles, the block owner has the priority to fill up the blockspace up to the max blob limit. There is no guarantee to include the bundles with blobs submitted by the normal users
Only last block owner can submit bundle with top or bottom order specified. If a block owner sell the block, the ordering of their submitted bundles will not be respected.
Inclusion Preconfs: Latency-based order flow, Intents/Exchanges with offchain order matching,
Execution Preconfs: Searchers, CEX/DEX Stat Arb, HFT
Whole Block: Market Makers, Searchers, Stat Arb
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 API. Such orderflow will only be emitted at expiration of a Slot and only to the appropriate Builder/Sequencer at such point in time:
Our collateral contract (EthgasPool) has been audited by Sigma Prime and Node Security and our commit boost module has been audited by Sigma Prime.
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.
API docs: developers.ethgas.com
Commit Boost Module: https://github.com/ethgas-developer/ethgas-preconf-commit-boost-module
Modified rbuilder: https://github.com/ethgas-developer/preconf-builder
Exchange Specifications:
TPS: 100k TPS
Latency: 3-5ms latency, depending on colo or direct EC2
Location: AWS - Asia Pacific (Tokyo) / ap-northeast-1
Collateral Contract (EthgasPool): 0x818EF032D736B1a2ECC8556Fc1bC65aEBD8482c5