Skip to main content

Wallet/Dapp Integration Guide

This guide covers the essential steps for wallet & dapp developers to send transactions to MEV-Share.

What's MEV-Share?

MEV-share is a protocol that lets users, wallets, and dapps to capture the MEV their transactions create.

You can submit your orderflow to the Flashbots MEV-Share Node to internalize the MEV generated by your transactions.

What's a MEV-Share Node?

A MEV-Share Node is a service that matches user transactions with searcher bundles. Flashbots runs MEV-Share Nodes on Ethereum Mainnet and Goerli. Users submit their transactions to the Node, which shares select information about transactions with searchers. Searchers propose transactions for the Node to bundle with the user transactions (currently we only support backruns). The Node forwards these bundles to a block builder with a requirement that the user is paid a refund; a percentage of the winning searcher's bundle profit.

How to Integrate

The Flashbots MEV-Share Node is accessible through the Flashbots Protect RPC.

Send Orderflow to Protect RPC

Route your application's eth_sendRawTransaction calls to the Protect RPC rpc.flashbots.net to connect to the MEV-Share Node. By default, connecting to Protect will enable the MEV-Share Node with the Stable configuration, which is set by Flashbots to give users the best possible execution.

Set Privacy Configuration

To specify a custom privacy configuration, options are passed as URL query params. These params currently include hints and builders.

Hints specify which data fields in the user's transactions are shared with searchers on MEV-Share. The following hints are currently available:

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.
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.

Specifying builders permits the specified builders to use your orderflow to build blocks.

caution

Adding other builders can make users' transactions land on-chain faster and more reliably, but note that Flashbots does not control how other builders operate and makes no guarantees about their behavior.

The following builders are currently supported. By default, orderflow is only routed to the Flashbots block builder.

NameRPC

Set Refund Configuration

By default, the Flashbots MEV-Share Node will send 90% of the searcher's payment to tx.origin of the transaction that is backrun. To adjust the refund percentage and recipient(s), append an optional refund URL query param to your request.

The refund param contains two values separated by a colon :. The first value is the address that the refund should be transferred to. The second value is the percentage of the searcher's payment that should be refunded. To split the payment across multiple addresses, add a new refund param for each address with the amount that it should receive.

The sum of all percentages specified in refund params must be less than 100. The validator payment is inferred from 100 - sum of refund percentages. Note that keeping a larger percentage of the refund may result in longer inclusion times, because it reduces the payment to the validator.

Examples

Connecting to RPC with this configuration would share logs and function selectors, and send transactions only to Flashbots:

https://rpc.flashbots.net?hint=logs&hint=function_selector&builder=flashbots

Connecting to RPC with this configuration would send 40% of the searcher's payment to "userAddr", 10% to "walletAddr" and the remaining 50% to the validator:

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

We recommend experimenting to find the right settings for you and your users. We are happy to partner with your data and product teams to find the best balance.

To learn more about configuring Flashbots Protect, see the Flashbots Protect RPC docs.

What are the guarantees and benefits?

The MEV-Share Node will bundle user transactions with each valid searcher backrun and submit them to a dedicated Flashbots builder. The builder will choose the winning bundle and transfer 90% of the searcher's payment to tx.origin of the user's transaction.

If no valid backruns are submitted, the transaction will be treated as a regular Protect transaction and receive all the typical benefits of Flashbots Protect.

What are the risks?

This is a beta release of the Flashbots MEV-Share Node. The MEV-Share Node service may experience service interruptions and there may be API breaks during the trial phase.

By default, the MEV-Share Node shares no transaction information with searchers other than the transaction hash. This is unlikely to result in the largest possible refund. You can customize your request to share additional information and we will closely monitor and update the defaults where needed.

Next steps

We are exploring a number of improvements. For instance — customizable refund percentage & recipients (which would allow wallets or dapps to take a cut), more privacy settings & per-protocol defaults, and more expressive execution preferences (allowing searchers to submit bundles that contain more than simple backruns).

The Flashbots MEV-Share Node is one implementation of the MEV-share protocol. We are also actively designing standard interfaces for the protocol as a whole.

Help improve MEV-Share

Join us in discussing the latest APIs by creating an Issue or Pull Request on github/flashbots/mev-share.