For example, if the decay proportion is $1/2$ as in the example above, the bid's value decays by $50$%.
In general, when a provider issues a commitment at time $t$ for a bid with amount $\mathrm{bidAmt}$, the bidder pays the provider the value $v$ computed as
$$
v = \mathrm{bidAmt} \cdot \frac{\mathrm{decayEndTimestamp} - t}{\mathrm{decayEndTimestamp} - \mathrm{decayStartTimestamp}},
$$
constraint to $0 \leq v \leq \mathrm{bidAmt}$, i.e., the value $v$ paid is never more than $\mathrm{bidAmt}$.
## Analysis of the Mechanism
The security of the mechanism comes from the fact that the participating parties have conflicting incentives. In particular, we note that there is no incentive for the bidder to manipulate the choice of the bid’s timestamps; if the bidder includes a timestamp in the future, then the provider essentially gets less decay (i.e., the bidder pays more). If the bidder includes a timestamp that is too old, then the provider can choose to not commit as the decay is too high (then the bidder gets no commitment). Moreover, we note that this would have the exact same effect as the bidder changing the price of its bid prior to the submission of the bid. Similarly, the commitment timestamp set by the provider must not be too old, as otherwise, it won't be valid when included in the mev-commit chain.
In many network-based systems, including our decay mechanism, faster connections often provide better opportunities, such as quicker access to information or response times. This situation is similar to high-frequency trading in financial markets, where traders with faster connections can outperform others. In our system, any advantage due to a faster connection is bounded by the parameter $\Delta$.
## Properties of the Mechanism
Our decay mechanism design achieves the following properties:
**1. Predictability of Decay:** The providers can *accurately compute* how much their decay will be for a commitment.
**2. Public Verifiability of Decay**: The decay mechanism offers public verifiability, as the decay amount can be calculated using the public timestamps from the bid and the commitment.
**3. L1 Synchrony Independent:** Our decay mechanism maintains independence from the L1 actual slot time, ensuring that the decay mechanism functions correctly regardless of whether the L1 block confirmation occurs more quickly or experiences delays.
**4. Just in time (JIT) Awareness of Bid:** JIT awareness of a bid ensures that the decay mechanism operates independently of the bid's submission time within the network, meaning a bid can be sent at anytime during a slot and experience correct decay. This is achieved by specifying the onset of decay and its deadline directly within the bid's structure, thus guaranteeing the mechanism functions as designed, irrespective of the bid's dispatch time.
# Bid Structure
Source: https://docs.primev.xyz/v1.2.x/concepts/bids/bid-structure
The bid payload sent to the internal mev-commit API is as follows:
| Key | Description |
| --------------------- | ---------------------------------------------------------------- |
| `txHashes` | Array of transaction hashes as strings |
| `amount` | Bid amount in wei |
| `blockNumber` | L1 block number targeted for bid inclusion |
| `decayStartTimestamp` | Start timestamp for bid decay (in Unix milliseconds) |
| `decayEndTimestamp` | End timestamp for bid decay (in Unix milliseconds) |
| `revertingTxHashes` | Array of transaction hashes as strings that can revert |
| `rawTransactions` | Array of raw signed transaction payloads |
| `slashAmount` | Amount to be slashed from provider stake in case of a failed bid |
| `bidOptions` | One or more of the available options |
Only one out of the `txHashes` or `rawTransactions` need to be provided in the bid. If the `rawTransactions` is given, the `txHashes` are inferred from it.
```json Example bid theme={null}
{
"txHashes": ["0549fc7c57fffbdbfb2cf9d5e0de165fc68dadb5c27c42fdad0bdf506f4eacae", "0549fc7c57fffbdbfb2cf9d5e0de165fc68dadb5c27c42fdad0bdf506f4eacaf","0549fc7c57fffbdbfb2cf9d5e0de165fc68dadb5c27c42fdad0bdf506f4effff"],
"amount": "100040",
"blockNumber": 133459,
"decayStartTimestamp": 1716935571901,
"decayEndTimestamp": 1716935572901,
"revertingTxHashes": ["22145ba31366d29a893ae3ffbc95c36c06e8819a289ac588594c9512d0a99810"]
}
```
```json Example bid with raw transaction payloads theme={null}
{
"rawTransactions": ["0x02f8db82426882010c8410433624841043362f8303425094ea593b730d745fb5fe01b6d20e6603915252c6bf87016e03ce313800b864ce0b63ce0000000000000000000000000e94804eaa3c4c5355992086647f683f6f41ef1f000000000000000000000000000000000000000000000000000150e0786cc000000000000000000000000000000000000000000000000000000000000004e378c001a0ece6d13b20247abdc07d669c9186ee5a1ac9601db8c98a3323024ab299cb6662a01c20680efe4e0bb48a3a936b5ab27c741819f0ac567b12b34b230004b20b78a0", "0x02f8748242682c841043362684104336318252089412b141665da4a5f617c759ad996ef91ad806a9c0880de0b6b3a764000080c001a0806552ed846808580eb896994825f07e73de2f42e2d3554f228284ecfaa89d9ca046d58b62ba565982fb07a64b436dd7a6c210b2f59c4fb2aee2cdd150ccf8bfaa"],
"amount": "100040",
"blockNumber": 133459,
"decayStartTimestamp": 1716935571901,
"decayEndTimestamp": 1716935572901,
"revertingTxHashes": ["22145ba31366d29a893ae3ffbc95c36c06e8819a289ac588594c9512d0a99810"]
}
```
The final bid structure includes a hash and signature that is auto-constructed by your mev-commit bidder node and looks as follows.
```json theme={null}
{
"txHash":"0549fc7c57fffbdbfb2cf9d5e0de165fc68dadb5c27c42fdad0bdf506f4eacae,0549fc7c57fffbdbfb2cf9d5e0de165fc68dadb5c27c42fdad0bdf506f4eacaf,0549fc7c57fffbdbfb2cf9d5e0de165fc68dadb5c27c42fdad0bdf506f4effff",
"bidAmount":277610,
"revertingTxHashes":"22145ba31366d29a893ae3ffbc95c36c06e8819a289ac588594c9512d0a99810",
"blockNumber":2703,
"digest":"uU2p20f5KmehWqpuY1u+CbhcS8jNwdQAJQe2dh0Vnrk=",
"signature":"nY6jYsGPxj6LVlSVQJbZcxvmRrw8Ym5rqOL1x0W/xPlJGBaF/ZzzjkxiioY/MDiRGvlflSWeoT0fh3aIJiJxAhw=",
"decayStartTimestamp":1716935571901,
"decayEndTimestamp": 1716935572901,
"slashAmt":0,
"rawTransactions":["0x02f8db82426882010c8410433624841043362f8303425094ea593b730d745fb5fe01b6d20e6603915252c6bf87016e03ce313800b864ce0b63ce0000000000000000000000000e94804eaa3c4c5355992086647f683f6f41ef1f000000000000000000000000000000000000000000000000000150e0786cc000000000000000000000000000000000000000000000000000000000000004e378c001a0ece6d13b20247abdc07d669c9186ee5a1ac9601db8c98a3323024ab299cb6662a01c20680efe4e0bb48a3a936b5ab27c741819f0ac567b12b34b230004b20b78a0"],
"nikePublicKey": "04c631d017981efdc0c319b475de36389a10ede86fbbc9adcf573844a858ce8ddcddb41306eb9c34ec4ee9bc0234f7e30684bf389142437166d407e47974d5cbf7"
}
```
## Details on Bid Structure
| Property | Description |
| ------------------- | --------------------------------------------------------------------------------------------------------- |
| txnHash | Array of transaction hashes represented as strings |
| bidAmount | Amount to bid in wei |
| blockNumber | L1 target block to have bid included |
| decayStartTimestamp | Start timestamp for bid decay (in Unix milliseconds) |
| decayEndTimestamp | End timestamp for bid decay (in Unix milliseconds) |
| bidDigest | Hash of the bid |
| bidSignature | Signed bidВigest = sign(bidDigest, signingKey) |
| nikePublicKey | NIKE public key of the bidder, autogenerated for each bid |
| revertingTxHashes | Array of transaction hashes as strings that can revert |
| rawTransactions | Array of hexadecimal encoded raw signed transaction payloads |
| slashAmount | Amount to be slashed from provider stake (and directly transferred to the bidder) in case of a failed bid |
| bidOptions | Position constraints or other available options |
### Details on Decay Parameters
The `decayStartTimestamp` and `decayEndTimestamp` parameters allow bidders to control the range over which their bid decays.
Due to inherent network delays, preconfirmation times can range between 50 to 250 milliseconds even if providers commit immediately after seeing the bid. To account for this, you might want to set your `decayStartTimestamp` approximately 300 milliseconds in the future. However, setting this delay is not mandatory and should be adjusted based on your strategic preferences for bid timing and pricing.
For more detailed information about the decay mechanism, refer to the [Bid Decay Page](https://docs.primev.xyz/v1.2.x/concepts/bids/bid-decay-mechanism).
### Details on BidOptions
The `bidOptions` provides a way to put certain constraints on the transaction with respect to the block. Currently we have the position constraint option. This option allows users to configure the location of the transaction in the block. This could be an absolute index or percentile or gas percentile index of the block.
```proto theme={null}
message PositionConstraint {
option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_schema) = {
json_schema: {
title: "Position Constraint"
description: "Constraint on the position of the transaction in the block."
}
};
enum Anchor {
ANCHOR_UNSPECIFIED = 0;
ANCHOR_TOP = 1; // Position is at the top of the block
ANCHOR_BOTTOM = 2; // Position is at the bottom of the block
}
enum Basis {
BASIS_UNSPECIFIED = 0;
BASIS_PERCENTILE = 1; // Position is a percentile of the block size
BASIS_ABSOLUTE = 2; // Position is an absolute position in the block
BASIS_GAS_PERCENTILE = 3; // Position is a percentile of the gas used in the block
}
Anchor anchor = 1 [(grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {
description: "Anchor position of the transaction in the block."
}];
Basis basis = 2 [(grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {
description: "Basis for the position constraint."
}];
int32 value = 3 [(grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {
description: "Value of the position constraint. If anchor is TOP, this is the position from the top of the block. If anchor is BOTTOM, this is the position from the bottom of the block."
}];
};
```
For example,
```json theme={null}
{
anchor: ANCHOR_TOP,
basis: BASIS_PERCENTILE,
value: 10
}
```
would let the provider know that this transaction or bundle has to be in the top 10% of the block. If we get a commitment and the transaction is not in the top 10%, the provider will be slashed. Multiple constraints can be combined, in which case the transaction needs to satisfy all of them. In case of transaction bundles, a set of constraints is considered satisfied if each constraint is satisfied by at least one transaction in the bundle.
### Details on Encrypted Bid Structure
The bid structure is encrypted using an AES key, which the bidder P2P node generates at the start, and is then sent to the provider.
```json theme={null}
{
"ciphertext": "5750d8af6296296f1147f5e11f47f253f376dea3fd5c2760cd82bd82a7066a8fe1c84f48a4e738d1df7c0e64f930c6b0b642800156e453a501c8b993951fcb50fe0b9fce4a2046838f499317a6018eb59abd5e84dbe3b7e296d4e0e70ef3bb221af7afe341908dbd02e8c91b4eff935b2697208f51ccacf5fe744c199afca687d85850a2e12a75433510dccda9258612348c586e971cc521486806ea25ec94d5fa7038beda3f532970e7b06198deef96677af3a6889c84d657585a9eefd224961f87a3353ad4ede4a7368e2e5bc9571d320a8a3be0f1e08e769f9bb2da6fb76c81cd"
}
```
# Understanding Bidder Deposit Rules
Source: https://docs.primev.xyz/v1.2.x/concepts/bids/bidder-deposit
Bidders need to deposit funds to be able to place bids on the mev-commit network. As bids are posted privately, providers cannot determine how much bidders have bid to other providers for the relevant L1 block. To ensure that bidders can cover all their bids, we bind deposits to specific providers. Providers can thus ensure that bids from a given bidder do not exceed the amount deposited for them.
It is important to note that if a bidder deposits, for example, 1 ETH for every provider, they can still only post bids totaling 1 ETH for a given block. This is because only a single provider can post the block to L1, meaning bids made to other providers will not be executed.
Deposited funds can be withdrawn by the bidder at any time, after waiting the \~10 minute cooldown period.
## Deposit Manager
It's recommended that bidders leverage the *deposit manager* to deposit, and automate ongoing re-deposits to specific providers.
The deposit manager is an on-chain contract that a bidder account can enable by "setting their code" to the implementation using EIP-7702. After enabling the deposit manager, a bidder's deposits are automatically replenished from the bidder's EOA balance during the preconf settlement process, according to *target deposit* amounts configured by the bidder.
A target deposit is the desired amount of funds that a bidder wants to be deposited for a specific provider. Bidders should set this to the maximum cumulative amount of ETH they would ever bid to a provider with respect to a single L1 block.
# null
Source: https://docs.primev.xyz/v1.2.x/concepts/bids/reverting-txns
## Reverting Transactions
Transactions are by default execution commitments when put in the bid payload. The `revertingTxHashes` field is used to describe transactions that you would like to allow to not need to be executed.
When you include transaction hashes in the `revertingTxHashes` array, you are indicating that these transactions can be reverted if necessary. This can be useful in scenarios where certain transactions are optional or conditional, and their execution is not strictly required for the bid to be valid.
Here is an example of how to include reverting transactions in your bid payload:
```json Example bid theme={null}
{
"txHashes": ["0549fc7c57fffbdbfb2cf9d5e0de165fc68dadb5c27c42fdad0bdf506f4eacae", "0549fc7c57fffbdbfb2cf9d5e0de165fc68dadb5c27c42fdad0bdf506f4eacaf","0549fc7c57fffbdbfb2cf9d5e0de165fc68dadb5c27c42fdad0bdf506f4effff"],
"amount": "100040",
"blockNumber": 133459,
"decayStartTimestamp": 1716935571901,
"decayEndTimestamp": 1716935572901,
"revertingTxHashes": ["22145ba31366d29a893ae3ffbc95c36c06e8819a289ac588594c9512d0a99810"]
}
```
In the example above, the `revertingTxHashes` field is used to specify a list of transaction hashes that can be reverted if necessary. This field is an array of strings, where each string represents a transaction hash.
In this particular example, the `revertingTxHashes` array contains a single transaction hash: `"22145ba31366d29a893ae3ffbc95c36c06e8819a289ac588594c9512d0a99810"`. This means that the transaction with this hash can be reverted if needed, without invalidating the bid.
By including the `revertingTxHashes` field, bidders can provide flexibility in their bids, allowing certain transactions to be reverted if necessary, which can be useful in various scenarios where transaction execution is conditional or optional.
# null
Source: https://docs.primev.xyz/v1.2.x/concepts/commitments
Commitments represent promises made by providers in a cryptographically verifiable manner.
| Key | Description |
| --------------------------- | --------------------------------------------------------------------- |
| `commitmentDigest` | Represents the hash of the bid structure, including the bid signature |
| `commitmentSignature` | Represents an ECDSA signature of the `commitmentDigest` |
| `commitmentProviderAddress` | Represents the address of the provider |
| `sharedSecret` | Represents the shared secret between the bidder and provider |
```json Example commitment theme={null}
{
"result":{
"txHash":"91a89B633194c0D86C539A1A5B14DCCacfD47094",
"bidAmount":"2000",
"blockNumber":"890200",
"receivedBidDigest":"61634fad9081e1b23a00234a52a85386a91fc0fad3fb32d325891bdc4f8a52a9",
"receivedBidSignature":"be99f499be5483665d569bd52fa8c4c9ed5c3bed2f94fb9949259bf640d8bd365b1d9a4b9ccb3ace86ffdcd1fdadc605b0f49b3adaf1c6a9ffea25585234664f1c",
"decayStartTimestamp":"1716935571901",
"decayEndTimestamp":"1716935572901",
"nikePublicKey":"04c631d017981efdc0c319b475de36389a10ede86fbbc9adcf573844a858ce8ddcddb41306eb9c34ec4ee9bc0234f7e30684bf389142437166d407e47974d5cbf7",
"commitmentDigest":"08a98d4c9d45f8431b46d99a23e6e8f82601ccf0773499d4e47bcd857cad92a6",
"commitmentSignature":"cfc1e4e2ea9cc417027ed5846fa073c8e6031f70f91ffa9b92051b5b7738c0500d8fefb0fc189bce16004b3c0e1c4cfa41260968161adf8b55446ed5c40d1ac51b",
"commitmentProviderAddress":"0x1234567890123456789012345678901234567890",
"sharedSecret":"0x1234567890123456789012345678901234567890",
}
}
```
The commitment consists of the details associated with the bid along with signatures made by the provider.
The provider generates a digest from the commitment, signs it with their private key, stores the digest and signature as an encrypted commitment on the mev-commit chain, and sends the commitment back to the originating bidder via the P2P network.
```json theme={null}
{
"result":{
"commitment":"08a98d4c9d45f8431b46d99a23e6e8f82601ccf0773499d4e47bcd857cad92a6",
"signature":"cfc1e4e2ea9cc417027ed5846fa073c8e6031f70f91ffa9b92051b5b7738c0500d8fefb0fc189bce16004b3c0e1c4cfa41260968161adf8b55446ed5c40d1ac51b",
}
}
```
# Fast Protocol Economics & Mev Distribution Model
Source: https://docs.primev.xyz/v1.2.x/concepts/fast-protocol
This document explains how **FAST RPC**, **mev-commit**, and the **Fast Protocol** collectively capture, route, and redistribute mev. It aims to give engineers, integrators, and validators a clear understanding of the value flows, incentive design, and equilibrium properties of the system.
***
# Summary
Fast Protocol transforms mev into a transparent, shared, incentive-aligned mechanism:
* **Users** receive top-of-market mev refunds (≥90%, even >100%)
* **Validators** earn strictly more when opting in, and materially more than in other OFA systems
* **Builders** maintain sustainable margins while delivering transactions
* **The protocol** becomes more valuable as usage increases, creating a positive feedback loop
No competing OFA can sustainably provide higher user mev refunds than Fast Protocol. The design is mathematically constrained, incentive-compatible, and self-stabilizing under normal market conditions.
## Overview of Fast Protocol
FAST RPC adds an **order flow auction (OFA)** on top of **mev-commit**. When users send transactions through FAST RPC:
* The RPC auctions and simulates backruns
* Mev is realized through backrun bundles
* Builders commit via mev-commit
* A portion of the mev goes to validators, depending on opt-in status
* The rest flows into the **mev distribution contracts**, forming the basis of tokenized mev rewards
The system ensures:
* Users receive **≥90%** of the mev their transactions generate when feasible
* Opted-in validators earn **significantly more** mev than non-opted-in validators
* The protocol achieves a **unique equilibrium** where no competing OFA can sustainably pay users more
***
# MEV Flow & Core Definitions
## MEV Components
For each mev-commit bundle:
$$
M_{bundle} = M_{bid} + M_{priority} + M_{direct}
$$
Where:
* $M_{bid}$ — the builder's decayed commitment
* $M_{priority}$ — sum of transaction priority fees
* $M_{direct}$ — any explicit builder payment
We also define:
* $M_{rpc}$ — total mev generated by FAST RPC transactions
* $M_{block}$ — total mev in the block
* $\rho = \dfrac{M_{rpc}}{M_{block}}$ — share of block mev attributable to FAST RPC
* $\rho' = \dfrac{M_{bundle}}{M_{rpc}}$ — fraction of RPC mev appearing in bundles
***
## Fee Parameters
FAST Protocol uses two fees:
* **Mev fee on bundles:**
$$
\text{mev\_fee} = f_{mev} \cdot M_{bundle}
$$
* **Validator fee (opted-in only):**
$$
\text{val\_fee} = f_{val} \cdot M_{block}
$$
Typical values:
| Parameter | Value | Meaning |
| --------------- | ------ | --------------------------- |
| $f_{mev}$ | 0.05 | 5% mev fee on bundles |
| $f_{val}$ | 0.05 | 5% validator fee |
| $\mu_{builder}$ | \~0.10 | Builder’s margin on RPC mev |
***
# FAST RPC MEV Generation
## Per-Transaction MEV Estimation
For each transaction $tx$:
$$
m(tx) = \text{estimated backrun profit}
$$
Total mev driven by FAST RPC in a given slot:
$$
M_{rpc} = \sum_{tx} m(tx)
$$
***
# MEV Redistribution Model
Redistributed mev accumulates into a pool $T$ composed of:
* Builder mev fees ($f_{mev} M_{bundle}$)
* Validator fees ($f_{val} M_{block}$)
* Backrun-captured mev from non-opt-in slots
***
## User Distribution
Each user $u$ has a weight:
$$
w_u = \frac{M_{rpc}^{(u)}}{M_{rpc}}
$$
Their payout is:
$$
P_u = T \cdot \tau_{rpc} \cdot w_u
$$
Payout may be delivered in points or tokens depending on availability.
***
# User Refund Ratio (γ)
Define:
$$
\gamma = \frac{T \cdot \tau_{rpc}}{M_{rpc}}
$$
Interpretation:
* $\gamma = 0.9$ → 90% mev refund
* $\gamma > 1$ → users receive **more than 100%** of their generated mev
System objectives:
* Maintain $\gamma \ge 0.9$ under normal conditions
* Allow $\gamma > 1$ in mev-rich phases (treasury surplus)
***
# Adaptive Parameter Logic
The protocol continuously adjusts how much mev goes to users versus the protocol treasury based on how abundant mev is in a given period. Let:
$$
r = \frac{M_{rpc}}{T}
$$
The protocol adapts how value is split between users and treasury based on mev abundance, summarized by the parameter $r$.
***
## Case 1 — Scarce MEV
When mev relative to the redistribution pool is scarce (high $r$), the system caps what it can give back while preserving protocol sustainability.
We can express the scarce regime as:
$$
r > r_{\text{crit}}
$$
for some critical $r_{\text{crit}}$ corresponding numerically to:
* approximately $\dfrac{0.95}{0.9}$ in the original parameterization.
In this regime:
$$
\tau_{rpc} = \tau_{\text{max}}
$$
$$
\tau_{fast} = 1 - \tau_{\text{max}}
$$
with $\tau_{\text{max}}$ set so that users get as much as the system can afford (slightly under 90% refunds in the most constrained conditions).
***
## Case 2 — MEV Rich
When mev is abundant relative to the pool, i.e.
$$
r \le r_{\text{crit}},
$$
the protocol:
* Preserves at least a 90% user refund on average
* Allocates the surplus between users based on the share of mev they generate
* Keeps a minimum fraction of value for the protocol
We can express $\tau_{rpc}$ generically as:
$$
\tau_{rpc} = a \cdot r + b \cdot (1 - r)
$$
for suitable constants $a$ and $b$ chosen so that:
* Users always receive at least 90% of their generated mev on average
* The protocol receives at least 5% in total
Then:
$$
\tau_{fast} = 1 - \tau_{rpc}
$$
In practice, parameter choices are tuned so that:
* For typical orderflow conditions, $\gamma$ is around or above $0.9$
* In mev-rich conditions, $\gamma$ can exceed $1$, sharing surplus with users while still realizing value for protocol treasury
This ensures:
* Users always receive ≥90%
* Protocol always receives ≥5%
* Treasury surpluses enhance both sides proportionally
***
## Greater than 100% Refunds ("Casino Effect")
Because the total value returned to RPC users ($T$) can include both:
* **Immediate mev** generated in the current epoch
* **Historical value** previously accumulated in the treasury and redistributed in later epochs
it is possible for the effective refund rate ($\gamma$) to exceed 1.
### Interpretation
* $M_{\text{rpc}}$ — total mev generated by a user's transactions in the epoch
* $\tau_{\text{rpc}}$ — fraction of the distribution flow allocated to users
* $T$ — total ETH distributed from the treasury to all users in the epoch
When $\gamma > 1$, users receive **more than 100%** of the mev their transactions generated—an effect referred to as the **casino effect**.
This arises naturally when prior epochs accumulated surplus mev in the treasury, allowing later epochs to over-refund users.
***
# Validator Incentive Model
FAST Protocol is designed so that **opting in is rational and strictly profitable** for validators.
Opted-in validators gain:
* All backrun-captured mev from FAST RPC bundles
* Their share of traditional builder → validator mev
* Competitive advantage in attracting order flow
Non-opted-in validators receive only the small residual share left after RPC backruns and mev fees.
***
## Opt-in Profit Condition
Incremental profit from opting in:
$$
\Delta_{opt} = M_{rpc} \cdot (1 - \mu_{builder}) - f_{val} \cdot M_{block}
$$
Opt-in is profitable if:
$$
\rho > \frac{f_{val}}{1 - \mu_{builder}}
$$
With typical values ($f_{val} = 0.05$, $\mu_{builder} = 0.10$):
$$
\rho > 0.0555
$$
Meaning:
**If Fast Protocol generates more than \~5.6% of block mev, opting in and even paying a 5% fee is profitable.**
In practice, Fast Protocol exceeds this threshold comfortably.
***
## What Validators Earn
| Validator Type | Approx. RPC mev Capture | Reason |
| ---------------- | ----------------------- | ---------------------- |
| **Opted-In** | \~95% | Backrun mev + residual |
| **Not Opted-In** | \~5% | Similar to Mev Blocker |
Opted-in validators therefore enjoy **\~20× higher mev capture** on FAST RPC flows.
***
# Why FAST RPC Is the Best-Paying OFA
The equilibrium analysis shows:
* If FAST RPC offered **less** than 90% user refunds, users would defect to other options
* If an OFA tried offering **more**, its builders or validators would become unprofitable
* FAST RPC optimally balances incentives so validators, builders, the protocol, and users all remain profitable
Thus, no competing OFA can sustainably provide higher user mev refunds than Fast Protocol.
# Bridging Details
Source: https://docs.primev.xyz/v1.2.x/concepts/mev-commit-chain/bridging-details
# Understanding Bridging Mechanisms
The mev-commit chain utilizes a standard bridging mechanism to ensure a secure and efficient transfer of ETH between mainnet Ethereum and the mev-commit chain.
We envision mev-commit to eventually integrate with a multitude of interoperability protocols (think wormhole, layerzero, etc.). In the meantime Primev has implemented its own lock/mint bridging protocol as described below.
## Lock/Mint Peg
Native ETH on the mev-commit chain maintains a 1:1 peg with ETH on L1. The only way to mint ETH on the mev-commit chain is to lock an equivalent amount on L1. ETH can be burned on the mev-commit chain to release/receive an equivalent amount on L1.
## Security
There are inherent security assumptions in bridging ETH to the mev-commit chain. While these are similar to other bridge trust assumptions, we've listed them below:
* Liveness of the bridge relayer actor.
* POA signers that maintain mev-commit chain state.
* Correctness of Primev's [standard bridge protocol](https://github.com/primev/mev-commit-bridge/tree/main/standard/bridge-v1) and integration into the mev-commit chain.
Our standard bridge implementation has been audited by Cantina. More details can be found [here](https://blog.primev.xyz/Battle-Testing-mev-commit-Key-Findings-from-Our-Spearbit-Security-Review-1436865efd6f8025bd6ce3824349821d).
## **Importance of Origin Chain Security**
**Selective Bridging**: Only bridges originating from Ethereum L1 should be allowed to mint native ETH on the mev-commit chain. This is to prevent the impact of compromised states on other chains affecting the mev-commit chain.
## Bridge Contracts
See **Bridge Contracts** section of [contracts page](/v1.2.x/developers/contracts) to gain context on contracts necessary to enable bridging.
## Relayer
The main off-chain component of the bridge is the relayer. Primev currently operates the relayer, with open-sourced implementation [here](https://github.com/primev/mev-commit/tree/main/bridge/standard).
# Chain Details
Source: https://docs.primev.xyz/v1.2.x/concepts/mev-commit-chain/chain-details
The mev-commit chain is live on [mainnet](/v1.2.x/developers/mainnet). To test and experiment, join the testnet and get familiar with its functionalities at the [testnet](/v1.2.x/developers/testnet) section.
## Design
Mev-commit chain is currently built out as an Ethereum sidechain run with [go-ethereum’s Clique proof-of-authority consensus mechanism](https://geth.ethereum.org/docs/tools/clef/clique-signing). It's not a generalized chain for everyone to launch dapps on, but only for specific execution service applications, such as preconfirmations, top of block, bottom of block, or other services.
Source code for the geth fork which runs the mev-commit chain can be found in the [mev-commit-geth repo](https://github.com/primev/mev-commit-geth).
## Progressive decentralization
Today, most or arguably all Ethereum scaling solutions rely on centralized bridging and sequencing. Mev-commit components rely on existing tech, and consequently inherit this property. However anyone can permissionlessly validate correct execution, and operation of chain infrastructure. Moreover, because the mev-commit p2p network is decentralized and commitments are cryptographic, actors can theoretically settle commitments without the mev-commit chain.
At this point of the network's inception, Primev entities will run all validating infrastructure for the mev-commit chain. Correct and honest operation can be permissionlessly audited by spinning up a full node and connecting to the mev-commit chain as a peer. Over time we plan to have entities outside of Primev to become POA signers or bridge validators to progressively decentralize the centralized components of the system.
The mev-commit chain will continue to evolve. We have ongoing research into consensus algorithms we can employ to decentralize the mev-commit chain without compromising on speed. Open source scaling solutions that prove to be practical, decentralized, and meet security thresholds will be considered to decentralize the mev-commit chain.
## POA geth nodes
Primev currently maintains a mev-commit-geth bootnode which doesn’t participate in consensus, and a set of full-node POA signers that run consensus. These signers take turns proposing the next block by utilizing a waiting period.
The current target block period is 200ms, meaning about 60 mev-commit chain blocks will be committed for every Ethereum mainnet block. The block time will likely change as enhancements are added and chain state grows.
## Fee Mechanism
**Non-inflationary**: The fee mechanism on the mev-commit chain is non-inflationary, maintaining a strict 1:1 peg between sidechain ether and L1 escrowed ether. This is achieved through a variation of EIP-1559, where both the base and priority fee accumulate to a treasury account (preconf.eth address).
## Smart Contracts
Smart Contracts are deployed on the mev-commit chain to enable use cases, follow bid and commitment states, and invoke rewards or slashing as needed. Anyone can deploy contracts on the mev-commit chain, however there'll be additional integration work needed with mev-commit off-chain components to fully enable the use case under the current design. Thus we first recommend getting in touch with the Primev team to enable a use case at this stage of the network.
Currently deployed contracts are designed as follows:
* A preconfirmation contract allows preconfirmation commitments to be stored and tracked on-chain.
* Two separate registry contracts exist to manage bidders and providers, both parties must stake ETH to participate. Rewards and/or slashing are managed by these contracts.
* An oracle contract receives L1 payloads from the oracle service. It currently operates by checking confirmed mainnet blocks.
* An block tracker contract which designed to track Ethereum blocks and their respective winners.
## Oracle service
The oracle service is an off-chain process that interacts with the oracle contract as needed. This service monitors and extracts the winning builder and corresponding transaction hash list from each L1 block, and submits this data to the oracle contract residing on the mev-commit chain.
This is a centralized oracle currently operated by Primev. We're actively looking into decentralizing the oracle role through existing decentralized Oracle protocols and evaluating creating a service where this can be decentralized.
# Differences Between Ethereum and mev-commit Chain
Source: https://docs.primev.xyz/v1.2.x/concepts/mev-commit-chain/differences-between-ethereum-and-mev-commit-chain
## Introduction
Mev-commit chain is an Ethereum-compatible blockchain designed to provide faster transaction processing and lower fees.
It aims to optimize the extraction of Maximal Extractable Value (mev) by utilizing a specialized architecture.
This document highlights the key differences between Ethereum and mev-commit chain.
## Overview
The following table provides an overview of the key features and differences between Ethereum and mev-commit chain:
| Feature | Ethereum | Mev-Commit Chain |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| Mempool | Larger mempool size | Smaller mempool size, transactions may be encrypted, limited chain mempool visibility due to fewer chain node operators |
| Validators | Decentralized proof of stake system with a large number of validators | Centralized setup with only two validator nodes creating blocks in a round-robin fashion, allowing for faster consensus and block production |
| Opcodes | Supports Ethereum opcodes | Supports all Ethereum opcodes, ensuring compatibility with existing Ethereum smart contracts and tools |
| Consensus | Uses proof of stake consensus, prioritizing decentralization | Uses clique proof of authority consensus, where authorized validators take turns creating blocks, prioritizing performance and fast block times |
| Block time | 12 seconds | 200 milliseconds |
| Transaction Fees | Supports both legacy and EIP-1559 transactions, with base fee being burned and priority fee going to the proposer/signer | Supports both legacy and EIP-1559 transactions, with base fee directed to the protocol treasury and priority fee going to the proposer/signer |
### Transaction Fees
Like Ethereum, mev-commit chain supports both legacy and EIP-1559 transactions, with a preference for EIP-1559.
The allocation of fees differs:
* The base fee is directed to the protocol treasury, instead of being burned.
* The priority fee goes to the proposer/signer, as in Ethereum.
### Mempool
Mev-commit chain's mempool is smaller compared to Ethereum's. While the mempool is public, transactions may be encrypted, and chain mempool visibility is limited due to the presence of only a few chain node operators. This reduces the potential for front-running and other mev-related activities.
### Number of Validators
Mev-commit chain currently operates with only two validator nodes that create blocks in a round-robin fashion. This centralized setup allows for faster consensus and block production. However, it also introduces a higher level of trust in the validators compared to Ethereum's decentralized proof of stake system.
### Opcodes
Mev-commit chain supports all Ethereum opcodes, as it consists of Ethereum nodes. Opcodes are low-level instructions that define the operations a blockchain can perform. By supporting all Ethereum opcodes, mev-commit chain ensures compatibility with existing Ethereum smart contracts and tools.
### Consensus
Mainnet Ethereum uses proof of stake, while mev-commit chain currently uses clique proof of authority consensus. In clique proof of authority, a set of authorized validators take turns creating blocks. This consensus mechanism prioritizes performance and fast block times over decentralization.
## Conclusion
Mev-commit chain offers a specialized blockchain environment optimized for mev extraction. With faster block times, a different fee structure, and a centralized validator setup, mev-commit chain provides an alternative to Ethereum for use cases that prioritize speed and mev optimization.
# null
Source: https://docs.primev.xyz/v1.2.x/concepts/mev-commit-intro/actors
Network actors’ roles are defined based on their interactions with other ecosystem actors. A diagram below depicts a given mev actor’s relative placement compared to others.
A list of potential Actors on the mev-commit network are listed below:
### **Providers:**
Providers of execution services include but are not limited to:
* **Block Builders**: They curate and order transactions in blocks, and have their own private mempool, giving them an advantage in committing to transaction inclusion or making related decisions.
* **Relays**: Relays are trusted actors that accept block bids from block builders and make them available to proposers, also relaying the block payload when requested. Due to their fundamental role in the mev pipeline, they can also act as guardians of proposer preferences for blocks and provide execution services.
* **Rollup Sequencers**: They're practically block builders for the L2 ecosystem, curating and ordering transactions for the L2 rollups.
* **Miners and Mining Pools**: In PoW systems such as Bitcoin, miners and mining pools can provide execution services as they mine the blocks that contain transactions.
#### Rules for Providers
To participate in the mev-commit network, providers must adhere to the following requirements:
* **Node Availability:** Providers must operate a mev-commit provider node continuously, ensuring high availability and reliability.
* **Consistent Commitment:** Providers must be willing to commit to profitable bids for all available slots.
* **Builder Activity:** The associated builder must have consistently produced at least 0.5% of recent mev-boost blocks to demonstrate meaningful network contribution.
Failure to comply with the above requirements may result in removal from the mev-commit network.
### **Bidders**
Bidders are users of execution services, bidding for inclusion of their transactions, for some specific preference to be adhered to by providers, and more. Bidders include but are not limited to:
* **Searchers**: Searchers of mev opportunities are in prime position to bid for execution services as they may have specific preferences or time constraints that maximize the profitability of their strategies.
* [**Solvers**](/v1.2.x/concepts/solvers): Solvers practically act similar to searchers, and will want to bid for execution services that optimize their order in specific ways depending on the protocols they adhere to.
* **Rollup Provers**: Provers and other rollup actors that create blobs and calldata to be posted to L1 will bid for execution services so their data can reliably make it on-chain.
* **AA Bundlers, Wallets, and other transaction aggregators** : These entities possess transactions from end users, and can bid for execution services with them or on their behalf so their platform provides the best user experience.
* **End Users**: While we don't anticipate most end users to send execution service bids directly beyond the gas price of their transactions, end users are considered bidders of execution services in general whether through gas price or other deal or engagement with where they send their transaction order flow to.
Generally, if you send transactions you'll be a bidder, and if you receive transactions you'll be a provider. If you are unsure whether you should be a bidder or provider, or both, reach out to our team and we will guide you according to your specific considerations.
# Understanding mev-commit
Source: https://docs.primev.xyz/v1.2.x/concepts/mev-commit-intro/network-overview
### Overview
Mev-commit is designed as an out of protocol layer to systems like mev-boost, facilitating the exchange of execution bids and commitments between mev actors, solving for coordination inefficiencies. This design ensures that only necessary parts of this faciliation happen on mev-commit (bids, commitments, settlement) and not the transaction flow itself. This design achieves chain abstraction by its nature, as any transaction hash on any chain can be referred to in a mev-commit bid, and be paid in eth. Bids and commitments on mev-commit also do not rely on blockchain bottlenecks and are real-time.
### Bids and Commitments
Bids are received and evaluated by providers, who run decisioning logic in their own environment and may decide to issue a cryptographic commitment against whatever the bid is for. In the preconfirmation case, the minimum a commitment can be made is for inclusion of the referred transaction hash(es) in the bid on the target L1 block number specified.
### Settling Commitments
Commitments are simultaneously sent to bidders and the mev-commit chain in hash format. This ensures the network can operate with end-to-end pre-execution privacy and low latency. Once the commitment is revealed by either of the participating parties at the end of a slot, an oracle will check the target L1 block number as it gets confirmed to see if the commitment is delivered. If so, the bid amount will be rewarded to the provider. If not, the provider stake will be slashed.
### Rewards and Slashing
*Only the actors who participated in the block's confirmation are considered for rewards or slashing.* This means if Block Builder A and Block Builder B commit to a bid and the target block is built by Block Builder A, the oracle will reward or slash Block Builder A.
### Network Architechture
The architecture of the mev-commit peer-to-peer (P2P) network is designed to support instantaneous communication among network participants. The diagram below depicts how mev-commit acts as a layer on bidder and provider operations, that are external to the mev-commit network by its nature:
### Network Connectivity
The network is structured to ensure robust connectivity among users and providers. Each participant node connects to a primary network node, known as a bootnode, during the initial startup phase, establishing a foundational network link.
### Gateway Nodes
The subsequent diagram provides a detailed representation of the bid, commitment, and fund flows within the mev-commit framework, showcasing the efficiency and effectiveness of interactions among mev actors.
# null
Source: https://docs.primev.xyz/v1.2.x/concepts/mev-commit-intro/oracle
**The primary role of the oracle is to ensure that the provider carries through on their commitments.**
The oracle consists of two parts:
* A smart contract component [here](https://github.com/primev/mev-commit/blob/main/contracts/contracts/core/Oracle.sol).
* A microservice [here](https://github.com/primev/mev-commit/tree/main/oracle).
The oracle automates the verification of provider commitments and queries the L1 data source for transaction hashes and block extra data. It then
cross-references these with commitments logged in the commitments contract, and then
verifies adherence using the oracle contract. If a commitment is satisfied, the oracle contract triggers a
reward to the provider using the bidder contract; if not, it slashes the provider by interacting
with the provider contract.
## Prior to Oracle Engagement
Before the oracle can be engaged according to the protocol's intended sequence of events, several preliminary actions must be taken:
**1a.** Simultaneously, the bidder issues an encrypted bid via the mev-commit peer-to-peer network.
*After the bidder's actions, the provider proceeds to:*
**2a.** Retrieve the encrypted bid from the mev-commit network.
**2b.** Issue an encrypted commitment for the transaction mentioned in the bid.
## Oracle Happy Path Flow
When a bid for a transaction (txnj) is circulated through the mev-commit p2p network, and the provider has made an encrypted commitment and then opened it after the L1 block was created, the oracle is activated to verify whether the provider has honored this commitment.
The process is as follows:
1. The provider assembles the complete L1 block, incorporating txnj, to which it previously committed. **Note: If the provider doesn’t get selected to construct the L1 block, the oracle flow does not get triggered.**
2. The oracle microservice fetches the block from the L1 chain and verifies the presence of txnj.
3. Upon confirmation that txnj is included, the microservice notifies the oracle smart contract of the commitment's fulfillment.
4. The oracle smart contract then initiates the transfer of funds from the bidder's deposited balance to the provider's account.
## Oracle Slashing Path
In the event that a provider fails to include a committed transaction (txnj) in the L1 block, the oracle slashing path is initiated to penalize the provider for the breach of commitment. This process is outlined below:
1. The provider is expected to produce an L1 block that includes the committed transaction (txnj). However, if the provider does not include txnj, the protocol moves to the slashing phase.
2. The oracle microservice retrieves the block from the L1 chain and searches for txnj. If the transaction is not found, it triggers the next step.
3. The oracle communicates that txnj was not seen in the oracle contract.
4. The oracle contract, upon receiving this information, initiates the slashing procedure. This involves penalizing the provider by triggering a slash event, which results in the forfeiture of the stake held by the provider contract as a guarantee of honest behavior.
5. The confiscated stake is subsequently allocated to the bidder as compensation for the provider's failure to include the committed transaction, thereby ensuring that the bidder is recompensed for the provider's breach of trust.
# What is mev-commit?
Source: https://docs.primev.xyz/v1.2.x/concepts/mev-commit-intro/what-is-mev-commit
Mev-commit is a peer-to-peer (P2P) networking platform designed to facilitate real-time interactions and coordination between mev actors and execution providers. It provides a robust network for exchanging execution bids and cryptographic commitments, which are used to specify execution requirements in detail and to receive credible commitments that act as promises to fulfill bid requirements. Mev-commit allows actors to engage in “fast games” such as preconfirmations through real-time cryptographic commitments and settles results using a high throughput blockchain for permissionless access.
## What are Bids?
Within mev-commit, bids act as the foundational requests placed by bidders, signaling their need for specific transaction execution services. This process occurs within a peer-to-peer networking setup to streamline direct negotiations with execution service providers like block builders and rollup sequencers. Each bid, marked by the unique identifier of a transaction hash, enables a straightforward mechanism for providers across the network to recognize and respond to these requests.
Bids essentially convey a user's readiness to pay a certain fee for the execution of their transaction, proposing a price designed to motivate execution providers to give priority to their transaction.
## What are Commitments?
Commitments within mev-commit represent the execution providers' affirmative responses to bids, confirming their agreement to execute the specified transactions at the proposed prices within designated blocks. These commitments are conveyed through cryptographic proofs or digital signatures, signifying the providers' acceptance of a bid.
Commitments serve as the critical link that aligns the supply and demand dynamics of the network, facilitating an effective and streamlined process for transaction execution.
## Actors
Network actors' roles are defined based on their interactions with other ecosystem actors. The diagram below depicts a given mev actor's relative placement compared to others:
Using ARUBE, mev-commit keeps all information and value related to bids private pre-execution while allowing them to be settled in a decentralized manner.
## Committing to Bids
A provider who receives a bid can make a commitment to it, which they also sign for authentication. The signed commitment binds the provider to the bid. Furthermore, the process is executed in such a way that only the bidder who issued the bid can identify a commitment as being related to their bid. This approach ensures a high level of privacy for the providers, as the commitments they issue are not linkable to a specific bid. In a normal run of the protocol the provider opens all its commitments at the end of the L1 slot, however if the provider refuses to open any of its commtiments, the bidder can independently open the commitment without needing assistance from the provider. This functionality is provided by the novel notion of dual-phase commitments.
### Dual-Phase Commitment (DPCOM)
DPCOM is a two-party commitment protocol that allows a message to be committed in two distinct phases. In the first phase, one party precommits to a message and receives both a precommitment and an opening key. In the second phase, the other party commits to the precommitment generated in the first phase, receiving a decommitment information as the output.
A key feature of a dual-phase commitment scheme is its flexibility in opening the resulting commitment using either the opening key or the decommitment information. This is especially useful in the context of the mev-commit protocol, where the bidder generates a precommitment to its bid, after which the provider commits to that precommitment. This process also ensures that both parties can open the commitment: the bidder obtains the opening key when generating the precommitment, and the provider obtains the decommitment information when committing to the precommitment. Consequently, both parties can later prove the content of the committed message to third parties. Crucially, if the provider misbehaves and refuses to publicly open the commitment, the bidder can independently open it without needing assistance from the provider.
The image below illustrates provider B committing to a bid posted by bidder 2, while the other parties remain unaware of the specific bid being committed to.
You can read more on ARUBE and DPCOM [here](https://mirror.xyz/preconf.eth/iz2J0uTXHhl8DiAkG-VLLwvCp-8qcc_Z7A8_4rU0A3g).
## ZK Proofs for Opening Commitments
A crucial property of the commitments issued by providers on mev-commit is that they can both be opened by providers as well as bidders. Being able for the bidders to open commitments is necessary when providers violate the commitment and thus have no incentive to open it. Therefore, when providers open a commitment, they have to prove in zero-knowledge that the commitment was generated correctly. This ZK proof is verified in a smart contract on the mev-commit chain when the provider sends the commitment-opening transaction. Thus, a provider can only open commitments that have been generated correctly and could also have been opened by the bidder.
### Implementation and Efficiency
The ZK proof used has been tailor-made for this particular use-case and optimized for efficiency. It is based on so-called sigma protocols and only requires a few elliptic curve operations and the computation of a hash. Generating a single ZK proof for the commitment opening takes only 0.122 milliseconds on a Mac M1 Pro. Furthermore, only around 32k gas is consumed in the smart contract to verify the proof. For comparison, the overall gas cost of the commitment opening transaction is around 488k gas. Hence, only less than 7% of the gas cost is attributed to the zero-knowledge proof verification.
More details on the used ZK proofs can be found [here](https://mirror.xyz/preconf.eth/AgtLSBob1hd2A924vlL7jCyJxQDZZE2tCq_K07w5vuU).
# Builder Attribution
Source: https://docs.primev.xyz/v1.2.x/concepts/rewards-and-slashing/builder-attribution
Understanding how builders are identified and attributed in mev-commit
# Builder Attribution
Builder attribution in the mev-commit system involves identifying the provider responsible for building an L1 block. This is crucial for ensuring that rewards and slashing mechanisms are correctly applied based on the commitments made by providers.
## How Builder Attribution Works
### Oracle and Builder Attribution
The oracle plays a central role in verifying whether commitments made by providers are fulfilled. It does this by:
* Querying the PBS relay to obtain block delivery data and associated BLS keys
* Cross-referencing block hashes from L1 with those delivered via the relay
* Identifying the builder through their registered BLS key when block hashes match
* Validating commitments against the identified builder in the mev-commit system
This system ensures accurate provider attribution for block building and appropriate distribution of rewards or penalties based on commitment fulfillment.
# mev-commit Points Program
Source: https://docs.primev.xyz/v1.2.x/concepts/rewards-and-slashing/points
The `mev-commit` Points Program rewards validators who opt-in and remain actively opted-in. Points accrue over **6-month Seasons**, with each Season offering base points plus growing multipliers. All points will be visible on the [Validator Dashboard](https://validators.mev-commit.xyz/) like the screenshot below. Read more to learn how points are awarded and how to maximize your total.
## Quick Overview
* **Immediate Reward:** Earn **1,000 points** per validator right when you opt in.
* **6-Month Seasons:** Completing an entire Season nets you up to **10,000 points** total in Season 1, and double for following seasons.
* **Multipliers:**
* Season 1: base schedule (see table below).
* Season 2 & 3: rewards are **2×** each month’s total.
* **Opt-Out Penalties:** If you opt out early during a season, you keep the **base points** for fully completed months but **lose** that month’s multiplier.
## Aggregated Points at Operator Level
Your dashboard displays **one aggregate total** across all your opted-in validators. Operators can see total points and watch them grow daily.
## Maximize Points via Partner Protocols
You can earn additional or parallel rewards when using partner protocols alongside `mev-commit`:
* **EigenLayer:** Operators opted-in to the `mev-commit AVS` on EigenLayer may earn `$eigen` token rewards (based on EigenLayer’s policies).
* **Symbiotic, Mellow, SSV:** Opt-in validators using these protocols to earn points from them AND mev-commit. Points will be available on the Symbiotic dashboard as well.
| Contract | Address |
|---|---|
| BidderRegistry | {BidderRegistryAddressMainnet1_2_0} |
| ProviderRegistry | {ProviderRegistryAddressMainnet1_2_0} |
| PreconfManager | {PreconfManagerAddressMainnet1_2_0} |
| Oracle | {OracleAddressMainnet1_2_0} |
| BlockTracker | {BlockTrackerAddressMainnet1_2_0} |
| Contract | Address |
|---|---|
| SettlementGateway | {SettlementGatewayMainnet1_2_0} |
| Entity | Address Type | Address |
|---|---|---|
| L1Gateway | Proxy | {L1GatewayMainnet1_2_0Proxy} |
| Implementation | {L1GatewayMainnet1_2_0Implementation} |
| Contract | Address Type | Address |
|---|---|---|
| MevCommitAVS | Proxy | {MevCommitAVSProxyAddress} |
| Implementation | {MevCommitAVSImplementationAddress} | |
| MevCommitMiddleware | Proxy | {MevCommitMiddlewareProxyAddress} |
| Implementation | {MevCommitMiddlewareImplementationAddress} | |
| VanillaRegistry | Proxy | {VanillaRegistryProxyAddress} |
| Implementation | {VanillaRegistryImplementationAddress} | |
| Reputational VanillaRegistry | Proxy | {VanillaReputationalProxyAddress} |
| Implementation | {VanillaReputationalImplementationAddress} | |
| ValidatorOptInRouter | Proxy | {ValidatorOptInRouterProxyAddress} |
| Implementation | {ValidatorOptInRouterImplementationAddress} | |
| ValidatorOptInHub | Proxy | {ValidatorOptInHubProxyAddress} |
| Implementation | {ValidatorOptInHubImplementationAddress} |
| Description | Address |
|---|---|
| Primev Team Multisig | {PrimevTeamMultisig} |
| Commitment Holdings Multisig | {CommitmentHoldingsMultisig} |
| Symbiotic "network address" (Served by Primev Team Multisig) | {PrimevTeamMultisig} |
| Contract | Address |
|---|---|
| BidderRegistry | {BidderRegistryAddress} |
| ProviderRegistry | {ProviderRegistryAddress} |
| PreconfManager | {PreconfManagerAddress} |
| Oracle | {OracleAddress} |
| BlockTracker | {BlockTrackerAddress} |
| Contract | Address |
|---|---|
| SettlementGateway | {SettlementGatewayAddress_1_1_6} |
| L1Gateway | {HoodiL1GatewayAddress} |
| Contract | Address |
|---|---|
| ValidatorOptInRouter | {HoodiValidatorOptInRouterAddress} |
| ValidatorOptInHub | {HoodiValidatorOptInHubAddress} |
| VanillaRegistry | {HoodiVanillaRegistryAddress} |
| MevCommitAVS | {HoodiMevCommitAVSAddress} |
| MevCommitMiddleware | {HoodiMevCommitMiddlewareAddress} |
| Lido Registry | {HoodiLidoRegistryAddress} |
| RocketMinipoolRegistry | {HoodiRocketMinipoolRegistryAddress} |
| Entity | Address |
|---|---|
| Mev-commit (Symbiotic) Network Address | {HoodiMevCommitNetworkAddress} |
| Mev-commit (Symbiotic) Vault Address | {HoodiMevCommitVaultAddress} |
| Mev-commit (Symbiotic) Subnetwork | {HoodiMiddlewareSubnetwork} |
1. Visit [mev-commit.xyz/bridge](https://www.mev-commit.xyz/bridge)
2. Connect your wallet when prompted
3. Select mev-commit as the source chain and Ethereum as the destination chain
4. Enter the amount of ETH you want to transfer
5. Click "Bridge" and approve the transaction in your wallet
6. Transaction should complete within a few minutes
Note: A fixed fee of 0.005 ETH is charged when bridging from mev-commit to L1 to cover relayer costs.
For advanced users, programmatic access, or automation needs, the bridge CLI tool is also available - see [Bridge CLI](/v1.2.x/get-started/bridge-cli) for details.
# Bridge CLI
Source: https://docs.primev.xyz/v1.2.x/get-started/bridge/bridge-cli
The mev-commit chain uses native ETH that must be bridged from L1 using our lock and mint bridge. A user CLI application can be downloaded from the [releases page](https://github.com/primev/mev-commit/releases/latest).
You can confirm your operating system and architecture by running `uname -sm`. Or use the following command which automatically downloads and extracts the latest bridge user CLI binary for your system into your \$HOME directory: ```shell theme={null} curl -Ls $(curl -s https://api.github.com/repos/primev/mev-commit/releases \ | grep browser_download_url \ | grep "mev-commit-bridge-user-cli_[0-9].*$(uname -s)_$(uname -m)\.tar\.gz" \ | cut -d '"' -f 4 \ | head -n1) | tar -xz -C ~ ``` The binary will then be available in your \$HOME directory as `user-cli`.To check other options available in the user CLI, users can use the `-h` option
``` ./user-cli -h NAME: mev-commit-bridge-user-cli - CLI for interacting with a custom bridge between L1 and the mev-commit (settlement) chain USAGE: mev-commit-bridge-user-cli [global options] command [command options] COMMANDS: bridge-to-settlement Submit a transaction to bridge ether to the settlement chain bridge-to-l1 Submit a transaction to bridge ether back to L1 help, h Shows a list of commands or help for one command GLOBAL OPTIONS: --help, -h show help ``` ``` ./user-cli bridge-to-settlement -h NAME: mev-commit-bridge-user-cli bridge-to-settlement - Submit a transaction to bridge ether to the settlement chain USAGE: mev-commit-bridge-user-cli bridge-to-settlement [command options] OPTIONS: --account-key value private key of the account to use for signing transactions in hex encoding [$ACCOUNT_KEY] --keystore-path value path to keystore location [$MEV_ORACLE_KEYSTORE_PATH] --keystore-password value use to access keystore [$MEV_ORACLE_KEYSTORE_PASSWORD] --amount value amount of ether to bridge in wei [$AMOUNT] --dest-addr value destination address on the mev-commit (settlement) chain [$DEST_ADDR] --l1-rpc-url value URL for L1 RPC [$L1_RPC_URL] --settlement-rpc-url value URL for settlement RPC [$SETTLEMENT_RPC_URL] --l1-contract-addr value address of the L1 gateway contract [$L1_CONTRACT_ADDR] --settlement-contract-addr value address of the settlement gateway contract [$SETTLEMENT_CONTRACT_ADDR] --silent disable spinner (default: false) [$SILENT] --help, -h show help ```[FAST RPC Usage Instructions for dApps](#usage-for-dapps)
[Usage Instructions for Wallets](#usage-for-wallets)
{/* Removed "FAST RPC" */}
If you instead want to configure your wallet manually, you can do that as follows:
The bid options are optionally used by bidders if they want additional constraints on the transaction. Currently, mev-commit supports positional constraints on the transactions w\.r.t the block. The decision logic should take these into consideration before returning.
```proto theme={null}
message PositionConstraint {
option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_schema) = {
json_schema: {
title: "Position Constraint"
description: "Constraint on the position of the transaction in the block."
}
};
enum Anchor {
ANCHOR_UNSPECIFIED = 0;
ANCHOR_TOP = 1; // Position is at the top of the block
ANCHOR_BOTTOM = 2; // Position is at the bottom of the block
}
enum Basis {
BASIS_UNSPECIFIED = 0;
BASIS_PERCENTILE = 1; // Position is a percentile of the block size
BASIS_ABSOLUTE = 2; // Position is an absolute position in the block
BASIS_GAS_PERCENTILE = 3; // Position is a percentile of the gas used in the block
}
Anchor anchor = 1 [(grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {
description: "Anchor position of the transaction in the block."
}];
Basis basis = 2 [(grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {
description: "Basis for the position constraint."
}];
int32 value = 3 [(grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {
description: "Value of the position constraint. If anchor is TOP, this is the position from the top of the block. If anchor is BOTTOM, this is the position from the bottom of the block."
}];
};
```
* If they have opted in, your relay only accepts blocks from mev-commit builders:
To implement this, your relay needs to track two things:
1. Provider Registry: Lists opted-in builders and their BLS keys
2. Validator Registry: Shows which validators have opted into mev-commit
## Quick Start
### Rewards
The primary reward that a validator earns in opting-in to mev-commit is increased yield, generated by providers being able to place higher bids in the mev-boost auction. See [Why Participate](/v1.2.x/get-started/validators/validator-guide#why-participate?) for more details.
All vault/operator pairs must agree on how validator yield will be split or otherwise distributed.
We plan to introduce a points system that will be applied to all opted-in validators. In the context of using Symbiotic, each vault will earn points commensurate to the number of validators opted-in through that vault.
### Network Overview
The Symbiotic "network" in this context is mev-commit. Our network is represented by:
* A "network address", aka the Primev team multisig at [0x9101eda106A443A0fA82375936D0D1680D5a64F5](https://etherscan.io/address/0x9101eda106A443A0fA82375936D0D1680D5a64F5)
* A "middleware contract" at [0x21fD239311B050bbeE7F32850d99ADc224761382](https://etherscan.io/address/0x21fD239311B050bbeE7F32850d99ADc224761382)
# Setup
The following setup steps will reference various Symbiotic core contracts. Refer to their [deployments page](https://docs.symbiotic.fi/category/deployments) and [core source code](https://github.com/symbioticfi/core).
{children}
;
export const CardContent = ({children}) =>
{children}
;
export const Separator = () => ;
export const CardDescription = ({children}) =>
{children}
;
export const QuickStartCard = ({children, title, icon}) => • [Quickstart Your Node](/v1.2.x/get-started/quickstart)
• [Send Transactions](/v1.2.x/get-started/bidders/best-practices#provider-rpcs)
• [Node Commands](/v1.2.x/get-started/bidders/bidder-node-commands)
• [Bid Structure](/v1.2.x/concepts/bids/bid-structure)
• [Bidder Deposit](/v1.2.x/concepts/bids/bidder-deposit)
• [Bid Decay](/v1.2.x/concepts/bids/bid-decay-mechanism)
• [Registering as a Provider](/v1.2.x/get-started/providers/registering-a-provider)
• [Consuming Bids](/v1.2.x/get-started/providers/consuming-bids)
• [Sending Commitments](/v1.2.x/get-started/providers/sending-commitments)
• [Commitments Structure](/v1.2.x/concepts/commitments)
• [Querying for Proposers](/v1.2.x/get-started/providers/Querying-for-proposers)
• [Opting-in as a Validator](/v1.2.x/get-started/validators)
• [Eigenlayer Operators](/v1.2.x/knowledge-base/eigenlayer-operator-registration)
• [Validator Rewards](/v1.2.x/concepts/rewards-and-slashing#validators-proposers)
• [Validator Considerations](/v1.2.x/concepts/validator-considerations)
**pFt \* M(t,T) + ασ(t,T) = Pbid**
| | |
| -- | ------------------- |
| P | price |
| pF | priority fee |
| t | current time |
| T | time at end of slot |
| σ | cost of state |
| α | 1 - bidder margin |
| M | multiplier |
Adjust your bid based on real-time commitments from providers. Start with conservative estimates and tweak as you learn the market.
The goal is to find the sweet spot where your bid is competitive enough for inclusion, but not higher than necessary.
# Introduction
Source: https://docs.primev.xyz/v1.2.x/knowledge-base/introduction
A collection of answers to frequently asked questions.
Instead of blindly sending your transaction, you can use an execution preconf. Here's how: