by Claude Donzé and Christoph Rosenmayr – October 29, 2026

Consumer trades on Ethereum generate value every block. Whether the app that creates it can capture it comes down to one thing: routing control. This piece on consumer orderflow adds to our 2026 series on the Ethereum Block Building landscape.

Thanks to the team at NuConstruct , 0xprincess and Eto, for their feedback and review.

This is the 5th piece in our Block Building series. New to the topic? Start with our Primer; the following two pieces walk the entire value chain, from order origination to block construction. Part 4 covers the transaction ordering value and how it exists in different forms, and now we’re focusing on a valuable resource on Ethereum: Consumer Orderflow.

1. Primer: Ethereum’s Blockspace Market
2. The Demand Side – Orderflow and the Priority Fee Landscape
3. The Supply Side – Builder Economics and Orderflow Relationships
4. The Conservation of MEV 
5. Consumer Orderflow – Sizing the Flow (this piece)
6. Consumer Orderflow – Capturing the Flow (upcoming)

Key takeaways: 

• Consumer orderflow – wallet swaps, DEX frontends, solvers, routers, and Telegram bots – is a meaningful share of priority fee spend, but how (and whether) it gets monetized depends almost entirely on who controls routing.
• Consumer flow creates value through two distinct channels: the priority fees users pay directly, and the MEV their transactions generate that searchers pay builders to capture.
• As shown earlier in our research series, less-sophisticated consumers systematically overpay for inclusion: MetaMask swappers spend an average of ~$1.27 per transaction – up ~8x from ~$0.15 in early 2024 – with Uniswap-frontend and Banana Gun users in a similar range and GMGN users above $2.2, while more sophisticated users tend to use solver models (CoWSwap, 1inch Fusion, UniswapX), which keep per-transaction priority fees low/near the minimum-viable fee paid
• Whether this value is capturable by the application that generates it comes down to RPC control: wallets, Telegram bots, and solver-based apps can choose where their users’ trades land; most frontends and routers currently cannot capture it without an architecture change.
• The apps that do control routing choose builders deliberately: Maestro and Banana Gun currently land above 67% and 82% of their respective priority fee spend in Titan blocks – against a blocks-built baseline of ~50%. Exclusive relationships with builders open monetization channels (rebates, refunds, improved execution) that are largely invisible onchain.
• In Part II, we will focus on how to measure flow, determining routing-control status, score builder counterparties, and monitor them – and argue that, done right, monetizing consumer orderflow is net beneficial for users: exclusive builder relationships remove overpayment at the source, and the growing services layer (preconfirmations, ordering guarantees, custom execution) makes these agreements more than a refund mechanism
• Dune dashboard (Consumer Orderflow): https://dune.com/gcm/ethereum-consumer-orderflow 

Introduction: how much is consumer orderflow actually worth?

Every 12 seconds, Ethereum auctions off the right to order transactions, and our two-part deep dive showed who wins it and why. Since the start of 2024, validators have earned $1.36B in execution-layer rewards, builders have generated $400M+ in surplus on top, and MEV searchers – who accounted for 50–80% of weekly priority-fee spend in recent weeks – have concentrated that surplus with the builders that serve them best, above all Titan. If you stopped reading there, you’d conclude that block building is a market by and for sophisticated players, and everyone else is a spectator.

That conclusion would miss one of the interesting open questions in the market – and if you run a consumer app, the one that concerns you directly: how much is your users’ orderflow actually worth, and why do a handful of apps capture that value while you and everyone else give it away?

MEV flow is, in one important respect, the simple case: searchers route their own transactions and choose their builders. Every bid is a trading decision – our markout analysis in this earlier article suggests searchers spend 90% of extractable profit on priority fees. This does not hold true for consumer orderflow. When a user swaps through MetaMask, clicks “swap” on a frontend, or types “/buy” in a telegram bot, an application sits between them and the block. The application, not the user, decides where the trade lands. The user neither knows nor cares which builder includes their transaction; they care about speed, inclusion, UX, and execution quality. They routinely overpay for those qualities relative to what a sophisticated party would bid, and their trades leak MEV that searchers pay builders handsomely to capture.

In other words: consumer flow generates value its originators are not equipped to price, and delegates – usually unknowingly – the decision about who monetizes it. For the application sitting in the middle, that value is either a dormant asset or a business model, and the difference comes down to a single factor: whether the app controls the RPC, the interface through which wallets and users submit transactions to the network.

This two-part series is the dedicated follow-up on consumer orderflow, structured around the following questions: how much value my flow generates and how to estimate it for my app specifically; whether my architecture can capture it and what changes if it can’t; what a deal with a builder could look like; who the credible counterparties are and what picking wrong costs users; whether to keep the value or return it; and how durable any of this is. We close with the first concrete steps to monetize consumer orderflow and argue why monetizing orderflow can be net beneficial for the user.

As before, our analysis is based solely on fully observable onchain data, all of which can be found in this dune dashboard. Factors such as latency, relay policies, and offchain rebate arrangements that are not directly observable onchain are noted where relevant but largely out of scope. We flag explicitly below where commercial terms leave the onchain record.

Defining consumer orderflow

We define consumer orderflow as trading transactions originated by end users but submitted through an application. Reusing the Flashbots orderflow labels and MEV labels from our demand-side analysis, this covers five segments:

1. Wallet swaps (MetaMask Swaps being the dominant example) embed trading directly into the wallet, giving the wallet full control over transaction construction and submission
2. DEX frontends (Uniswap’s interface and peers) generate the transaction but typically hand submission back to whatever wallet (and RPC) the user has configured
3. Solver-based meta-aggregators (CoWSwap, 1inch Fusion, UniswapX) take the user’s intent and delegate execution to sophisticated solvers who construct, price, and route the transaction on the user’s behalf
4. Telegram bots and trading terminals (Maestro, Banana Gun, and more recently GMGN) hold user keys or session permissions and control the full submission path, optimizing for inclusion speed in competitive token launches.
5. Routers/Agg Integrators (1inch, Kyberswap, etc.) are the onchain contracts these systems pass through, useful as a labeling layer but rarely a routing decision-maker themselves

On a pure volume basis, consumer orderflow constitutes between 35-45% of DEX volume on Ethereum. Measured against that same total, routers account for roughly 20%, solver models ~8%, DEX frontends ~7%, wallet swaps ~4% and Telegram bots ~0.5%.

A searcher’s routing choice within the transaction supply chain is a trading decision. A consumer’s routing “choice” is often whatever their application decides for them, so the value embedded in this flow accrues to whoever sits at the point of control. Applications compete for consumer flow by serving what the user actually wants from a trade. Those wants reduce to a handful of economic goals we summarize here:

No user optimizes for all of these at once, many are direct trade-offs: certainty against best price, simplicity against control, speed against cost – so weighting one means conceding another. That weighting is what defines a user type, and each type’s dominant goal draws it toward the application built to serve that goal: a mainstream swapper toward simple UX wallet swaps, the execution-sensitive trader toward solvers, the self-directed power user toward DEX frontends, the launch hunter toward Telegram terminals, and the programmatic allocator toward intent systems – with size and sophistication turning any of these profiles up or down rather than adding new ones. 

Applications, in turn, compete not by chasing every goal but by picking a set of goals and owning them: simplicity and a small trust surface, or execution quality and value recapture, or speed and asset screening. Each wins the users for whom its set of goals is the deciding factor. And because consumer flow is facilitated rather than self-routed, acquiring the user is the same act as capturing their flow: the application they choose is the one that builds and submits the transaction on their behalf, and so becomes the point of control it passes through.

We’ve now defined what consumer orderflow is, what a user wants from a trade, and how this flow is served. The next question is what that flow is worth. The answer, it turns out, lands neither in one place nor with one party.

How consumer flow generates value: two channels

Besides a fee on volume, consumer trades produce value twice: once through what the user pays to get included, and once through what the trade itself is worth to everyone else in the block.

Channel 1: the priority fees users pay directly

As covered earlier in the series, every Ethereum transaction pays a protocol-set base fee that is burned and a priority fee, which compensates the block builder for inclusion and ordering.

The optimal priority fee is the lowest fee that is just sufficient to secure the desired inclusion time. For inclusion in the next block, this means paying slightly more than the marginal transaction competing for the final unit of available blockspace. Paying less risks being excluded; paying materially more does not improve execution once inclusion is already secured and therefore represents unnecessary spending. However, this optimal value can only be identified during (for a block builder) and, more generally, after the block has been constructed (for anyone other than the builder of that block in question). When submitting a transaction, the user does not know how many other transactions will arrive before the next block, what fees they will offer, how much gas they will consume, or which transactions the builder will select. Moreover, builders may prioritize transactions based not only on their explicit priority fees, but also on the additional MEV they create (more on this below). As a result, the visible mempool does not reveal a single, reliable clearing price.

This problem is particularly difficult for consumers, who generally lack real-time mempool infrastructure, builder relationships, sophisticated inclusion models, and the ability to continuously replace transactions as market conditions change. They therefore rely on estimates (e.g. set by wallets, often derived from recent blocks and observed pending transactions). These estimates can work well under stable conditions, but may lag during sudden demand spikes. Wallets consequently tend to offer broad “slow,” “market,” and “fast” estimates rather than a genuinely optimal price. In effect, retail users must choose between overpaying for certainty and underpaying while accepting uncertain inclusion. 

One of the numbers we can look at is the relative share of priority fees paid in terms of traded DEX volume. Excluding Telegram bots (which pay higher priority fees often for sniping-related use cases), users of the other consumer orderflow categories often pay between 1-5 bps in priority fees. As these are added on top of existing application or volume fees this meaningfully contributes to onchain execution often being more expensive than executing on a centralized exchange.

When paying a higher priority fee is rational

A higher priority fee is rational when inclusion in an earlier block (or earlier within a specific block) has value to the user (economic value, certainty that trade/swap/transfer is done). By increasing the revenue attached to the transaction, the user makes it more attractive for block builders to include relative to competing transactions. This is most clearly rational when:

• the opportunity deteriorates quickly, such as a fast-moving trade or token launch;
• delay could cause the trade to cross its slippage limit and revert;
• the user must complete a transaction before an onchain state change (oracle update that triggers a liquidation);
• a pending transaction is blocking subsequent transactions from the same account;
• block space is congested and a low-fee transaction is unlikely to land within the required window.

Searchers and MEV flow provide the extreme example: they routinely bid away most of an opportunity’s expected profit because receiving nothing from a late transaction is worse than retaining only a small margin from an early one.

When it is irrational

Paying a higher priority fee is irrational when the transaction is not time-sensitive, when blocks have sufficient spare capacity, or when the fee is already above the marginal price required for inclusion. Once the transaction would have landed in the desired block anyway, every additional unit of priority fee is pure overpayment.

Who pockets this overpayment today? Block builders and block proposers, as direct revenue, unless the application in the middle participates in the fee path (through e.g. a refund RPC or an exclusive orderflow agreement; more on that below). 

Channel 2: the MEV consumer transactions create

Consumer transactions do not only pay priority fees; they can also change onchain state in ways that create profitable opportunities for others. A swap may move the price in a liquidity pool, a borrow may push an account closer to liquidation, and a large trade may create a temporary price discrepancy across venues. These state changes can make it profitable to execute another transaction immediately before or after the user’s transaction, or to place transactions around it within the same block. The value available from doing so is MEV and captured by searchers.

Searchers monitor pending transactions and onchain state for these opportunities, construct transactions or bundles that capture them, and compete for favorable placement in the block. For example (see earlier parts in the series here and here for details):

Atomic arbitrage: A consumer swaps $ETH for $USDC through a poorly routed pool, moving its price below another DEX; a searcher immediately buys $ETH from the underpriced pool and sells it on the other venue, capturing the difference in the same transaction bundle. Similar value arises on e.g. a lending market such as Aave when an oracle update makes a position liquidatable and a searcher captures the liquidation bonus. Because these opportunities are directly tied to an identifiable state change, an orderflow or backrunning auction can sell the right to capture them and return part of the proceeds to the user or protocol (more on this below).

Sandwiching: A consumer publicly submits a swap with 5% slippage tolerance; a searcher buys immediately before it, pushes the price upward while keeping the user’s trade executable, and sells immediately afterward at the user’s expense. The profit comes from exploiting both the disclosed routing decision and the price range the user has authorized, and can largely be prevented through private submission, tighter slippage or batch-based execution.

CEX–DEX arbitrage: $ETH rises on a centralized exchange while an AMM still quotes the old price, allowing a searcher to buy $ETH cheaply from the AMM and sell it at the higher CEX price.

Searchers compete aggressively for the same opportunities and therefore bid away much of the available value, paying builders for inclusion and ordering while retaining only a small profit margin due to this competitiveness. As a result, consumer transactions can generate value even when the user pays only an ordinary priority fee: the transaction itself creates an opportunity that searchers monetize and partially pass upstream through their bids for blockspace. 

Taken together, consumer orderflow creates value through two distinct channels: users explicitly pay priority fees for inclusion, while their transactions often generate additional MEV that – today – is largely captured by searchers and passed on to builders through competitive bids. In the next chapter, we size both channels using onchain data to understand how consumer activity has grown, where it stands today, and how much value runs through each channel.

Sizing the flow

80-90% of total sandwiched orderflow can be attributed to the consumer orderflow categories we defined above. The remaining 10-20% of flows are sophisticated enough to reach the chain without passing a recognizable intermediary contract (through direct calls, bespoke routers, automated rebalancing, etc.) – which is another way of saying flow whose originator is sophisticated enough to route around the applications altogether, and therefore not consumer flow in any sense that matters here. 

As we showed above, in 2026, about 45% of all DEX volume is consumer orderflow, the rest is MEV orderflow. What we can see from the relative market share graph below: DEX frontends are in steady structural decline, routers now serve around 50-60% of consumer DEX volume, and the solver models grew steadily until CoWSwap’s fee switch in November 2025 reduced their volume shortly after (while keeping revenue stable).

Next, we’re breaking down consumer orderflow in the two channels described above (see methodology in the Dune dashboard).

Channel 1: consumer priority fees over time

Consumer priority fee spend peaked in the first half of 2024 at more than $10M per week at the height of valuable onchain activity and has since compressed to a median of roughly ~$220k in recent weeks, largely tracking the decline in total execution layer rewards on Ethereum.

Normalized by block values (which have been declining throughout various changes in Ethereum and general lower activity), in terms of priority fee spent, consumer orderflow is ranging between ~3-15% of total priority fees in recent weeks (with the rest of priority fees being spent by MEV orderflow):

Within the consumer orderflow category, the composition has shifted: DEX frontends fell from ~40% at their peak to around ~12% of consumer priority fee share today, Wallet swaps rose from 1% to 20-30%, and routers growing from 2-3% to ranging between 10% and 20%. Telegram bot spend declined hardest both in notional and relative value throughout 2025, as token launches migrated to other chains, e.g. Solana, Base and more recently, Robinhood Chain. Token sniping is often the spend driver, and interestingly has rebounded in early 2026 with GMGN dominating the category, and in recent weeks peaking at up to 60% of priority fee spend.

We assume that three forces are driving these shifts. First, execution quality is winning the price-sensitive users: routers and solvers compete on net output – routing across venues, batching, MEV protection – while a single-venue frontend structurally cannot, so the trades where basis points matter migrate toward the architectures built to save them. The CoWSwap fee-switch episode is the natural experiment confirming how price-elastic this user group is: a change in the fee structure moved volume almost immediately.

Second, distribution beats destination: swapping has moved to where the user already is. The wallet is the one interface every onchain user has open, and embedding the trade there captures the mainstream swapper before a frontend gets the visit. The frontends’ loss isn’t necessarily a loss of existing users, but rather of users never acquired because they began swapping inside a wallet once those features went live.

Third, the redistribution tracks routing control: the growing segments (wallets, solvers, telegram bots) are the ones whose architecture lets them monetize their flow, and monetized flow funds the execution quality, speed, and product investment that acquire the next user. Frontends, which hand submission back to the user’s wallet, sit outside that flywheel, as well as routers, which are routing onchain and don’t have control over transaction submission. 

Intensity, not notional

Notional spend above tells you where the market is. Intensity – priority fees per transaction and per dollar of volume – tells you what a given flow is worth. The spread is significant: snipers paid up to 0.9% of their volume in priority fees in recent weeks, roughly 15x what Wallet swaps, 51x what frontend users, 114x what solver users, and 141x what Router users paid per $ of volume.

But the most interesting number in that table is not the Telegram bots – everyone expects sniping to be expensive (as it is a race to land a transaction earlier than others). It is the Wallet swaps: Users swapping through their wallet pay roughly 2-5x more per dollar routed in recent months than users doing the same trade through a DEX frontend: a market swap of one liquid token for another.

The intuitive explanation is user sophistication. Wallet swaps users are, on average, the least experienced participants in the dataset, they trade from the default interface of the first application they installed, and it is tempting to conclude that they overpay because they don’t know better: they accept whatever priority fee the interface suggests, or set one arbitrarily high to make the anxiety of a pending transaction go away.

The within-segment data below breaks that explanation. If overpayment were a user trait, near-identical products with near-identical users would show near-identical intensity. They don’t, as we show in the next section.

Wallet swaps

In this graph, we plot routed volume against paid priority fees in the last 180 days, the size of the dot indicates the transaction count. Binance Wallet routed ~$2.7B against ~$112k in priority fees; MetaMask routed ~$1.05B against ~$1M in priority fees, at comparable transaction counts, roughly 23x apart in intensity.

Part of the gap is mechanical: at similar transaction counts, Binance Wallet’s average trade is ~4x larger, and since a priority fee buys inclusion for a transaction rather than scaling with its size, larger tickets dilute per-volume intensity by that factor. That leaves the two wallets roughly 6x apart per transaction, for what is functionally the same product. The remaining gap has to come from choices made on what happens after a user submits a transaction, and three possibilities stand out:

First, fee-estimation defaults: the wallet suggests the priority fee, most users accept it blindly, and a conservative estimator versus a generous one produces this kind of persistent per-transaction spread. 

Second, submission path: flow routed through private channels or infrastructure with negotiated inclusion (more on this further below) doesn’t need to bid its way in through the public fee market the way broadcast flow does. 

Third, what could be happening here: a wallet is routing through an OFA-style refund RPC that rebates a percentage of priority fees to the orderflow provider. If the wallet doesn’t give that rebate back to the user, it earns more when its users pay more priority fees, converting generous defaults in UX from a cost into a revenue line. What we can observe with MetaMask Swaps onchain fits this description: as we showed before in the series, per-user priority fees are up ~8 since early 2024 against flat notional spend. Binance Wallet, by contrast, seems to not monetize swap flow at all – its parent monetizes the user on the exchange – so it can afford to treat priority fees as pure user cost to be minimized.

Looking at this chart, plotting priority fees per transaction and deselecting all but MetaMask, we can see that priority fees started going up clearly around May 2024 when MetaMask first introduced Smart Transactions (which moved MetaMask users’ transactions into their own submission pipeline). $ETH/USD can only partly explain the strong move: users paid ~$0.15 per transaction in January–April, and it then spiked to $0.7–$1+ in July, a 5–7x move, while $ETH went from ~$2,300 in January to $3,500 in summer, that’s +50% – so denomination effects can account for maybe a 1.3–1.5x drift of the observed 5–7x move.

Differences in priority fee intensity across applications are not necessarily the result of their submission infrastructure. They can also reflect differences in user bases, transaction types, and preferences around execution speed and reliability. However, MetaMask’s sharp increase coinciding with the introduction of Smart Transactions suggests that the application’s routing and fee-setting mechanisms played an important role. This distinction matters for the rest of the article: while users’ willingness to pay influences priority fee intensity, the application controlling transaction submission can significantly shape the fees ultimately paid. Depending on its infrastructure and incentives, it may minimize unnecessary expenditure, return part of the surplus to users, or capture some of that value itself.

Later on the chart, in early 2025, MetaMask users’ per-transaction spend fell sharply as network demand weakened and $ETH itself dropped from ~$3,400 to ~$1,800, reducing priority fees in dollar terms. From mid-2025, both reversed.

How these submission paths and refund arrangements actually work – and which apps can use them – is the subject of Part II. For now, the key takeaway is that priority fee intensity reflects both user demand and operator decisions. While differences between applications cannot be attributed to routing alone, MetaMask illustrates how changes in submission infrastructure can materially alter what users pay.

Frontends

Users that trade through Uniswap’s frontend (blue dot top right) are doing the most volume, more than $4.2B in the last 180 days, and are effectively the only frontend connected to a material amount in priority fees (~$736k over last 180 days); Curve (orange dot) does ~$1.5B in volume against roughly $11k in priority fees.

We see two possible explanations for the strong difference. The first is what type of users each brand acquires at the margin. Uniswap is the one DEX brand that has escaped the DeFi-native bubble. The frontend with the strongest mainstream brand therefore continuously inherits the least sophisticated marginal user: someone who accepts suggested gas settings (or flat out increases above suggested settings “to be sure”), retries failed transactions with a higher fee, and has never heard of an aggregator. Curve’s brand, by contrast, barely exists outside DeFi. Its user base self-selects for people who already know what a stableswap pool is – and who therefore know a stablecoin rebalance has no urgency worth paying for.

The second explanation is what gets traded. Curve’s flow is stablecoin- and pegged-asset-heavy: large, price-insensitive-in-time positions where nothing deteriorates if the transaction lands three blocks later, so the rational priority fee rounds to zero. Uniswap’s long-tail token flow includes the trades where timing feels urgent – volatile assets, new listings, positions users are anxious to enter or exit – which justifies some genuine priority fee spend. Larger average trade size on Curve dilutes per-volume intensity further, for the same mechanical reason as in the wallet comparison above. The two explanations are hard to fully observe onchain, but generally: sophisticated users and patient assets both produce low intensity, and the intensity gap reflects who shows up and what they trade, and on both counts Uniswap’s frontend concentrates the orderflow that is likely to overpay.

Telegram bots

From the graph above we can see that users that use GMGN (blue dot) pay more per volume (~$2.2M in priority fees on ~$379M in volume) than Banana Gun (orange dot, $283k in priority fees on ~$132M in volume). One possible explanation could be that Banana Gun (and Maestro) have optimized the transaction submission path more than GMGN. In April 2026, GMGN announced that further optimizations are coming to the Ethereum experience – which might include less significant overpaying for priority. The difference could also come from usage, and token sniping becoming less relevant to Maestro’s and Banana Gun’s user base.

Routers

KyberSwap (blue dot right) does the most volume ($11.1B) in the category on mid-range priority fee spend ($145k) and is growing fastest – Kyberswap gives gas suggestions to users’ wallets, even though, like all frontend-based aggregators, it never touches submission itself (and seems to be very efficient at it!). 

Li.Fi. (blue dot left) is the outlier in the other direction, low volume ($533M) against relatively high priority fee spend ($99k). Its architecture might partly explain why: LiFi is predominantly an API integrated into other wallets and apps, so its flow inherits fee defaults from dozens of integrators, and its routes are often complex multi-hop and cross-chain transactions, where a revert is expensive enough that paying a higher priority fee is the conservative default. The pair is a useful contrast for the chapter’s argument: within one segment, the operator that owns its full quote-to-suggestion pipeline lands near the efficient range (KyberSwap), while the one whose parameters are set downstream by integrators shows the widest overpayment – another appearance of intensity as an operator (or in LiFi’s case, integrator) choice.

Solvers

Both models (1inch Fusion and CoWSwap) delegate execution to sophisticated parties who construct, price, and submit the transaction on the user’s behalf – which is why the segment as a whole sits near the efficient floor. But within it, CoWSwap ($130k in priority fees on ~$7.8B volume) runs roughly 20x leaner per dollar than 1inch Fusion (~$373k on ~$1.2B), and the likely explanation is where each design puts the competition: CoW runs a batch auction that is decided offchain: solvers compete on the surplus they can deliver, the winner receives exclusive settlement rights for that batch, and the single settlement transaction – amortizing its priority fee across many orders at once – faces no onchain race at inclusion time, so the winning solver can bid close to the bare inclusion minimum. Fusion inverts this: orders decay along a Dutch auction and the first resolver to land a fill onchain captures the spread, so resolvers compete at the point of inclusion itself – structurally the same race searchers run – and each individually filled order carries its own priority fee, un-amortized. In other words, both designs make sophisticated parties pay the fees, but CoW’s auction settles before the block while Fusion’s settles in it, and competition inside the block is what priority fees price.

Comparison between segments

On this last graph, we plotted the different color-coded categories in one chart (Telegram bots = yellow, Routers = blue, Wallet Swaps = pink, DEX frontends = grey, and the outliers get more apparent: KyberSwap (bottom right) doing most volume with lowest priority fees spent, while the Telegram Bots are paying high amounts of priority fees on relatively low volume. One of the clear outliers in this chart is MetaMask Swaps, which pay more in priority fees on similar volume as Banana Gun. We can also see the large differences within a segment, such as the intensity of the different Telegram bots (in which Maestro paid the most priority fees per volume).

Even within the same segment, we observe wildly different priority fee intensity. The conclusion is that priority fee spend is not only a representation of a segment’s users and their preferences; it is also an engineering and business choice made by the app’s operators.

GMGN users pay two-thirds of what the most sophisticated stat-arb operation pays but a meaningful part of that is informed spend on genuinely contested inclusion. These users are in a race, and priority has real value to them, structurally the same reason searchers bid. The MetaMask figure is a default accepted for uncontested trades we can observe onchain today. The solver row shows what informed handling of uncontested flow looks like: near the efficient floor. The gap between a segment’s row and the efficient fee for that segment’s trades is the per-transaction headroom – rebate potential for default-driven flow, a priceable execution service for contested flow.

Channel 2: MEV created by consumer orderflow

Everything so far has priced channel 1: the fees users visibly attach to their own transactions, where we could measure each app’s gap to the efficient floor and trace it to operator defaults and routing. Channel 2 is the value a consumer trade gives off after it is submitted: the arbitrage, backruns and sandwiches it makes possible, monetized not by the user’s fee but by the searchers and builders competing to capture it. The user never sees this leakage anywhere, and it does not show up in the app’s priority fee intensity. A wallet can look perfectly efficient on every chart above while its flow is monetized heavily downstream. 

Measuring channel 2 however is inherently rougher, as we have to attribute consumer trades to the MEV transactions they triggered. The observable part is sandwiching:

The chart shows the priority fees searchers paid each week for the right to sandwich consumer trades, broken down by the victim’s segment – in effect, the market price of exploiting each application’s users. Unlike the other MEV flows (stat- and atomic-arb) discussed below, this is value taken directly from users: every dollar an attacker spends here is financed by worse execution for the trader being sandwiched, so the collapse from $4M+ per week in early 2024 to near zero today is an unambiguous win for consumers! 

This is the result of MEV protection maturing and 95% of DEX volume moving to private submission. DEX frontends and wallet swaps – the segments where transactions still reach the public mempool by default – dominated the victim pool, aggregators retained a persistent base layer through their onchain (public) routing, while the solver segment is nearly absent across the entire window: batch auctions and private execution eliminate this leak by construction.

MetaMask Swap users stopped from being sandwiched – a routing decision?

An interesting observation is selecting just MetaMask Swaps users when looking at the sandwiching data. The timing matches MetaMask’s product history: Infura, MetaMask’s default backend, enabled MEV protection by default in March 2025, routing transactions to a virtual mempool instead of the public one, which lines up with the Q1 decline. The October 2025 break coincides with MetaMask’s major product overhaul that month: a redesigned app and the Rewards program (which requires routing swaps through MetaMask’s pipeline). Three months later, in January 2026, Consensys’s SMG acquired MEV Blocker, the refund RPC, completing the stack: an operator that first routed all its flow privately, then bought the infrastructure that monetizes the flow.

Comparing this to e.g. Uniswap Frontend or OKX wallet (with a similar set of users), they keep getting sandwiched. One of the explanations could be that MetaMask Swaps started routing privately through an OFA-style refund RPC (and omitting the public mempool altogether). 

Stat- and atomic arbitrage

For the non-sandwich portion – the backruns and arbitrage consumer trades create – it helps to be precise about the causal chain, because the two strategies are triggered by different things. Atomic arb is triggered by price impact. When a consumer swap pushes a pool’s price away from the same pair’s price on other venues onchain, a searcher can buy from the displaced pool and sell on the others in one atomic bundle, and the profit available is a direct function of how far the consumer’s trade moved the pool. The consumer transaction is the opportunity: no consumer price impact, no atomic arb. Stat arb is driven by temporary price dislocations between venues. Consumer trades can create or widen those dislocations by moving an AMM away from the broader market price, while offchain price moves can leave the AMM temporarily stale until arbitrageurs/searchers realign it. More consumer flow therefore creates more moments where onchain prices diverge from fair value. The onchain anchor is less directly attributable than for atomic arb: stat-arb profitability comes from capturing these cross-venue deviations, of which consumer swaps are one source rather than necessarily the trigger. The onchain anchor for pricing the more directly attributable of the two: atomic arb spends an average of ~0.4% of its own DEX volume as priority fees (Part I; note the denominator is the arbitrage legs’ volume, not the consumer volume that triggered them).

This causal chain also determines which segments leak most: 

Telegram bot driven memecoin flow leaks the most per dollar: a $5k buy in a $50k-liquidity launch pool moves price by whole percentage points, creating a rich backrun on nearly every trade. As these meme tokens rarely trade on CEXs, the realignment is almost purely atomic arb across the token’s few onchain pools. 

Wallet and frontend flow in liquid majors leaks moderately but steadily: a retail-sized ETH/USDC swap in a deep pool moves price by fractions of a basis point, individually too small to backrun profitably, but this flow contributes to the aggregate displacement and stale-price surface that CEX–DEX searchers harvest continuously. Less of a per-trade trigger than a standing subsidy to the largest MEV category. 

Router flow sits in between and varies with routing quality: good routing splits a trade across pools precisely to minimize impact, which simultaneously minimizes the backrun it leaves behind, so the same routing engine that saves the user basis points also shrinks channel 2 leakage, one reason leakage differs so much within the segment. 

Solver flow suppresses leakage by construction: batching nets opposing orders against each other before they ever touch a pool, and solver competition internalizes the remaining realignment into the quote, the arb happens inside the auction, priced into the user’s fill, rather than onchain after it.

In aggregate: what does this mean for a consumer app? 

Now – for an app with a certain transaction count and volume, what is the realistic annual figure that its users are overpaying in priority fee and creating in MEV? One method to think through is applying the two intensity numbers above: priority fee per transaction (channel 1) and leakage per dollar routed (channel 2).

For example: a mid-sized wallet doing 25,000 swaps per week at the observed $1–1.2 priority fee per transaction generates $25–30k per week in channel 1, roughly $1–1.5M annualized, that its users are already (over)paying in priority fees. If it routes $40M weekly volume and its flow leaks 5–15bps into channel 2, that is another $1-3M annualized currently split between searchers and builders. 

A seven-figure annual sum, sitting in the flow of a mid-sized app. Whether you can claim any of it comes down to one question: who controls where your users’ transactions go? That question is the topic of  Part II.

With the table above we conclude Part I. Three findings carry forward: consumer orderflow pays priority fees far above the efficient floor, and the gap is set by operator defaults and routing, not user sophistication. The MetaMask series decoupling from a falling clearing price the moment Smart Transactions launched is the cleanest observation in our data. The spread in intensity across functionally identical products is enormous: 23x between wallets, 20x between solver models, so the overpayment is not a cost of doing business but a variable most operators never chose to optimize as of today. And the visible fees are only channel 1: the same flow throws off a second, comparable pool of value downstream as MEV, monetized today by searchers and builders who never face the user – which is to say, by default the value goes to whoever is watching the mempool, because no one at the app ever made a deliberate choice about where its transactions go. 

Part II will be is about making that choice deliberately: what routing control actually requires and which segments already have it, the four mechanisms for capturing the flow’s value, from the public ~90% rebate to exclusive builder relationships, what the sophisticated players chose when we trace their routing onchain, how to score a builder counterparty, and the final decision every app faces once the value arrives: keep it as revenue, or return it to users as execution quality.

If you have feedback or are interested in these topics, feel free to reach out to Claude, claude@greenfieldcapital.com. All charts and underlying queries can be found in this Dune dashboard and will be maintained going forward.

Note: Greenfield has investments in Titan’s parent company Gattaca, CoW Protocol, and NuConstruct. This analysis is based exclusively on publicly available onchain data via Dune Analytics. The findings reflect onchain observations and independent research views.