That can sound counterintuitive if you’ve spent time optimizing quotes, modelling slippage, or competing on spread. In practice, though, a meaningful portion of solver PnL is determined after the quote is already won. The difference between a profitable fill and a marginal (or negative) one is often hidden in how that transaction gets executed onchain.

Even today at sub gwei base fee a typical Ethereum mainnet fill might cost ~$0.03–$0.20 in gas. At scale, that isn’t noise. It is your margin.

And yet, most execution systems today are still treated as an afterthought.

For most intent-based systems the lifecycle is broadly similar:

1. A user expresses an intent (swap, bridge, etc.)

2. Solvers generate quotes based on their internal pricing models

3. A winning solver is selected

4. The solver executes the transaction onchain

The industry has spent the majority of its energy on step (2): pricing.

• Better routing algorithms

• Faster quote generation

• More accurate slippage modelling

• Inventory-aware pricing

But once a solver wins, execution is typically handled in a much more fragmented way:

• Each solver constructs and submits its own transactions

• Gas bidding is done independently

• Calldata is often unoptimized

• Routing decisions are made locally, not globally

• Inclusion is left to public mempools or private RPCs with revert protection

This works, but it is far from efficient.

Execution inefficiency is easy to miss because it doesn’t show up in the quote. It shows up in realized PnL.

Two solvers can quote the same price, win the same intents, and still end up with very different outcomes purely due to execution.

The gap comes from a collection of small inefficiencies:

• Slightly higher gas usage per transaction

• Redundant calldata across fills

• Suboptimal routing paths

• Poor inclusion timing

• Occasional reverts

Individually, each might look negligible. Together, they compound.

A rough rule of thumb we’ve seen in production systems:

~10% of execution cost is structurally wasted.

Not because of bad engineering, but because the system itself isn’t designed to optimize execution globally.

Most solver transactions are constructed in isolation.

• No batching across fills

• No shared state reuse

• No amortization of fixed costs

If you’re submitting 10 independent fills, you’re paying 10 times for base costs that could be shared.

Even small savings—10k–20k gas per transaction—add up quickly at scale.

Calldata is often the most overlooked cost center.

• Repeated parameters across transactions

• Verbose encoding patterns

• No compression or aggregation

On mainnet, calldata is not cheap. At high throughput, reducing calldata by even a few dozen bytes per transaction translates directly into margin.

Routing decisions are typically made per intent.

But in reality, many fills share overlapping paths:

• Same token pairs

• Same liquidity sources

• Same intermediate assets

Without aggregation, you end up:

• Hitting the same pools multiple times

• Incurring redundant price impact

• Paying repeated routing overhead

A globally optimized system would recognize these overlaps and co-route them.

Inclusion is not just about getting a transaction mined. It is about when and how.

Common issues:

• Overpaying for gas to guarantee inclusion

• Underbidding and missing profitable windows

• Competing with your own transactions

• Exposure to mempool latency and reordering

Many solvers treat inclusion as a binary problem. In reality, it is an optimization surface.

Reverts are often dismissed as edge cases. They’re not.

They come from:

• State changes between quote and execution

• Fragile routing assumptions

• Race conditions with other solvers

Each revert is a direct cost:

• Lost gas

• Lost opportunity

• Potential penalties (depending on protocol design)

Reducing revert rates even slightly can have an outsized impact on profitability.

Execution inefficiency doesn’t just affect solvers. It propagates through the entire system.

For solvers:

• Lower margins

• Higher variance in outcomes

• Reduced competitiveness in auctions

For users:

• Worse pricing (inefficiencies get priced in)

• Lower reliability (failed or delayed fills)

For protocols:

• Reduced solver participation

• Less competitive auctions

• Worse UX and retention

Thesis:

Execution quality, not liquidity, is becoming the primary differentiator in intent-based systems.

Liquidity is increasingly commoditized. Execution is not.

The core issue is that execution today is decentralized at the wrong layer.

Each solver optimizes locally, but no one optimizes globally.

Aggregation changes that.

Instead of treating each fill as an independent transaction, you treat execution as a shared problem:

• Batch multiple fills into fewer transactions

• Deduplicate calldata

• Co-optimize routing across intents

• Manage gas bidding at the aggregate level

• Coordinate inclusion strategy

This is not just about cost reduction. It is about system design.

A well-aggregated execution layer can:

• Reduce per-fill gas costs

• Improve inclusion consistency

• Lower revert rates

• Enable more sophisticated routing strategies

And importantly, it allows solvers to focus on what they’re actually differentiated in: pricing and inventory management.

Consider 10 fills targeting similar token pairs within the same block.

Without aggregation:

• 10 separate transactions

• 10x base gas costs

• Repeated calldata

• Independent routing decisions

• Potential self-competition in the mempool

With aggregation:

• Fewer bundled transactions

• Shared execution paths

• Compressed calldata

• Coordinated inclusion

• Reduced contention

Even a modest improvement, say $0.01 saved per fill, scales to meaningful numbers quickly.

At 5k fills/day, that’s $50/day in recovered margin.

This is the layer Spire is focused on: transaction aggregation and execution infrastructure.

Not another solver. Not another quoting system.

A shared execution layer that sits downstream of solvers and optimizes how transactions actually hit the chain.

In practice, this means:

• Aggregating fills across solvers

• Reducing gas and calldata overhead

• We’re seeing ~10% savings in production today, in a bear market!

• Improving inclusion quality

• Zero reverts

We’re already working with relayers in systems like Across, where execution quality directly impacts both solver profitability and user outcomes.

The goal isn’t to replace solvers. It is to make them more efficient.

As intent-based systems expand and cross-chain execution becomes solver-driven, the pressure on execution will increase.

A few trends are already clear:

• More competition on thin margins → execution efficiency becomes decisive

• Higher throughput systems → inefficiencies compound faster

• Cross-chain complexity → execution reliability becomes harder

• Protocol-level auctions → solvers need consistent, predictable outcomes

In that world, the current model, independent, uncoordinated execution doesn’t scale.

We’re likely moving toward a separation of concerns:

• Solvers specialize in pricing and capital efficiency

• Execution layers specialize in aggregation, routing, and inclusion

The same way block builders emerged to optimize block construction, execution infrastructure will emerge to optimize solver transactions.

And the solvers that adopt it early will have a structural advantage, not because they quote better, but because they execute better.

That’s where the next 10% comes from.