Mev Blocker
Introduction
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.
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 transactionsdefault_logs
Partial logs (the pool id and the fact that a swap was made) for curve, balancer, and uniswapV2/V3-style tradesTransactions 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.
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 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.
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.
Trace
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.
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.
Trace
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.
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.
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 Mev-Blocker 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 the ABC block builder and the XYZ block builder, as well as the TornadoRPC Mev block builder.
Setting Priority Fee
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.
Last updated