MEV detection methodology

Current decision process

1. Resolve a submitted transaction hash, or find recent supported swaps sent by a submitted wallet.
2. Fetch the mined block and locate the victim’s transaction index.
3. Decode supported router calls to identify the target pool and swap direction.
4. Search earlier and later transactions in the same block for the same pool.
5. Require a preceding swap in the victim’s direction and a following swap in the opposite direction, linked to the same surrounding sender.
6. Return the candidate frontrun and backrun hashes as inspectable evidence.

Supported signals

• High confidence: linked sandwich structure and recognized liquidation calldata.
• Medium confidence: identical calldata sent to the same contract earlier in the block by a different sender.
• Low confidence: an unlinked opposite-direction backrun or swap events across multiple pools.

Verdict meanings

High-confidence MEV detected

The analyzer found a strong supported pattern, such as a linked sandwich.

MEV-related activity found

One or more supported signals were found, but the result may require traces and profit accounting.

No supported MEV detected

No matching pattern was found within current coverage. This is not proof that the transaction experienced no MEV.

Pending, reverted, not found, or unsupported

The transaction cannot yet be evaluated, did not execute successfully, is unavailable, or does not match a supported pattern.

Limitations

• The live analyzer currently recognizes Uniswap v2 and v3 swap event formats on Mainnet and Sepolia.
• Analysis is bounded to 12 transactions on either side of the selected transaction to control RPC cost.
• Sophisticated searchers may use multiple addresses, private bundles, or intermediate contracts.
• Production attribution should additionally include traces, internal calls, token transfers, builder data, and net profit after gas and fees.
• Wallet-wide lookup requires a separate indexed history provider.