Intent Solver Quality Benchmark 2027: CoW vs 1inch vs UniswapX vs Bebop

The DN Intent Solver Quality Benchmark measures price improvement, fill reliability, execution speed, adverse tail outcomes and competition quality across CoW Protocol, 1inch Fusion, UniswapX and Bebop JAM.

Data reviewed: 2 September 2026

Methodology: DN-ISQB v1.0

Affiliate disclosure: Decentralised News may earn compensation when eligible readers use certain partner links. Commercial relationships do not determine platform inclusion, methodology, observations, scores or conclusions.

Summary

Intent-based DEXs do not merely find a route. They delegate execution to competing solvers, resolvers, fillers or market makers.

The DN Intent Solver Quality Benchmark measures whether that competition actually improves the trader’s result.

Its core metric is:

Net Solver Improvement = Realized Execution Value − Gas-Adjusted Counterfactual Execution Value

DN then measures fill reliability, execution latency, quote integrity, adverse tail outcomes and solver competition across order sizes from $1,000 to $1 million.

Key Findings

• The best quoted price is not necessarily the best execution. Intent systems should be evaluated using the amount actually received after settlement.
• Intent-based exchanges use materially different auction architectures. CoW Protocol uses combinatorial batch auctions, 1inch Fusion uses resolver competition around a Dutch auction, UniswapX uses fillers and Dutch-auction execution, while Bebop combines solver auctions with professional market-maker RFQ liquidity.
• Gasless does not mean economically free. In systems such as 1inch Fusion, the resolver pays blockchain gas, but the economics of gas are reflected in whether and when filling the order becomes profitable.
• Solver quality needs a counterfactual. A trade receiving 5 basis points more than its signed minimum has not necessarily generated 5 bps of solver alpha if a direct AMM route would have produced 10 bps more.
• Price improvement is only part of solver quality. Reliability, time-to-fill, tail outcomes and failed settlements matter.
• Research associated with Uniswap found Dutch-auction order-flow systems produced average price improvement of roughly 4 to 5 basis points in the sample studied, while also finding execution differences particularly material at larger order sizes. This is useful evidence, but DN classifies it as THIRD-PARTY / VENUE-AFFILIATED RESEARCH, not independent DN observation.
• A July 2026 academic study of CoW Protocol’s solver market found solver concentration changed following a reward-policy reform while average execution quality remained broadly unchanged in its sample. That is an important warning against assuming more solvers or lower concentration automatically means better prices for users.
• DN-ISQB v1.0 deliberately does not declare an empirical winner. The methodology is being defined before collecting the synchronized dataset.

The Next Battle in DEX Execution Is Not AMM vs Order Book

It is:

Solver vs Solver

The first generation of decentralized exchange analysis focused on liquidity pools.

The second focused on aggregators.

The next generation increasingly asks users to express an intent:

I have this asset.
I want that asset.
I require at least this much.
Find the best way to make it happen.

The user does not necessarily determine:

• which AMM to use,
• which pool to route through,
• whether to use private liquidity,
• whether to batch transactions,
• whether to match another user’s order,
• how to manage gas,
• how to split the trade.

A specialized execution agent handles those decisions.

Depending on the protocol, that participant might be called a:

solver

resolver

filler

market maker

or another liquidity/execution provider.

That creates an entirely new benchmarking problem.

What Is an Intent-Based DEX?

A conventional DEX transaction usually says something close to:

Execute this particular series of smart-contract calls.

An intent says something closer to:

Produce this desired economic outcome under these constraints.

That gives an execution system more flexibility.

For example:

Traditional route

ETH → Uniswap pool → USDC

versus:

Intent

Sell 100 ETH.

Receive at least X USDC.

Allow competing execution providers to determine how.

A solver might discover:

• direct AMM liquidity,
• several AMMs,
• private market-maker liquidity,
• another user’s opposite order,
• a batch,
• an RFQ,
• just-in-time liquidity,
• a superior gas strategy.

Theoretically, more execution freedom should make better outcomes possible.

The DN benchmark asks whether that theoretical opportunity actually reaches the user.

The Fundamental Problem With Ranking Intent DEXs

Suppose four protocols execute the same $100,000 trade.

At first glance:

D wins.

But suppose the market moved during execution.

Or one system settled ten seconds later.

Or one absorbed gas while another required the user to pay it.

Or D failed 5% of comparable intents.

Or the best direct AMM route at the same instant would have returned:

$99,995

Now the conclusion changes.

That is why DN does not use raw received amount alone.

The DN Counterfactual Execution Model

The central challenge is determining:

What would the user probably have received without the intent auction?

DN calls this:

Counterfactual Baseline Execution

For every intent observation, DN should construct an equivalent non-intent execution using:

• the same chain,
• same token pair,
• same input amount,
• same reference timestamp or block,
• comparable gas assumptions,
• comparable available public liquidity.

For Ethereum/EVM tests, this could include a standardized simulated direct-router execution.

The purpose is not to claim the counterfactual is perfect.

It is to create a consistent yardstick.

DN Net Solver Improvement

For an exact-input transaction:

Net Solver Improvement

NSI = 10,000 × (REV − CEV) ÷ CEV

Where:

REV = Realized Execution Value received by the user

CEV = Gas-adjusted Counterfactual Execution Value

Example:

Counterfactual direct execution:

$99,900

Intent execution:

$99,950

Difference:

$50

Net Solver Improvement:

approximately 5.0 bps

Positive is better.

Negative means the intent architecture underperformed the standardized baseline.

Why Realized Execution Matters More Than the Quote

Suppose an intent platform displays:

100 ETH → 401,000 USDC

The order eventually executes for:

401,250 USDC

That appears to represent:

$250 of improvement

But suppose DN’s synchronized counterfactual direct route would have yielded:

401,180 USDC

The meaningful improvement created by the intent system is closer to:

$70

not $250.

The quote can therefore answer:

Did the user beat the displayed expectation?

The counterfactual answers:

Did the execution system actually outperform an available alternative?

Those are different questions.

DN Solver Surplus Attribution

Intent systems frequently use the word surplus.

But surplus needs a reference point.

DN therefore separates:

Quote Surplus

Realized value minus displayed quote.

Limit Surplus

Realized value minus signed minimum.

Counterfactual Surplus

Realized value minus standardized alternative execution.

The third is usually the most useful when comparing execution systems.

A solver can generate substantial surplus over a deliberately conservative minimum while still underperforming a competitive market route.

DN User Surplus Capture Ratio

DN introduces another useful metric:

User Surplus Capture Ratio

USCR = User Realized Improvement ÷ Total Measurable Improvement Opportunity

Suppose the available execution opportunity relative to the baseline is:

10 bps

and the user ultimately receives:

8 bps

of that improvement.

USCR:

80%

This metric will be used only when DN has sufficient information to estimate the total opportunity credibly.

It should not be fabricated where the solver’s private economics are unknowable.

Five Dimensions of Solver Quality

The eventual DN benchmark should not reduce everything to price.

1. Net Price Improvement

Did the solver outperform the counterfactual?

2. Fill Reliability

Did the signed intent actually execute?

3. Time to Fill

How long did the user wait?

4. Quote-to-Fill Integrity

How closely did execution correspond with the economic expectation shown before signing?

5. Tail Execution Quality

What happens in the worst 5% of cases?

Those dimensions create a much richer view than:

“Protocol X is gasless.”

DN Fill Reliability

An intent is not valuable if it frequently expires.

DN defines:

Fill Reliability

Completed Signed Intents ÷ Valid Signed Intents

Suppose:

1,000 valid intents

985 filled successfully

15 expired, failed or were abandoned for execution-related reasons

Fill reliability:

98.5%

Cancellation initiated by the user should generally be separated from solver failure.

So should orders deliberately designed to remain open.

Time to Fill

Two systems can produce the same economic result with very different waiting times.

DN therefore records:

Median Time to Fill

P75 Time to Fill

P95 Time to Fill

The P95 metric is particularly important.

A system that usually fills in three seconds but occasionally waits three minutes is operationally different from one that consistently fills in ten seconds.

DN Execution Tail Risk

Average price improvement can be misleading.

Imagine:

System A

Median improvement:

+5 bps

P95 adverse outcome:

−35 bps

System B

Median improvement:

+4 bps

P95 adverse outcome:

−5 bps

Which is better?

A retail trader may prefer A.

An institution executing $5 million might strongly prefer B.

DN therefore introduces:

Adverse Execution Tail

The 95th-percentile adverse deviation from the standardized counterfactual.

Lower is better.

Why Order Size Changes Everything

The benchmark should run at four standard sizes:

$1,000

$10,000

$100,000

$1,000,000

where executable.

Why?

Because solver advantages are unlikely to be constant.

At $1,000:

• gas optimization can matter enormously,
• public AMM liquidity may already be sufficient,
• private liquidity may add little.

At $100,000:

• route optimization becomes more important,
• RFQ liquidity can matter,
• splitting becomes valuable,
• JIT liquidity may become relevant.

At $1 million:

• inventory depth,
• solver sophistication,
• private market makers,
• execution splitting,
• price impact management

can dominate the result.

Research published by Uniswap found its observed price-improvement differences became particularly pronounced in approximately the $50,000 to $200,000 trade-size range in the sample studied.

That does not prove the same result today.

It does validate the decision to benchmark by size rather than publishing one universal score.

Architecture 1: CoW Protocol

Operational status: LIVE

CoW Protocol is one of the clearest examples of solver-based decentralized execution.

Users sign intents rather than directly executing a particular AMM route.

Orders are grouped into batch auctions.

Competing solvers submit proposed settlements.

CoW describes the winner as the solver or combination of solutions producing the strongest auction outcome under the protocol’s scoring and fairness rules.

Current CoW documentation describes its solver-engine scoring broadly as:

user surplus + protocol fees − gas cost

and the system exposes solver-competition information through its API.

That is unusually useful for independent research.

Why CoW Is Especially Interesting for DN

As of the current review, CoW reports 29 active solvers settling batches.

That figure is:

PLATFORM-REPORTED

not independently verified by DN.

But the architecture offers unusually rich research possibilities.

DN can potentially investigate:

• winning solver,
• winning score,
• competing solutions,
• user surplus,
• price improvement,
• gas,
• settlement success,
• solver concentration,
• order size.

This means the future DN dataset may be able to evaluate not only:

How good is CoW?

but:

Which CoW solvers appear strongest under which market conditions?

That would be a much deeper research product.

CoW’s Solver Competition Is Not Simply “Most Solvers Wins”

This is important.

A system could have 30 solver identities but still derive most large-order execution from a small subset.

Conversely, concentration does not automatically imply worse execution.

A July 2026 academic study examining CoW Protocol found solver-market concentration increased in some dimensions after a reward-policy reform, particularly for larger orders, while average execution quality in the study did not materially change.

That suggests a useful DN principle:

Competition should be measured by outcomes, not headcount.

DN Effective Solver Competition

Rather than simply counting registered solvers, DN should measure:

Winning Solver Concentration

Share of settled volume won by each solver.

One familiar concentration measure is the Herfindahl-Hirschman Index:

HHI = Σ Solver Share²

DN can convert this into:

Effective Solver Count

Nₑ = 1 ÷ HHI

Example:

If four solvers each have 25%:

HHI:

0.25

Effective Solver Count:

4

If one solver wins almost everything:

effective competition approaches:

1

Again, this is a market-structure metric, not a direct quality score.

Architecture 2: 1inch Fusion

Operational status: LIVE

1inch Fusion uses an intent-style gasless swap architecture.

The user signs an order off-chain.

Resolvers compete to execute it.

The order’s available exchange rate evolves according to a Dutch-auction mechanism until filling becomes economically attractive to a resolver.

1inch documentation says the resolver pays blockchain gas on behalf of the user.

But this does not make gas economically irrelevant.

The auction curve itself considers variables including:

• trade volume,
• gas conditions,
• execution timing,
• preset parameters.

Gas therefore moves from:

an explicit user transaction cost

to:

part of resolver execution economics.

1inch Introduces a Different Solver Incentive

Consider a Dutch auction.

At the beginning:

the user price is highly attractive.

Few resolvers may be willing to fill.

As time passes:

the rate changes.

Eventually a resolver decides:

I can execute this order profitably at this level.

The solver faces a trade-off.

Wait longer:

potentially greater economic margin.

Wait too long:

another resolver can fill first.

This means solver quality includes:

how efficiently the resolver recognizes and captures executable opportunities.

Exclusive Resolver Competition Adds Another Layer

Current 1inch documentation also describes an Exclusive Resolver API under testing.

A resolver can provide an early quote and receive temporary execution exclusivity subject to service obligations.

The current specification identifies:

• maximum quote response time of 500ms
• an execution SLA framework of 90%

for the exclusive system.

Those are:

PLATFORM SPECIFICATIONS

not DN observations.

They nevertheless show why future intent benchmarks should measure both:

quote quality

and:

follow-through reliability.

A brilliant quote that is frequently not executed is not brilliant execution.

Architecture 3: UniswapX

Operational status: LIVE

UniswapX uses off-chain signed intents and competing fillers.

Current Uniswap material describes many orders as first being exposed to an RFQ-style opportunity, with Dutch-auction execution available if the order does not fill immediately.

In the Dutch auction:

1. the fill opportunity begins at a user-favorable rate,
2. the executable price evolves through time,
3. competing fillers decide when execution becomes attractive,
4. the first qualifying filler settles the order.

Unlike CoW’s batch structure, Uniswap emphasizes that each UniswapX Dutch auction applies to an individual swap rather than waiting for a batch.

UniswapX Creates a Valuable Counterfactual Opportunity

Uniswap’s own research framework compares auction-based execution against counterfactual routes.

That is conceptually close to the DN methodology.

The published analysis decomposed price improvement into areas such as:

• routing efficiency,
• gas optimization,
• priority-fee effects.

Its historical sample reported average price improvements of around 4 to 5 basis points for Dutch-auction OFA execution.

This is valuable methodological evidence.

But because the work comes from researchers associated with Uniswap and studies an ecosystem in which Uniswap participates, DN should not transform those historical results into a current neutral ranking.

Instead:

DN should reproduce the experiment independently.

That is how DN creates original data rather than paraphrasing another protocol’s research.

Architecture 4: Bebop JAM + RFQ

Operational status: LIVE

Bebop is particularly interesting because it combines two different execution markets.

JAM

Independent solvers compete in an auction.

PMM RFQ

Professional market makers provide private executable pricing.

Bebop Router can consider both and select between solver-driven on-chain liquidity and professional market-maker liquidity.

That creates a fascinating DN research question:

When does a solver auction beat professional RFQ liquidity, and when does the opposite occur?

Bebop’s Architecture Lets DN Test Private vs Public Liquidity

According to current documentation:

JAM liquidity

can combine on-chain and private liquidity.

PMM

uses professional market makers.

Router

selects between those execution mechanisms.

This potentially allows DN to classify individual trades by:

• solver-auction winner,
• RFQ winner,
• hybrid route.

The result could eventually produce a new DN metric:

Private Liquidity Advantage

Execution improvement attributable to RFQ/private liquidity versus the standardized public-liquidity counterfactual.

That could be particularly valuable for larger trades.

Bebop Also Makes Solver Reliability Explicit

Bebop’s solver documentation states that a solver receiving an execution request has a short period to respond and that solvers which commit to execution but fail to follow through can see their rating reduced.

It also notes that unreliable behavior can result in exclusion from quote flow.

That supports one of DN’s central propositions:

Reliability is part of price quality.

A solver that occasionally produces spectacular quotes but frequently fails to settle them should not outrank a slightly less aggressive but consistently executable solver.

Architecture Comparison

This is an architecture comparison, not a performance ranking.

The DN Solver Benchmark Test

Every standardized observation should record:

1. UTC timestamp
2. Chain
3. Sell token
4. Buy token
5. Exact input
6. USD trade size
7. Protocol/interface
8. Intent type
9. Initial displayed quote
10. Signed minimum
11. Quote timestamp
12. Signature timestamp
13. Fill timestamp
14. Settlement timestamp
15. Actual user output
16. Gas paid directly by user
17. Gas economically internalized where measurable
18. Counterfactual direct execution
19. Counterfactual gas
20. Net Solver Improvement
21. Quote surplus
22. Limit surplus
23. Solver/filler identity where available
24. Route composition
25. Fill status
26. Expiry status
27. Partial-fill status
28. Time to fill
29. Settlement failure
30. Market-volatility regime

Four Standard Trade Sizes

Every comparable venue should be tested at:

$1,000

Retail / gas-sensitive.

$10,000

Active trader.

$100,000

Professional execution.

$1,000,000

Large-order stress test where a valid intent is supported.

Again:

NO EXECUTABLE QUOTE

should be recorded as data.

It should not disappear from the sample.

Three Liquidity Cohorts

Cohort 1: Deep Majors

Examples:

ETH/USDC

ETH/USDT

Purpose:

Determine baseline solver efficiency.

Cohort 2: Liquid Altcoins

Tests routing sophistication and fragmentation.

Cohort 3: Long-Tail Assets

Tests whether solver flexibility meaningfully improves difficult execution.

A platform can perform exceptionally on ETH/USDC while being mediocre on fragmented assets.

One universal ranking would obscure this.

The DN Solver Outcome Matrix

Every trade should ultimately fall into one of several states.

Improved

Intent execution beats the counterfactual.

Neutral

Difference falls within a defined noise band.

Underperformed

Counterfactual route produced greater usable value.

Expired

Intent was never filled.

Failed

Execution attempted but did not settle successfully.

Partial

Only part of an eligible order was filled where partial fills are supported.

This lets DN publish much more meaningful statistics than average price alone.

DN Positive Improvement Rate

Another proprietary measurement:

Positive Improvement Rate

Trades with NSI > defined noise threshold ÷ completed trades

Example:

1,000 completed intents.

620 outperform by more than the minimum statistical noise threshold.

Positive Improvement Rate:

62%

This tells readers whether price improvement is:

frequent

or merely:

driven by a few very successful trades.

The Mean Can Lie

Consider two solver systems.

System A

900 trades:

0 bps improvement

100 trades:

+50 bps

Average:

+5 bps

System B

1,000 trades:

+4 bps

Average:

+4 bps

A headline says:

System A wins 5 bps vs 4 bps.

But most users experienced no improvement with A.

The distribution tells a different story.

DN should therefore publish:

• mean
• median
• positive improvement rate
• P25
• P75
• P95 adverse tail

for every meaningful cohort.

DN Execution Consistency

DN introduces:

Execution Consistency Score

A measure of dispersion around median Net Solver Improvement.

Lower dispersion means the user’s outcome is more predictable.

This matters because institutions often care about:

certainty

as much as:

maximum possible improvement.

An execution system generating:

+3 to +6 bps consistently

may be more useful for certain strategies than one producing:

−40 to +60 bps

with the same average.

Solver Quality During Volatility

Solver performance should also be separated by market regime.

Quiet Market

Low short-term volatility.

Normal Market

Representative conditions.

High Volatility

Sharp underlying price movement.

Gas Stress

Elevated network fees.

Liquidity Stress

Reduced available liquidity.

Intent systems may become more valuable precisely when normal routing becomes harder.

Or they may become less reliable because execution providers widen their economics.

Only observation can answer that.

Gasless Is Not a Free Lunch

This deserves particular emphasis.

Suppose:

Direct AMM

User output before gas:

$10,010

Gas:

$15

Net:

$9,995

Intent DEX

User output:

$10,002

User gas:

$0

The direct AMM superficially offered the better swap price.

But the intent delivered:

$7 more net value

after gas.

Now consider a $1 million transaction.

Direct execution:

$999,950

Gas:

$15

Intent:

$999,920

Now the direct route is better despite its explicit gas cost.

Therefore DN compares:

Gas-adjusted usable execution value

not marketing language such as:

“zero gas.”

DN Gas Internalization Benefit

This leads to:

Gas Internalization Benefit

Counterfactual Direct Gas Cost − Economic Gas Burden Embedded in Intent Execution

It is most important for smaller trades.

At $1,000, saving $10 of gas equals:

100 basis points

At $1 million:

$10 equals:

0.1 basis points

The same mechanism can therefore be transformative for one trade size and almost irrelevant for another.

Solver Competition Can Produce MEV Protection

CoW, 1inch and UniswapX each present their intent architectures as mechanisms designed in part to protect traders from harmful MEV or front-running dynamics.

DN should not score “MEV protection” based solely on marketing claims.

Instead we should eventually measure:

• execution relative to pre-trade reference price,
• sandwich exposure,
• unfavorable same-block price movement,
• surplus captured by the user,
• settlement path.

That can become its own future research object.

For this benchmark, MEV outcome remains an execution-quality component rather than a binary badge.

DN Intent Execution Quality Score

Once enough empirical observations exist, DN can calculate a composite score.

I recommend:

40% Net Execution Quality

Counterfactual-adjusted realized value.

20% Fill Reliability

Percentage of valid signed intents successfully executed.

15% Tail Execution Quality

P95 adverse execution outcome.

15% Time-to-Fill Quality

Median plus P95 latency.

10% Quote-to-Fill Integrity

Difference between displayed economics and actual outcome.

I would not include solver count directly in the composite.

Why?

Because solver competition is a mechanism.

User execution is the outcome.

If a protocol achieves excellent execution with five highly competitive solvers, it should not lose merely because another has twenty mediocre solvers.

DN Intent Execution Quality Score Formula

After each component is normalized to a 0 to 100 cohort score:

DN-IEQS =

0.40 × Execution Quality

0.20 × Fill Reliability

0.15 × Tail Quality

0.15 × Fill Speed

0.10 × Quote Integrity

The weighting is:

DN MODELLED

not an objective law.

The underlying raw statistics should always remain visible so readers can disregard the composite and apply their own priorities.

The Future DN Leaderboard

Once sufficiently populated:

No placeholder performance numbers should be converted into invented results.

The Even More Interesting Future Dataset: Individual Solvers

Where public information permits, DN can eventually move below protocol level.

For example:

This could become:

DN Solver League Table

Rather than merely:

CoW vs 1inch

DN could eventually ask:

Which execution agents actually produce the best user outcomes?

That is a much rarer research object.

DN Intent Solver Outcome Simulator

The proprietary tool below lets readers model a single intent outcome.

Enter:

• order value,
• displayed intent quote,
• realized user output,
• standardized alternative output,
• direct-route gas,
• intent user gas,
• fill time,
• estimated signed-intent fill reliability,
• P95 adverse outcome.

The calculator returns:

Quote Improvement

Net Solver Improvement

Gas-Adjusted Advantage

Dollar Value Created/Lost

DN Modelled Outcome Grade

It also shows how the same basis-point advantage translates to:

$1K

$10K

$100K

$1M