Mev Blocker
Last updated
Last updated
Maximal Extractable Value (MEV) has become a significant concern for users interacting with blockchain technologies, particularly those engaged in decentralized finance (DeFi) activities. MEV refers to the maximum value that can be extracted from blockchain transaction reordering by miners or validators. While it presents opportunities for profit, it also raises concerns about fairness and security within the blockchain ecosystem.
To address these concerns, MEV-Blocker emerges as a groundbreaking solution designed to protect users' transactions from being exploited for MEV. MEV-Blocker leverages advanced technologies to shield transactions, ensuring that users retain the majority of the MEV generated by their activities. This document serves as an introduction to MEV-Blocker, detailing its capabilities, configurations, and how users can harness it to safeguard their transactions while maximizing their returns in the blockchain space.
Mev-Blocker allows users to gain up to 90% of the MEV that their transactions create. By default, Protect users' transactions are sent to TornadoRPC Mev-Blocker 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 Mev-Blocker to optimize execution while protecting users from harmful MEV. This document guides users on the nuances and configurations of Mev-Blocker.
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 TornadoRPC Mev-Blocker Node, which facilitates this return. Users are automatically connected to the Stable configuration, a setting continuously optimized by TornadoRPC Mev-Blocker to balance efficient execution and protection against harmful MEV. This document provides a guide on the mechanism and various configurations of Mev-Blocker.
Advanced users can exert more control over their transactions and preferences through the advanced panel or by manually configuring their Protect RPC request.
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 TornadoRPC Mev 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.
Goal
TornadoRPC MEV Protect RPC URL
Stable
https://rpc.tornadoeth.cash/mev
Max Privacy
https://rpc.tornadoeth.cash/mev?trace=hash
Max Kickback
https://rpc.tornadoeth.cash/mev?trace=calldata&trace=contract_address&trace=function_selector&trace=logs&trace=hash
Add Builders (share with other builders for faster inclusion)
https://rpc.tornadoeth.cash/mev?builder=tornadoRPC&builder=XYZ
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 trace setup, use the hint parameter to control the visibility of your transaction data to searchers. If no traces are provided, the default stable trace configuration will be used. If you specify one or more trace, any hint that is not included will be disabled.
calldata
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.
logs
Share logs emitted by executing the transaction.
default_logs
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
function_selector
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.
contract_address
Share the address of the recipient of the transaction; typically a smart contract.
hash
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.
tx_hash
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 customize your trace setup, use the hint parameter to control the visibility of your transaction data to searchers. If no traces are provided, the default stable trace configuration will be used. If you specify one or more trace, any hint that is not included will be disabled.
calldata
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.
logs
Share logs emitted by executing the transaction.
default_logs
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
function_selector
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.
contract_address
Share the address of the recipient of the transaction; typically a smart contract.
hash
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.
tx_hash
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 Mev-Blocker block builder, even if it is not explicitly specified.
tornadoRPC
rpc.tornadoeth.cash
EigenPhi
builder.eigenphi.io
builder0x69
builder0x69.io
Titan
rpc.titanbuilder.xyz
beaverbuild.org
rpc.beaverbuild.org
BuildAI
https://buildai.net
f1b.io
https://rpc.f1b.io
rsync
rsync-builder.xyz
boba-builder
boba-builder.com/searcher/bundle
Gambit Labs
https://builder.gmbit.co/rpc
payload
rpc.payload.de
Loki
rpc.lokibuilder.xyz
penguinbuild
rpc.penguinbuild.org
JetBuilder
rpc.mevshare.jetbldr.xyz
tbuilder
flashbots.rpc.tbuilder.xyz
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 the ABC block builder and the XYZ block builder, as well as the TornadoRPC Mev block builder.
When configuring your transaction through the Protect RPC, it's crucial to ensure that the priority fee, also known as a tip, is set to a value greater than zero. This is a mandatory step to ensure that your transaction does not get overlooked.
To increase the likelihood of your transaction being selected by builders and thus potentially increasing your MEV returns, you can adjust the priority fee of your transactions. The priority fee is an additional fee paid to miners or block builders, incentivizing them to include your transaction in a block.
To set a priority fee while using Protect RPC, you can add the priorityFee parameter to your URL, specifying the amount in Gwei:
This sets a priority fee of 2 Gwei, signaling to builders that you're willing to pay a bit extra for the inclusion of your transaction.
Transactions that do not adhere to this requirement will be excluded by block builders and will not be included in the blockchain, except in cases where they're picked up as part of a bundle by a MEV-Searcher through MEV-Share.
Notes
The default priority fee is usually determined by the current network conditions and the base fee.
Setting a priority fee too low might result in your transaction being ignored.
Conversely, setting it too high might result in unnecessary costs without significant benefits.
It's important to balance the priority fee based on current network congestion and your desire for speed versus cost efficiency.
Example of Setting a Priority Fee in a Transaction Request
When sending a transaction request, you can adjust the maxPriorityFeePerGas field to set the priority fee. For instance:
Note: The maxPriorityFeePerGas value in the example is set to 1 Gwei for illustration purposes. The actual fee value should be adjusted based on current network conditions and your transaction urgency.
