Skip to main content

MEV-Share

Introduction

MEV-Share enables users to reclaim up to 90% of the MEV generated by their transactions, the rest of which is paid to searchers and builders. 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.

Common configurations

Stable Configuration

The Stable configuration is the default configuration for Protect RPC. No query parameters are specified to use it.

https://rpc.flashbots.net

Currently, this configuration shares the following information:

  • The hash of all transactions
  • default_logs Partial 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.

Max Privacy

To use Protect with full privacy, set only the hash hint in your Protect RPC URL:

https://rpc.flashbots.net?hint=hash

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.

Max Kickback

To use Protect with the maximum kickback, set all hints in your Protect RPC URL:

https://rpc.flashbots.net?hint=calldata&hint=contract_address&hint=function_selector&hint=logs&hint=hash

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.

Examples

Here are some examples of configurations that you might choose, depending on your goals.

Goal
Flashbots Protect RPC URL
Stablehttps://rpc.flashbots.net
Max Privacyhttps://rpc.flashbots.net?hint=hash
Max Kickbackhttps://rpc.flashbots.net/?hint=calldata&hint=contract_address&hint=function_selector&hint=logs&hint=hash
Add Builders (share with other builders for faster inclusion)https://rpc.flashbots.net?builder=flashbots&builder=XYZ
Change Refund (send more to validator for faster inclusion)https://rpc.flashbots.net?refund=userAddr:10

Configuration Reference

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.

Hints

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.

HintDescription
calldataShare 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.
logsShare logs emitted by executing the transaction.
default_logsShare 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
function_selectorShare 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.
contract_addressShare the address of the recipient of the transaction; typically a smart contract.
hashShare 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.
tx_hashShare individual tx hashes in the bundle.

Here is an example:

https://rpc.flashbots.net?hint=calldata&hint=logs&hint=hash

This configuration shares the calldata, logs, and hash of your transaction with searchers. It does not share the contract address or function selector.

Builders

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.

NameRPC

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 builder parameter:

https://rpc.flashbots.net?builder=ABC&builder=XYZ

This configuration sends your transaction to the ABC block builder and the XYZ block builder, as well as the Flashbots block builder.

Refunds

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 userAddr:

https://rpc.flashbots.net?refund=userAddr:10

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.

Priority fee

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.