Intents, Solvers, and Cross-Chain Execution (ERC-7683)

Summary

Intent-based trading replaces “submit a transaction” with “declare what you want” — users specify desired outcomes (e.g., “get at least X tokens for Y input”) and solvers compete to fulfill the intent at the best price. ERC-7683 (Cross-Chain Intents) standardizes this across chains. The 2026 “Redux” revision adds a programmable filler architecture (resolver interface) that fixes four fundamental problems in the original ERC design.

Intent Model vs. Transaction Model

Model	User specifies	Solver/executor does	MEV exposure
Transaction	Exact execution path (contract, calldata, gas)	Nothing; user executes directly	High (sandwich, frontrun)
Intent	Desired outcome (min output, max slippage)	Find the best execution path	Low (solver competes)

Intent benefits:

Better execution: solvers access off-chain liquidity, CEX, and multiple on-chain venues
MEV protection: solver bundles prevent frontrunning (user tx is not visible in public mempool alone)
Cross-chain: intents can be filled on a different chain than where the user has assets
Gas abstraction: solver pays gas, charges user from output token

Intent tradeoffs:

Trust: user must trust that the solver won’t manipulate execution
Quote staleness: the quote shown may not match actual execution
Solver centralization: top solvers dominate → concentration risk

ERC-7683: Cross-Chain Intents

Original ERC-7683 defined a standard for cross-chain intent fulfillment. The 2026 Redux revision adds a Programmable Filler (resolver interface) to address four problems:

Four Problems with Original ERC-7683

Static routing: fillers could only fill at predetermined venues; no dynamic path optimization
No conditional execution: fillers couldn’t execute multiple steps or handle execution conditions
Incomplete ordering: filler selection was opaque; no mechanism for fair competition
No programmability: applications couldn’t express custom execution logic

Redux Architecture: Resolver Interface

interface IResolver {
    function resolve(
        ResolvedOrder order,
        bytes calldata resolveData
    ) external returns (FillData);
}

struct ResolvedOrder {
    Steps[] steps;         // Ordered execution steps
    Variables[] vars;      // Parameterized values (price, slippage)
    Payments[] payments;   // Token flows (input, output, fees)
    Assumptions[] assums;  // Conditions that must hold (oracle check, time)
}

Steps: ordered execution actions (swap on Uniswap, bridge to L2, deposit to Aave, …)
Variables: parameterized values that can be filled dynamically (e.g., current oracle price)
Payments: input tokens, output tokens, fee distributions
Assumptions: conditions the solver verifies before filling (oracle price within range, deadline not exceeded)

How Redux Fixes the Problems

Dynamic routing: solver specifies execution steps at fill time → can route to any venue
Conditional execution: Assumptions allow solvers to abort if conditions aren’t met → no bad fills
Fair competition: standardized ResolvedOrder format enables comparison across solvers
Programmability: arbitrary Steps sequences enable complex multi-step intents

Solver Competition and Execution Quality

The $50M UI Lie case study (Mar 2026) revealed a critical failure mode in solver systems:

What happened:

Aave’s UI displayed an optimal swap quote (~1 bps slippage)
CoW Protocol’s solver was selected to execute
Between quote display and execution, the solver updated routing
The solver routed to a microscopic Sushi pool with much worse execution
The displayed quote bore no relation to actual execution

Root cause: Quote display and solver execution are decoupled. Solvers update routing right before submission; the UI shows a stale quote.

Implications:

“Best quote” displays are meaningless without real-time execution price guarantees
Solver selection criteria matter enormously — market share doesn’t equal quality
Users need on-chain enforceable execution guarantees, not just displayed quotes

Enforcing Execution Quality

ERC-7683’s Assumptions field enables this:

Assumptions = [
    {type: "oracle_price", asset: "ETH/USDC", min: 1990, max: 2010},
    {type: "deadline", timestamp: block.timestamp + 30},
    {type: "slippage", max_bps: 10}
]

If any assumption is violated at fill time, the solver cannot fill. This creates an on-chain commitment to execution quality.

CoW Protocol Architecture

CoW Protocol implements batch auctions as an alternative to continuous orderbook:

Users submit intents with minimum acceptable output
CoW Protocol collects intents for ~30 seconds
Solvers compete to fill the batch (off-chain CoW matching + on-chain settlement)
The winning solver provides a full solution for the entire batch at uniform prices
On-chain verifier checks the solution is valid before settling

Benefits:

Uniform clearing prices (no ordering advantage)
CoW (Coincidence of Wants) matching reduces slippage for opposing orders
Solver competition ensures best execution

Limitation: 30-second batch window is slow for time-sensitive trades.

Cross-Chain Execution Flow (ERC-7683)

User (Chain A) → signs Intent → Lock origin tokens
                                      ↓
                          Solver broadcasts intent to fillers
                                      ↓
                          Filler on Chain B executes → sends output to user
                                      ↓
                          Filler proves fill on-chain → claims locked tokens
                                      ↓
                          Origin contract releases tokens to filler

The relay mechanism (Oracle, Optimism, etc.) verifies the fill on Chain B and unlocks tokens on Chain A. ERC-7683 standardizes this flow across all chains.

Open Questions

Can the Assumptions mechanism fully prevent quote staleness, or can solvers still manipulate timing?
How do intent solvers interact with encrypted mempools? (Solver needs to construct the transaction; if the user’s intent is encrypted, the solver can’t see it)
Should solver selection be a competitive auction (first-price bid on quality metrics) or a reputation-based system?
How do solvers handle MEV opportunities within the execution of an intent? (A solver routing a large trade might capture MEV from intermediate steps)

Private Order Flow and OFA Mechanisms — OFA vs. intent-based routing
Sandwich Attacks — Intent systems protect against sandwich attacks
Ethereum Economic Zone (EEZ) and Cross-Chain Composability — EEZ and cross-chain composability

Key Sources

ERC-7683 Redux: Programmable Fillers (Feb 2026) — resolver interface; four problems; ResolvedOrder format
The $50M UI Lie (Mar 2026) — code-level analysis; quote staleness; solver routing failure