​
Understanding Credible and General Commitments

In the mev-commit network, commitments are essential to the bidding process. You may receive two types of commitments: credible and general. If the slot proposer is opted-in to mev-commit, provider commitments become credible. Understanding the difference between these two types of commitments will help you, as a bidder, optimize your interactions with the network and maximize your utility. Credible Commitments - Credible commitments are guarantees made by network participants who have direct control over fulfilling your bid. This could include block builders, proposers, or sequencers. These commitments offer the highest level of assurance that your bid will be delivered as promised, as they mean the proposer has opted in to mev-commit. Querying for Proposers is available by default and will notify you when your commitments are ultimately credible. General Commitments - General commitments are also promises made by network participants, but they offer a lower level of assurance compared to credible commitments. However, general commitments can approach the reliability of credible commitments when aggregated across multiple providers, such as all block builders for a mev-boost-enabled validator. This simply means that the proposer hasn’t opted in to mev-commit, but a committing block builder may still win the mev-boost auction and deliver its commitment for your bid. You can obtain the list of all registered providers as described here.

​
Submit Bundles

To include bundles of transactions, submit them in the exact atomic sequence they appear in the bundle. Bundles can be submitted as either:
  • An array of transaction hashes.
  • An array of transaction payloads.
Submitting raw transaction payloads is more efficient for providers, as it eliminates the extra step of looking up the payload based on a transaction hash when matching transactions with preconfirmation bids. This allows providers to be able to send preconfirmation commitments back to the bidder faster as well. You can learn more about bid structure here.

​
Transaction Payload

Include the raw transaction payloads in your bid in the atomic sequence in which they need to be placed in the block.
❯_ example
curl -X POST http://localhost:13523/v1/bidder/bid \
-d '{
    "rawTransactions": ["0x02f8db82426882010c8410433624841043362f8303425094ea593b730d745fb5fe01b6d20e6603915252c6bf87016e03ce313800b864ce0b63ce0000000000000000000000000e94804eaa3c4c5355992086647f683f6f41ef1f000000000000000000000000000000000000000000000000000150e0786cc000000000000000000000000000000000000000000000000000000000000004e378c001a0ece6d13b20247abdc07d669c9186ee5a1ac9601db8c98a3323024ab299cb6662a01c20680efe4e0bb48a3a936b5ab27c741819f0ac567b12b34b230004b20b78a0", "0x02f8748242682c841043362684104336318252089412b141665da4a5f617c759ad996ef91ad806a9c0880de0b6b3a764000080c001a0806552ed846808580eb896994825f07e73de2f42e2d3554f228284ecfaa89d9ca046d58b62ba565982fb07a64b436dd7a6c210b2f59c4fb2aee2cdd150ccf8bfaa"],
    "amount": "<amount in wei>",
    "blockNumber": <integer l1blocknumber>,
    "decayStartTimestamp": <timestamp milliseconds>,
    "decayEndTimestamp": <timestamp milliseconds>,
    "revertingTxHashes": ["7ca16add2aa1b1ef718006b791cb48a6ad729d22f5d2a0b294705320e4825abb"]
}'

​
Transaction Hash

Alternatively, you may refer to transactions that providers may already have through their RPCs or the public mempool by using transaction hashes. Note that not all providers may support this feature, and we encourage the use of the transaction payload option for optimal results.
❯_ example
curl -X POST http://localhost:13523/v1/bidder/bid \
-d '{
    "txHashes": ["0549fc7c57fffbdbfb2cf9d5e0de165fc68dadb5c27c42fdad0bdf506f4eacae", "22145ba31366d29a893ae3ffbc95c36c06e8819a289ac588594c9512d0a99810", "7e1506f266bc86c81ae46018053a274a3bd96a9eff17392930707bf8fa5ff6be"],
    "amount": "<amount in wei>",
    "blockNumber": <integer l1blocknumber>,
    "decayStartTimestamp": <timestamp milliseconds>,
    "decayEndTimestamp": <timestamp milliseconds>,
    "revertingTxHashes": ["22145ba31366d29a893ae3ffbc95c36c06e8819a289ac588594c9512d0a99810"]
}'
You can change the values in the fields txHashes, amount, blockNumber, decayStartTimestamp, decayEndTimestamp and revertingTxHashes as desired.

​
Bid amount

Note the bid amount should be set to the total amount the bidder is willing to pay for the bundle. Gas used by the transactions in the bundle does not affect the final amount paid.

​
Bid Decay

The decayStartTimestamp and decayEndTimestamp are important components for how sensitive the price of a preconfirmation will be. More details can be found about it here.

​
Bid Options

The bidOptions can be used to set positional constraints on the transactions or bundles in the block. Learn more about the different options here.

​
Troubleshooting

Bidders will start receiving commitments instantly in most cases. If you’re having trouble receiving commitments, check your bid parameters and ensure your bid is high enough for the commitment you’re requesting. Additionally check that you are connected to providers (via the topology endpoint) and that you are receiving mev-commit events (via the health endpoint).

​
Bidder Depositing

Bidders must bridge ETH to the mev-commit chain, then deposit toward one or more providers. As bids are settled, the bidder must “top up” their deposits. To automate this process, the bidder can enable the deposit manager and set target deposits for each provider. A target deposit is the desired amount of funds that a bidder wants to be deposited for a specific provider. Once a target deposit is set, the relevant deposit will be automatically “topped up” to the target value during the settlement process. Bidders should set their target deposits to the maximum cumulative amount of ETH they would ever bid to a provider with respect to a single L1 block. Read more about the deposit manager here.