frontrunning.xyz (DYOR before using this to accuse)

Glossary

Scope: UMA ManagedOptimisticOracleV2 on Polygon (0x2C0367…58B1), proposers on the Risk Labs whitelist (0x9F3588…c463). All figures respect the selected window and categories.

Underlying definitions
submissionOne transaction's shot at one request. A wallet can make several for the same request in one block: batching it into two different batches, firing from two addresses for redundancy, or replacing a transaction at a higher fee.
attemptA (wallet, request) pair — a wallet's whole effort at a request, aggregated over all its submissions. Established by re-executing each transaction from a tracked proposer as if it had been first in its own block (state at the end of block N−1, block context of N) and collecting the MOOV2 ProposePrice events it would have emitted. That replay is the only way to see losing attempts: a loser either reverts, or -- when the proposer batches with try/catch -- succeeds on chain having emitted nothing at all.
attempt clockAn attempt's time is its earliest submission. A replace-by-fee bump counts as the same submission only if its calldata, target and value are byte-identical; change any of them and it is a new submission with its own time. That check is what stops a nonce being used as a container -- planting a cheap early transaction and then replacing it with extra proposals bolted on after spotting a competitor.
winning blockThe block in which a request was actually proposed. An attempt counts only there, so there is at most one attempt per (wallet, request) and at most one race per request. A transaction that failed for its own reasons never produces a top-of-block proposal and is not an attempt.
contested (a race)A request whose winning block held attempts from two or more distinct wallets.
mempool timeEarliest sighting of the transaction across two independent listeners, keyed by transaction hash.
What counts as frontrunning

Frontrunning here means getting ahead on chain of a rival whose transaction you could already see. Two things must both be true: the wallet's submission reached the mempool after a rival's, and it still won the request. Arriving late and losing is just losing; arriving first and winning is just being fast.

Ordering is decided among publicly visible submissions only. A transaction sent privately is one no competitor could have reacted to, so it never makes anyone else late.

the wallet's submissionmempool ordering
Sent publicly, and it was the earliest public submission (or within 25 ms of it) first
Sent publicly, but another public submission was earlier late
Sent privately, while at least one rival was publicly visible unverifiable
Sent privately, and every rival was also private first

A late row that also won the request is counted under frontran. A late row that lost still counts as Mempool Copying — the wallet reacted to a rival either way, it just didn't bid high enough. That is why the two columns differ, and why the Frontrunning Ratio weighs wins-from-behind against the attempts a wallet made on its own information. unverifiable rows are what turn every one of those figures into a range: the low end assumes none of them were reacting, the high end assumes all of them were. first rows never contribute.

Columns
Won (Blocks)Proposals that landed on chain, and in parentheses the count of distinct blocks they landed in. A wallet batching many proposals into one transaction shows far fewer blocks than wins — those are not independent decisions.
Attempts (Blocks)Distinct requests the wallet tried to propose, and the distinct blocks those attempts landed in.
Contested Block %contested attempts / attempts. How often this wallet's proposals ran into a competitor. On its own this says nothing about conduct — some markets are simply crowded, and a fast proposer can race constantly and legitimately. An input to Mempool Copying, not a verdict.
First to Mempool %first / (first + late), i.e. over races where the ordering could be decided. Not conditioned on winning, so a wallet that is consistently first and consistently loses still scores high. Also an input rather than a verdict.
Mempool Copying %Reported as a range over evaluable attempts:
· low = late / evaluable — proven: observed, and a public rival was earlier
· high = (late + unverifiable) / evaluable — the worst case if every private submission turned out to be a reaction A gives the unverifiable count. Where nothing is unverifiable the two ends coincide and a single figure is shown. On its own this is an input rather than a verdict — racing often is normal in a crowded market, and being second occasionally is normal for anyone. What matters is how much of the wallet's business it accounts for, which is the Frontrunning Ratio.
Suspected FrontrunningRaces won while late — got ahead on chain despite arriving later in the mempool. A range when some of those wins were submitted privately and cannot be proven either way.
Victim / Was FrontrunRaces where this wallet was first and still lost. Proven only when the winner was itself proven late; the upper end adds races whose winner was unverifiable.
Honest AttemptsThe complement of Mempool Copying over evaluable attempts: those that were either uncontested, or contested with this wallet first into the mempool. Work the wallet demonstrably did on its own information. A range whenever private submissions leave some attempts unresolved — the low end assumes every unverifiable one was copying, the high end assumes none was. It is the denominator of the Frontrunning Ratio.
Frontrunning RatioThe only column that carries a judgement. Ratio of proposals won with frontrunning to honest, non-copied, attempts — Suspected Frontrunning / Honest Attempts. It asks how much a wallet gains from arriving late against how much business it does on its own information. A proposer that is simply busy and occasionally second scores low; one whose wins come disproportionately from behind scores high. Shaded green below 0.5 and red above 2, with each end of the range shaded on its own threshold. Shown as when there are no honest attempts to divide by — every evaluable attempt was Mempool Copying — which is the most extreme reading, not a missing value. A dash means there is nothing to report at all. Suppressed to plain text below 5 winning blocks.
Private %winning txs never observed / wins while a listener was demonstrably running. Wins from before coverage began are excluded entirely rather than counted as private. Left uncoloured: routing around the public mempool is legitimate anti-MEV defence as well as evasion, so it is context rather than an accusation. It is also the driver of the ranges in Mempool Copying and Frontrunning Ratio — a wallet with a high figure here will have wide bounds there.
Reading the shading
beside a walletFewer than 5 winning blocks. All verdict colours are withheld for that row, however extreme the percentage: a rate built on one or two batched transactions is not evidence.
beside a rangeHow many of those races were unverifiable, and why.
grey percentageFewer than 10 observations in the denominator — shown for completeness, never highlighted.
every (n/m)The literal numerator and denominator behind the percentage, so its weight is visible. 100% over two races reads exactly like 100% over two thousand without it.