Protect Transactions

A user submits transactions given a specific configuration (hints_selected) including privacy and other related settings. https://docs.flashbots.net/flashbots-protect/mev-share#hints

A few major decisions for transaction inclusion are the number of builders you share the transaction with (more num_of_builders_shared is generally faster) and your requested MEVRefund % (refund_percent). The more you are willing to give to the block proposer the faster your tx should be included.

Some users send their transactions both to flashbots private RPC and the public mempool, these transactions are flagged (public_mempool) if flashbots sees the transaction there as well.

The Protect data is unique on the tx_hash created_at_block_number tx_id level.

Here, user 0x2ae2d42c90cff2ad91a003c79ffad61c36f9e03c is calling a contract 0x16409dd958719e702c5dc18cfa408563c7055b57. The transaction remained private, as they did not also send it to the public mempool (public_mempool = FALSE, tx was not found duplicated in public).

Note, at first they only shared it with 1 builder. They update their config to share it with more builders. Be aware that the same transaction can be repeated in the protect table with multiple configs.

MEVShare Transactions

Block Builders aren't necessarily the same entity as the validator that proposes a block on Ethereum. While Ethereum does not have enshrined separation of these roles, Flashbots enables validators to shop around for the most profitable block (the block with the best transactions for their goals of maximizing their fee revenue) via their MEVBoost product.

MEV Share incentivizes order flow to flashbots related builders by offering refunds on MEV extracted, the refund_value_eth column paid to refund_to.

The builders (sometimes they self-label in the extra_data column) will build a block for the validator to propose and (due to game theory) offer up some of the profit they earn from that block (the MEV) by paying the validator (fee_recipient_address).

Users using the protect product (user_tx_from) have their MEV transactions (user_tx_hash) backrun by the builder (backrun_tx_hash) and the builder returns a piece of the value refund_value_eth in a refund transaction (refund_tx_hash).

The protect user may choose collect these refunds in a separate address (refund_to) but the builder always sends refunds from their address (refund_from).