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.

MEV BLOCKER

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.

https://rpc.tornadoeth.cash/mev

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.

Max Privacy​

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

https://rpc.tornadoeth.cash/mev?trace=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.tornadoeth.cash/mev?trace=calldata&trace=contract_address&trace=function_selector&trace=logs&trace=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	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

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.

Trace	Description
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:

https://rpc.tornadoeth.cash/mev?trace=calldata&trace=logs&trace=hash

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.

Trace	Description
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:

https://rpc.tornadoeth.cash/mev?trace=calldata&trace=logs&trace=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 Mev-Blocker block builder, even if it is not explicitly specified.

Name	RPC
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:

https://rpc.tornadoeth.cash/mev?builder=tornadoRPC&builder=XYZ

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:

https://rpc.tornadoeth.cash/mev?priorityFee=2

Priority Fee: >0 ETH

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:

{
  "jsonrpc": "2.0",
  "method": "eth_sendTransaction",
  "params": [{
    "from": "0xYourAddress",
    "to": "0xRecipientAddress",
    "value": "0xValue",
    "data": "0xData",
    "maxPriorityFeePerGas": "0x3B9ACA00" // This sets the priority fee to 1 Gwei
  }],
  "id": 1
}

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.