Skip to main content



MEV-Share allows users to reclaim a significant portion of the MEV generated by their transactions, while the remainder goes to searchers and builders to facilitate transaction inclusion. 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 customize 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.

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 as the configuration is tuned to maximize benefits.

Max Privacy

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.

Max 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 a better chance to identify more MEV opportunities and return MEV refunds.


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

Flashbots Protect RPC URL
Max Privacy
Max Kickback
Add Builders (share with other builders for faster inclusion)
Change Refund (send more to validator for faster inclusion)

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.


To customize your hint setup, use the hint parameter to control the visibility of your transaction data to searchers. The default Stable hint configuration will be used if no hints are provided. If you specify one or more hints, any hint that is not included will be disabled.

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:

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


Designate which builders will receive your transaction with the builder parameter. This parameter can be repeated multiple times to include different 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 builder parameter:

This configuration sends your transaction to ABC block builder, XYZ block builder, and 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 for bundled transactions. 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 address.

Here is an example of a refund parameter that sends 10% of the searcher's payment to the address userAddr:

The sum of all refund percentages must be less than 100. The remaining percentage, inferred from 100 - total refund percentages, is the payment to the validator.

Note: Keeping a larger percentage of the refund may result in longer block inclusion times as it reduces the payment to the validator.

Priority fee

When sending a private transaction to an RPC endpoint, the priority fee (tips) should be greater than zero. A transaction with a 0 priority fee will not be shared with block builders and will only be included on-chain if a searcher bundles them via MEV-Share.