Intent Trading

Signed objective. Solver execution.

A normal swap names a path.

An intent names an outcome.

AMM routing starts from execution mechanics. Input dx moves through one or more pools and produces dy. Intent trading starts one layer above that. A trader signs constraints. A solver chooses how to satisfy them. A settlement contract checks whether the submitted execution still matches the signed constraints.

swap:    trader -> route -> pool calls -> amountOut
rfq:     trader -> maker quote -> signed order -> settlement
intent:  trader -> signed objective -> solver route -> settlement

Intent trading moves execution search away from the trader. Settlement stays constrained by a signature.

The boundary is the design. The solver does not receive custody just because an intent exists. The solver receives a right to attempt settlement under exact constraints. Token movement still requires approval, permit, or an account-level authorization, and the settlement contract enforces the signed limits.

Roles

Intent trading has three core roles.

Trader signs an objective. The objective can be exact input, exact output, a limit price, a deadline, a recipient, and a chain-specific settlement domain.

Solver searches for execution. The solver can use AMMs, RFQ liquidity, private inventory, bridges, batch matching, liquidations, or several routes at once.

Settlement contract verifies the signed objective and performs the final token movement.

The roles are not symmetric.

trader:
  define constraints
  sign intent
  approve or permit sell token
  wait for settlement
 
solver:
  search execution
  compete on output or surplus
  submit calldata
  pay gas or be reimbursed by protocol rules
 
settlement:
  recover signer
  check deadline and nonce
  pull input token
  execute solver route
  enforce minimum output
  deliver output token

The trader signs a bounded objective. The solver signs nothing in the core flow unless the protocol adds a solver-bid signature. The transaction that reaches chain is usually submitted by the solver, a relayer, or a protocol executor.

Intent

An intent is not a wish.

An intent is a signed statement with executable constraints.

sellToken: USDC
buyToken: WETH
sellAmount: 1000e6
minBuyAmount: 0.42e18
receiver: 0xTrader
deadline: 1720000000
nonce: 37
chainId: 1
settlement: 0xSettlement

This object does not say how to trade.

It says what a valid settlement must achieve.

That difference is the core of intent trading. Path choice becomes solver work. Constraint enforcement remains contract work.

Signature

Most EVM intent systems use EIP-712 for the trader intent.

The signature binds the objective to a domain.

domain:
  name
  version
  chainId
  verifyingContract
 
message:
  trader
  sellToken
  buyToken
  sellAmount
  minBuyAmount
  receiver
  deadline
  nonce

The domain matters. The same bytes must not become valid on another chain or another settlement contract.

The message matters. A solver must not be able to change the output token, receiver, deadline, or minimum received amount after the signature is collected.

A minimal Solidity shape looks like this.

struct IntentOrder {
    address trader;
    address sellToken;
    address buyToken;
    uint256 sellAmount;
    uint256 minBuyAmount;
    address receiver;
    uint256 deadline;
    uint256 nonce;
}

The actual protocol shape can be richer. It can include partial fills, fee fields, auction ids, app data, exclusive solver windows, or cross-chain data. The contract-critical fields are the fields that enter the signed hash and constrain settlement.

Authorization

The intent signature is not token approval.

It proves objective ownership. It does not by itself give the settlement contract the right to pull ERC-20 tokens.

Token authorization is separate.

path A: ERC-20 approve(settlement, amount)
path B: Permit2 permitTransferFrom(...)
path C: token-native permit(...)
path D: account abstraction validation

The common EOA flow has two signatures or one signature plus one existing approval.

intent signature:
  "This trade is acceptable under these constraints."
 
permit signature:
  "This contract may transfer this token under these limits."

Those signatures have different meaning.

The settlement contract cannot spend the trader's token only because the trader signed an intent. It can spend only if token allowance, Permit2 allowance, token-native permit, or account validation permits that movement.

Solver

The solver receives a constrained problem.

maximize:
  output to trader
 
subject to:
  sellAmount <= signed sellAmount
  buyAmount >= signed minBuyAmount
  receiver == signed receiver
  deadline not expired
  nonce unused
  token authorization valid

Many strategies can satisfy the same intent.

AMM route:
  USDC -> WETH through one or more pools
 
RFQ route:
  USDC -> maker quote -> WETH
 
Inventory route:
  solver sends WETH from inventory and later unwinds USDC
 
Batch route:
  trader A wants WETH
  trader B wants USDC
  solver nets the orders before touching pools

The solver is paid by spread, explicit fee, captured surplus, auction reward, or protocol-specific accounting.

The signed intent should make that payment model bounded. A solver may keep surplus only when the protocol rules allow it. Otherwise surplus can be returned to the trader, shared, or auctioned away through solver competition.

Settlement

Settlement is the point where off-chain search becomes on-chain state.

The contract usually performs checks in a fixed order.

1. decode order
2. verify domain-separated signature
3. check deadline
4. check nonce or fill state
5. pull sell token
6. execute solver calls
7. measure received buy token
8. require received >= minBuyAmount
9. send buy token to receiver
10. mark nonce or fill amount

The exact order can differ, but the invariant should not.

The trader's signed constraints must be true after execution.

function settle(
    IntentOrder calldata order,
    bytes calldata traderSignature,
    bytes calldata solverCalldata
) external {
    require(block.timestamp <= order.deadline, "EXPIRED");
    require(!usedNonce[order.trader][order.nonce], "NONCE_USED");
    require(_recover(order, traderSignature) == order.trader, "BAD_SIG");
 
    usedNonce[order.trader][order.nonce] = true;
 
    uint256 beforeBalance = IERC20(order.buyToken).balanceOf(order.receiver);
 
    IERC20(order.sellToken).transferFrom(
        order.trader,
        address(this),
        order.sellAmount
    );
 
    _executeSolverCalls(solverCalldata);
 
    uint256 received =
        IERC20(order.buyToken).balanceOf(order.receiver) - beforeBalance;
 
    require(received >= order.minBuyAmount, "INSUFFICIENT_OUTPUT");
}

This sketch is incomplete as production code. It shows the verification shape.

The critical part is not the route. The critical part is the post-condition.

received buy token >= signed minimum

Gas

Intent trading often moves gas payment away from the trader.

The trader signs an off-chain objective. A solver or relayer submits the on-chain transaction. This is why intent trading is often described as gasless from the trader's view.

Gasless does not mean free.

gas payer:
  solver or relayer
 
economic payer:
  spread
  fee
  worse quoted price
  protocol subsidy
  auction economics

The chain still charges gas. The question is where that cost appears in the trade economics.

Failure

An intent can fail without stealing funds.

Common failures are mechanical.

• deadline expires
• nonce is already used
• allowance is missing
• Permit2 signature is invalid
• solver route reverts
• final output is below minBuyAmount
• receiver balance check fails

The correct failure mode is revert.

No partial settlement should remain if the route cannot satisfy the signed constraints. Gas can still be spent by the transaction submitter.

Trust

The trader does not trust the solver with custody.

The trader trusts the settlement contract and the signed constraints.

That trust is narrower than trusting a hosted exchange, but it is not zero.

trusted or assumed:
  settlement contract code
  token contract behavior
  signature domain
  nonce accounting
  balance measurement
  permission scope
 
not trusted:
  solver honesty
  route quality by default
  off-chain quote persistence
  mempool behavior

Solver quality is an auction and market-design problem. Settlement safety is a contract problem.

The two should not be mixed.

RFQ Boundary

RFQ and intent trading overlap, but they are not identical.

RFQ usually asks a maker for a price.

Intent trading asks a solver network for execution that satisfies an objective.

RFQ:
  price discovery -> maker
  route search -> mostly fixed by quote
  signed object -> maker quote or order
 
Intent:
  price discovery -> solver competition
  route search -> solver responsibility
  signed object -> trader objective

An RFQ quote can be one input into an intent solver's route.

An intent can settle through RFQ liquidity.

That does not make every RFQ an intent system. The difference is where the trader's signed object sits. In RFQ, the maker's quote is the central price commitment. In intent trading, the trader's objective is the central constraint.

Boundary

Intent trading moves more work off chain.

It does not remove the need for on-chain verification.

The useful mental model is simple.

off chain:
  search
  bidding
  route construction
  batch matching
  inventory decisions
 
on chain:
  signature verification
  permission use
  nonce or fill accounting
  token movement
  final constraint check

The solver can be clever.

The contract must be boring.

That is the point.