What Flashbots Searchers Need From Partial Hints

To search Flashbots MEV-Share order flow with partial hints, you need the transaction hash and enough disclosed information to decide whether a backrun is possible. A hint is selected data about a pending private transaction, not a fragment that can necessarily be matched like a partial text query. The name flashbots is often used broadly, but this search problem concerns MEV-Share: the system shares limited transaction information with searchers while keeping the full signed transaction private.

That changes the searcher's starting point. In a public mempool, a bot can inspect a pending transaction's visible fields and calldata. With MEV-Share, it works from what the sender has chosen to reveal. Flashbots describes searchers using those hints to build partial bundles: a bundle can refer to the user's transaction by hash while adding the searcher's own transaction around it. The matchmaker can then substitute the original signed transaction when processing the bundle. The searcher does not need the user's signature, but it does need enough evidence to predict what the transaction will do.

What information do Flashbots hints reveal?

Flashbots hints disclose specific parts of a transaction, and their usefulness depends on the sender's privacy settings. Documented hint types include the transaction hash, contract address, function selector, calldata and logs. The hash identifies the transaction for bundle construction; the other hints provide context about its likely effects. A contract address may indicate which application receives the call, while a function selector can narrow down which function is being invoked. Calldata or logs can reveal more, depending on what is shared.

More disclosure can make a transaction easier to evaluate, but it also exposes more about the user's intended action. Consider a decentralised exchange trade. A token pair in the logs may show which assets are involved, while withholding the trade amount and direction leaves important parts of the opportunity uncertain. If the hint set reveals less than a strategy needs, the searcher may be unable to form a useful backrun. If it reveals more, searchers may be better able to compete, but the user has shared more transaction information before inclusion.

For a searcher assessing a partial event, the practical questions are:

• Does the hash identify an event that can be referenced in a partial bundle?
• Do the disclosed contract, selector, calldata or logs identify a state change relevant to the strategy?
• Can the searcher read the relevant on-chain state and estimate how the proposed backrun would execute?
• Can the bundle meet its payment conditions and remain worthwhile after execution costs?

These checks separate a hint that is merely identifiable from one that is actionable. A hash alone may be enough to include the transaction reference, but it does not explain the trade or establish that a profitable opportunity exists.

How does a searcher use partial hints?

A searcher monitors the MEV-Share event stream, evaluates each event against a strategy, and uses the hash and disclosed fields to construct a candidate backrun. It then submits the partial bundle through the relevant MEV-Share mechanism. Flashbots documentation says the node simulates searcher bundles and forwards successful candidates to builders subject to the user's refund conditions. The searcher therefore needs a way to test the transaction sequence against current state; seeing hints is only the first step.

That simulation is central because hints describe selected data, not a guarantee about the final result. A trade's effect depends on the state of the contracts when the bundle executes, and competing transactions may change that state first. A searcher must also account for gas and the value it offers in return for inclusion. If the estimated gain disappears after costs, or the bundle fails its conditions, the transaction should not be treated as a viable opportunity simply because its hints looked promising.

This differs from searching the public mempool, where bots can inspect full pending transactions and often calculate against their disclosed parameters. MEV-Share gives the sender more control over what is revealed, while asking searchers to work with less complete evidence. It also differs from a simple transaction lookup: a searcher is not just trying to find a record, but to infer a state change and build a valid transaction sequence around it. That makes partial hints a privacy and market-design choice as well as an input to a bot.

What should users and searchers watch next?

Users choosing hint settings should weigh the expected usefulness of each field against what it reveals. Sharing more may give searchers a clearer basis for constructing backruns and could improve the chance of sharing value through refunds; it also reduces how much remains private before inclusion. Sharing less protects more detail, but may leave searchers unable to identify or price an opportunity. There is no universally best setting: it depends on the transaction and the user's priorities.

Searchers should watch the actual event fields they receive, the transaction's inclusion status, and whether simulations remain profitable as state changes. Users should watch which hints their wallet or application shares and what refund terms apply. The useful signal is not simply that an event appeared, but whether the disclosed information was sufficient for a valid backrun and whether that backrun produced value under the stated conditions. Partial hints make searching possible without full disclosure; they do not make an incomplete view equivalent to a complete transaction.