MEV-Share allows users to gain up to 90% of the MEV that their transactions create. By default, Protect users' transactions are sent to Flashbots MEV-Share Node, which returns them up to 90% of the MEV that their transactions create. By default, Protect users will be connected with the Stable configuration, which is continuously tuned by Flashbots to optimize execution while protecting users from harmful MEV. This document guides users on the nuances and configurations of MEV-Share.
MEV-Share enables users to reclaim up to 90% of the MEV generated by their transactions. By default, transactions from Protect users are directed to the Flashbots MEV-Share Node, which facilitates this return. Users are automatically connected to the Stable configuration, a setting continuously optimized by Flashbots to balance efficient execution and protection against harmful MEV. This document provides a guide on the mechanism and various configurations of MEV-Share.
Advanced users can exert more control over their transactions and preferences through the advanced panel or by manually configuring their Protect RPC request.
Flashbots Protect RPC
Send to more builders and give validators a larger tip.
The Stable configuration is the default configuration for Protect RPC. No query parameters are specified to use it.
Currently, this configuration shares the following information:
hashof all transactions
default_logsPartial logs (the pool id and the fact that a swap was made) for curve, balancer, and uniswapV2/V3-style trades
- Transactions are only forwarded to the Flashbots block builder
This may change over time as we gather more data and fine-tune the configuration to maximize benefits.
To use Protect with full privacy, set only the
hash hint in your Protect RPC URL:
This configuration ensures that all identifiable transaction data sent to the MEV-Share Node is concealed from searchers. However, it's important to note that this could make it more challenging for searchers to spot MEV opportunities, leading to a very likely decrease in your MEV kickback.
To use Protect with the maximum kickback, set all hints in your Protect RPC URL:
This configuration provides searchers with comprehensive details about your transaction, giving them better chance to identify more MEV opportunities and to return more MEV kickback to you.
Here are some examples of configurations that you might choose, depending on your goals.
|Flashbots Protect RPC URL|
|Add Builders (share with other builders for faster inclusion)|
|Change Refund (send more to validator for faster inclusion)|
The Protect RPC uses query parameters within the URL to convey your preferences. These parameters can include hints about your transaction, the builders to whom your transaction is directed, and the distribution of potential refunds if your transaction is bundled.
To customize your hint setup, use the hint parameter to control the visibility of your transaction data to searchers. If no hints are provided, the default Stable hint configuration will be used. If you specify one or more hints, any hint that is not included will be disabled.
|Share data sent to the smart contract (if applicable) by the transaction. The function selector and contract address will also be shared if the calldata is shared.|
|Share logs emitted by executing the transaction.|
|Share specific subset of logs related to defi swaps. Partial info (the pool id and the fact that a swap was made) for curve, balancer, and uniswapV2/V3-style trades|
|Share the 4-byte identifier of the function being called on the smart contract by the transaction. The contract address will also be shared if the function selector is shared.|
|Share the address of the recipient of the transaction; typically a smart contract.|
|Share the transaction hash (or bundle hash if sending a bundle). To use full privacy mode, share this hint and this hint alone. The hash will always be shared if other hints are shared.|
|Share individual tx hashes in the bundle.|
Here is an example:
This configuration shares the calldata, logs, and hash of your transaction with searchers. It does not share the contract address or function selector.
To designate the builders who will receive your transactions, use the
builder parameter. This parameter can be repeated multiple times to include multiple builders. The builders listed below are currently supported.
Note that all transactions are shared with the Flashbots block builder, even if it is not explicitly specified.
It's important to understand that while adding more builders can increase your transaction inclusion rate, it also requires you to place trust in those builders. Here's an example of how to utilize the
This configuration sends your transaction to the ABC block builder and the XYZ block builder, as well as the Flashbots block builder.
You can tailor your refund settings using the refund parameter. This determines the distribution of the searcher's payment among different addresses if your transaction is bundled. If not specified, the transaction originator (tx.origin) will by default receive 90% of the searcher's payment.
The refund parameter contains two colon-separated values: an address for the refund and the percentage of the searcher's payment to be refunded. To distribute the payment across multiple addresses, append a new refund parameter for each.
Here is an example of a refund parameter that sends 10% of the searcher's payment to the address
All percentages in the refund parameters must total less than 100. The remaining percentage, inferred from 100 - total refund percentages, is the payment to the validator. Note that keeping a larger percentage of the refund may result in longer inclusion times, because it reduces the payment to the validator.
When sending private transaction to rpc endpoint you should set priority fee (tips) to be strictly greater than zero. Transactions with 0 priority fee will not be shared with block builders and included on chain, unless they are bundled by a searcher via MEV-Share.