Methodology

Last updated 3 November 2026 · applies to the datasets selectable at the top of each page.

This version

This site is an independent continuation of Orderflow.art, built by Flashbots in 2023–2024 to show how Ethereum order flow travels from users and frontends through solvers, mempools, order flow auctions (OFAs) and builders, and where its liquidity comes from. It is maintained by Davide Barone and is not affiliated with or endorsed by Flashbots. The code is a fork of flashbots/Orderflow.art (commit 003d36e) and stays under the AGPL-3.0 licence; the source code of this version is distributed with it.

The pages, Sankey columns and metric definitions are the original ones. The original site read materialized results that are no longer refreshed, so here the public Flashbots SQL is re-run on Dune for every day shown. Changes needed to keep those queries working on today's data are listed as declared fixes; anything that goes beyond the original definitions is kept in a separate extended dataset.

Datasets

Also computed but not shown in the selector for now: the same 206 days with the original definitions only (the extended dataset minus its flagged extensions) and 30 Jan 2024 with the original definitions, used for the comparison with orderflow.art (see Validation).

Why this period. It is the longest stretch in which every source is complete or has been repaired. From 17 February 2026 the public Flashbots Protect files shrink to about a third of their size, several March 2026 files are empty and no file exists after 27 May 2026, although the service still runs; the MEV-Share dataset ends on 31 March 2026. On 18–25 July 2025 the public mempool archive itself covers only 13–22 hours a day, and the Protect file of 30 June 2025 is missing. A shorter but complete period was preferred to a longer one with silent gaps.

How the data is computed

Eight public Flashbots views are re-run, one result per query and window:

They use the Flashbots router and frontend list (3004150), PMM maker list (2812729), Mempool Dumpster (3145549), Flashbots Protect (3023136), MEV Blocker bundles, Hashflow trades (3099694) and builder labels (3184477), with Dune's Spellbook tables (dex.trades, dex_aggregator.trades, prices.usd, protocol tables).

• Each query runs on one week (CoW and UniswapX liquidity on windows of at most four days). The original “last 7 days” filters are replaced by explicit time bounds, also on large joins. The bounds do not change results, because a transaction's trades, events and block share its block time; this was checked by re-running the same window.
• Results are aggregated per UTC day and per Sankey path, meaning the six columns plus a pair group. Transaction and user counts are carried as once-per-transaction and once-per-user flags, so they add up across paths.
• Pairs: the ETH/BTC and peg pairs listed by the original site are kept. Other pairs are grouped as “Other ETH/BTC pairs”, “Other peg pairs” and “Other long-tail pairs”.
• Every query execution is listed with its Dune execution ID under “Declared gaps and sources” in the notice at the top of each page.

What the charts measure

• Orderflow Sankey: the width is the USD value of retail trades from the Flashbots SQL, priced with Dune prices. Columns: frontend → meta-aggregator → solver or router → mempool (public/private) → OFA → builder.
• Liquidity Sankey: columns frontend → meta-aggregator → solver → aggregator → liquidity source → PMM. The first stages carry each transaction's requested volume, counted once per transaction. Later stages carry the USD value of each liquidity leg, so they can exceed the input when a trade is routed through several legs.
• Frontends page:
  • Volume is the sum of trade USD.
  • Transactions are distinct transaction hashes.
  • Users are distinct transaction senders per frontend. They are exact for a single day; over several days they are sums of daily or weekly counts, hence upper bounds.
  • Median trade size is interpolated from six size buckets.
• Shares refer to the retail flow captured by the original Flashbots queries, not to all DEX volume on Ethereum. Searcher, market-maker and arbitrage transactions that do not go through the listed frontends, routers and intent protocols are not included.

Declared fixes (all datasets)

1. Renamed Spellbook projects. 0x API→0x-API, 1inch LOP/1inch Limit Order Protocol→1inch-LOP, paraswap→velora, CoW Protocol→cow_protocol, DODO→DODO X. Without this, those flows would silently drop out of the original filters.
2. CoW solvers. The solver list used by the CoW liquidity view keeps only solvers active today, so past solvers became “Unlabeled Solver” (74 M$ on 30 Jan 2024). All named solver addresses are used instead, as in the CoW orderflow view.
3. 1inch Fusion resolver. Resolver 0x8571…a422 never has a name in oneinch.swaps. It is labelled Rizzolver, as in the original data.
4. CoW liquidity settlements. Settlements are taken from cow_protocol_ethereum.batches instead of “transactions sent to the settlement contract”. By February 2026, 43% of settlements went through solver contracts, and the original filter found only 45% of the CoW volume. On 2024 data the result is identical.
5. 1inch Fusion market maker. The resolver's own contract is now the transaction target, so the 1inch settlement contracts that forward the tokens are excluded from the maker lookup. This restores, for example, Wintermute's 16.0 M$ on 30 Jan 2024, as in the original.
6. CoW frontends. In the original-definitions datasets every CoW order is shown under one label, “Cowswap Integrators”, as on the original dashboard. The published SQL would use Dune app names where they exist.

Extensions (extended dataset only)

• Routers missing from the Flashbots list: 0x Settler, OKX DexRouter v2, Odos v3, LI.FI Permit2 Proxy, Relay, LiquidMesh, SushiSwap RedSnwapper, Enso and Rango. Over the period they raise the non-intent volume from 87.9 to 106.8 billion USD (+21%). Every extended row is flagged, so the original-definitions dataset is exactly the extended one minus those rows.
• CoW app names. Since mid-2025, Dune has no app name for essentially any CoW order. Names come from the public CoW API instead (one request per appData hash), which names 98.1% of the CoW volume.
  • Apps with at least 1% of CoW volume appear as “CoW · <app>”: CoW Swap, DefiLlama, Aave, CoW Swap-SafeApp and Safe Wallet Swaps.
  • Smaller apps are grouped as “CoW · other apps”.
  • Orders without any name keep the original label “Cowswap Integrators”.
• PMM labels at venue level for Native and Clipper, where the market maker itself is not visible on-chain.

OFA attribution from builder refunds (pilot, 3 Feb 2026)

The original OFA column can only name Flashbots Protect and MEV Blocker, the two services that publish their transactions. Other private routes (wallet RPCs and OFAs such as Servo, Blink or Nova) publish nothing per transaction, but many of them are paid back by the block builder: the builder refunds part of what the transaction paid it, in the same block and right after the bundle, to an address chosen by the service. Following a suggestion by Christoph Schlegel (Flashbots), this pilot finds those refunds and the transaction they belong to.

• Exact bundle match. A refund R that follows transaction T must satisfy value(R) = p × reward(T) − gas_used(R) × base_fee, with p a whole percentage and reward(T) the priority fee plus direct coinbase transfers of T, to within 3 wei. This is the rule in Titan's eth_sendBundle documentation. Titan, beaverbuild and Eureka pay the refund right after the bundle; Quasar and BuilderNet batch refunds at the end of the block, so T is searched among all earlier transactions of the block (the adjacent transaction wins when it matches, otherwise exactly one transaction must match). Share of in-block refunds matched on this day: BuilderNet 86%, Titan 91%, beaverbuild 85%, Quasar 88%, Eureka 81%.
• Which transaction. When the refund is a share of the user's own fee (Servo, bloXroute and some unnamed recipients), T is the user transaction. When it is a share of a backrun's payment (Blink, Nova and others), the user transaction is the one before T, the backrun's target. The role is set per address from the data: a recipient is treated as backrun-paid when the transaction before T is almost never public, which holds for bundle mates but not for unrelated neighbours.
• BuilderNet delayed refunds. Servo's refunds in BuilderNet blocks are paid later; each one equals 90% of one transaction's priority fee, which identifies the transaction (public refund API of relay.flashbots.net).
• Labels are added only where the original column is empty; Protect and MEV Blocker keep priority. Intent families keep the original column.
• By sender (lower certainty). A refund exists only when the transaction paid a tip or was backrun, but the RPC is a wallet setting. A private transaction without a label gets <label> · by sender when its sender has exact attributions to one label only on the day, it landed with a builder that label is seen paying, and the sender has at most 30 retail trades on the day (bots and relayers are left out). Senders are not fully consistent: the other transactions of senders with an exact label went 16.2 M$ through the public mempool and 12.6 M$ through Protect/MEV Blocker, against 18.7 M$ propagated; 4.2 M$ belong to senders seen with two or more labels and are not labelled.
• Result on 3 Feb 2026: 66.8 M$ of the 313.8 M$ of private non-intent volume without a Protect/MEV Blocker label are attributed (21.3%): 48.1 M$ from exact refunds and 18.7 M$ by sender. The rest pays no refund to a listed address, or is refunded in ways this rule does not match.

Recipients left out on purpose:

• Refunded transactions are in the public mempool (builder rebate on public flow): 0x3ff8…f540, 0x1e14…d1d7, 0x3096…e69f, 0x4157…c3e3, 0xd0e3…672a, 0x2947…947f, 0xa8bf…9fb3, 0xb92b…6bac, 0x6244…7ec0, 0x4cb5…9082, 0x333b…5ace, 0x1c75…0071, 0xb679…e211, 0xe77d…f6ec.
• Backrun refunds whose target transactions are mostly public (64%): 0xbfcf…6511.
• Safe receiving about 270 ETH a day of refunds on large non-retail flow: a private orderflow deal, not a retail OFA: 0x149b…14e5.
• Refunded bundles mostly carry Protect/MEV Blocker transactions (already labelled by the original OFA column): 0xce91…093b, 0xb666…000f, 0x63ef…129f, 0x875c…c763, 0x0c61…3d1f.
• Backrun refunds whose target transactions are mostly public (62%): 0xf96a…ca6a.

Related addresses: Blink's published searcher kickback address 0x743b…3869 (Base and Robinhood Chain docs; on Ethereum it receives builder refunds only from June 2026), the Gemini deposit contract it pays into (0xb0b8…e634), Nova's published Base refund address 0xfbfa…99fb (no Ethereum activity) and the forwarder 0xfeee…7ffc through which builders have paid refunds since about August 2026 (the recipient is in its calldata). Names marked inferred or hypothesis are not confirmed by the services.

Tested without result: BuilderNet's public fee-refund API pays one refund per bundle to the bundle's signer, so a service that signs its bundles with a fixed key should show up in the blocks where its refund address is paid. On 12,000 recent blocks (late October 2026, 1,649 built by BuilderNet) no signer is linked to the Blink or Nova addresses beyond its base rate, so signers do not name these services.

Execution cost along the paths (pilot, 3 Feb 2026)

Following a suggestion by Christoph Schlegel: the Sankey shows the realised trades, not what each party on the path keeps. This pilot estimates it for non-intent transactions (dataset «2 Dec 2025 – 16 Feb 2026», which includes this day): tick «Colour by execution cost» above the order flow Sankey to colour each link by its cost + gas (grey when less than 10% of the link's volume is measured), and hover a link for the split.

• Reference price. Binance spot 1-second prices (ETHUSDT, BTCUSDT, USDCUSDT, opening price of the block's second, from data.binance.vision); USDT is the numeraire, WBTC and cbBTC are valued as BTC.
• Cost. Value the sender gave minus value received, net per token over all transfers of the transaction, in bp of what was given. Only transactions where the sender moves just ETH/WETH, WBTC, cbBTC, USDC or USDT and receives at least half of what was given (bridges and partial fills are left out); the covered share of the volume is shown with every figure. Gas is reported apart (base fee burned, priority fee to the builder).
• Who keeps it (only on transactions where every token moved, by anyone, is priced): pools = net gain of the DEX pools the transaction traded with (LP fee plus price impact against the reference); fee recipients = addresses that only receive and get at most 5% of the input (frontend and integrator fees, positive slippage kept by the aggregator); other = every other address (routers, RFQ makers missing from dex.trades). OFA refunds = what the builder paid the OFA address for the transaction, and backrun bids = what the backrun paid the builder, both from the exact refunds above.
• Limits. A heuristic. Prices move within a second and the CEX–DEX basis enters the cost; intent families (CoW, UniswapX, Fusion), whose surplus and solver margins need other rules, are not covered yet; Servo's BuilderNet delayed refunds have no amount here.

Volume-weighted, all non-intent transactions: cost 18.3 bp, gas 0.8 bp, covered 39% of the volume. Sanity check: MetaMask Swaps shows fee recipients at 90.3 bp, against its published 87.5 bp fee; Blink and Nova kickbacks are 90% of the backrun bids.

OFA attribution and execution cost over the period (2025-12-02 – 2026-02-16)

The same rules as the pilot, run day by day (77 days, one Dune query per day). Three things change with a longer window:

• Address list. Refund recipients appear and fade, so the classification is rerun on one sample day per week (the Tuesdays of 7 weeks, 30 Dec 2025 – 10 Feb 2026) and the window uses the union: 64 addresses, 30 excluded. An address enters when it qualifies on at least one sample day and is excluded on none; listing it on days without its refunds labels nothing. A weekly census of all in-block builder transfers shows whether a named address kept receiving refunds (a stop with no transfers means it ceased, not a data error).
• Servo is matched in SQL from all BuilderNet delayed refunds to its three Safes (same 90% rule, unique matches); on 3 Feb 2026 this reproduces the pilot exactly.
• Prices: Binance 1-second prices at every slot second of the window.

On 2025-12-02 no mempool data exists (not even in the public archive): exact refund labels are kept, «by sender» labels are dropped and the day is left out of the shares below.

Over the window, 4644.4 M$ of the 16437.6 M$ of private non-intent volume without a Protect/MEV Blocker label are attributed (28.3%): 2940.5 M$ from exact refunds, 1703.8 M$ by sender.

In-block transfers from builders to each named address per week (weeks start on Tuesday 2025-12-02); unnamed listed addresses qualifying per sample day: 12, 12, 15, 21, 15, 32, 14.

December weeks. The weeks of 2025-12-03, 2025-12-09, 2025-12-16, 2025-12-23 were added after the list was fixed and use it unchanged. Their sample days, classified afterwards as a check, show recipients that are not in the list: 2025-12-03: 0xc609…1d28 (98), 0xa114…8cd1 (52), 0x2c5f…0836 (17), 0x1e43…6564 (10), 0xb489…8d6c (7); 2025-12-09: 0xc609…1d28 (165), 0x5057…5786 (11), 0x722a…f305 (9), 0x13b2…5785 (7), 0x1e43…6564 (6), 0xb489…8d6c (6); 2025-12-16: 0xc609…1d28 (297), 0xe23b…9871 (8), 0xe88f…b996 (8), 0x2c5f…0836 (7), 0xfef3…4ade (6), 0xce8a…70e4 (5), 0xd9ba…309d (5); 2025-12-23: 0xf4a0…84f6 (11); attribution in those weeks is therefore a lower bound. The largest, 0xc609…1d28, receives refunds only in the weeks of 2, 9 and 16 December 2025 and none afterwards (it stopped, it is not a data gap).

Completeness and known gaps

Every gap is classified as an error in the data (the activity existed) or as something that no longer exists.

Validation

Against the original site. For 30 January 2024 the full original Sankeys were downloaded from the orderflow.art API and compared link by link with this pipeline:

All remaining differences above 1 M$ have a named cause:

• labels updated since the snapshot: CoW solver Otex is now GlueX, UniswapX fillers are now labelled Flow Traders, and some builder labels changed;
• routers added to the Flashbots list after the snapshot: Pendle, Transit, Bitget;
• DEX models rebuilt in Spellbook: Curve −6.8 M$ in orderflow and −13 M$ in liquidity, Solidly +3.4 M$;
• revised Protect and Maestro datasets.

On every week of the period:

• every Sankey conserves volume (relative error below 10⁻¹³);
• liquidity input matches orderflow per family;
• daily series have no breaks;
• the pilot day 3 Feb 2026, extracted from its weekly run, matches the separate one-day runs: same transactions, same volume to within one part in a million.

Original methodology

The methodology of the original site, written by Flashbots, is still available on Notion, with the launch blog post. It describes the concepts and categories used here. Its statements about data sources and freshness refer to the original 2023–2024 deployment.