Commitment Buyers

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.

Timing & Execution of Preconfs

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

Bundle Types

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. If multiple normal users submit conflicting mev bundles, we follow the first come, first served principle.

• 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

Bundle Ordering

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.

Target Users

• 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