Intent-based swaps: what changes when users stop signing transactions

The conventional swap asks a user to specify a path. Which pool, which route, how much slippage to tolerate, what gas price to pay. Every one of those is a question the user is not equipped to answer, and each wrong answer costs them money — usually invisibly.

Intent-based design inverts it. The user signs a statement of outcome: give me the most USDC obtainable for this ETH, by this deadline. Specialised solvers then compete to satisfy it, and the winner is whoever produces the best result.

An intent is not a transaction

A transaction is an instruction: do exactly this. An intent is a constraint set: reach a state satisfying these conditions. The distinction matters because a constraint can be satisfied in ways the user could not have specified. A solver may route across several venues, net the order against another user going the opposite way, or fill from its own inventory. None of those are expressible as a single signed transaction.

Because the user signs constraints rather than calldata, the execution path can be decided after signing — which is precisely what makes competition possible.

The solver auction

Solvers are independent actors running their own routing, inventory and risk models. They observe the intent pool, compute what they can deliver, and bid. Whoever offers the best execution wins and settles.

Two properties follow. First, routing quality becomes a competitive market rather than a feature of the interface — a solver with better inventory or a cleverer path wins on merit. Second, coincidence of wants becomes exploitable: when two users want opposite sides of the same pair, a solver can match them directly and neither pays pool fees or slippage.

MEV as a design input

In the conventional model, a user broadcasts a transaction that publicly announces their intention, and searchers extract value by ordering around it. Sandwiching is the well-known form.

Intent-based flow removes the public announcement. The user never broadcasts an executable transaction; the solver settles a batch. Value that would have been extracted by reordering is instead competed away in the auction and returned to the user as price improvement. MEV does not disappear — it is redirected from an adversarial extraction into a competitive bid.

This is the strongest argument for the model, and it is worth stating precisely: the protection comes from the auction being competitive. A solver set that is small or collusive weakens the guarantee.

What the settlement layer has to guarantee

Handing execution to a third party only works if the user cannot be worse off than they agreed to. Three properties carry that:

• Limit enforcement at settlement. The contract verifies the outcome against the signed constraints and reverts otherwise. The solver cannot deliver less than promised.
• Deadline. An intent that cannot be filled expires rather than sitting as a standing option against the user.
• Replay and cancellation safety. A signed intent must be single-use and revocable before fill.

Get these right and the worst case is that nothing happens. That is the correct worst case.

The costs

Latency is the obvious one: an auction takes time, so intent-based fills are slower than a direct swap. For a trader chasing a moving market that is a real cost. There is also a liveness dependency — if no solver bids, nothing executes, and the user is relying on a market that may be thin for exotic pairs. And solvers are infrastructure someone has to run, which concentrates capability among participants with capital and engineering depth.

For most users, trading pairs with real liquidity, the trade is straightforwardly good. For latency-sensitive flow on thin pairs, it is not.