ERC-7683 in 2026: how cross-chain resolvers and solvers work

An operation across blockchain networks requires coordinating actions executed in different systems. In intent-based models, users express the result they want and other participants execute the order under its conditions. ERC-7683 aims to help those systems share an understandable representation of orders.

The specification remains in Draft status and uses an architecture centered on resolvers, contracts that interpret orders, unlike the initial rigid-interface model from 2024. That evolution matters when comparing implementations: a common representation can facilitate integration, but the application still needs to explain execution and the conditions for completing each operation.

Why orders need a common representation

An intent states the outcome a user wants, such as delivering one asset on an origin chain and receiving another on a different network,without prescribing every execution step. The problem is that each protocol encodes the order, its constraints and its payments differently. A solver would need a custom integration to discover and price every market.

ERC-7683 places a translation layer between both sides. The original order may be an opaque, protocol-specific payload. A resolver interprets it and returns a common representation that other systems can query without knowing every detail of that private format in advance.

A resolver and a solver are not the same

The resolver is the adapter: it transforms the order into normalized steps, variables and payments. The solver is the economic actor that analyzes that output, estimates costs and risks, and decides whether it can complete execution profitably. Separating the roles lets a protocol keep its own logic while exposing opportunities to a broader set of executors.

The common representation describes which actions must occur, which values may vary and which payments compensate the executor. Interoperable addresses rely on ERC-7930 to identify accounts or assets beyond a single chain's address format.

A simplified order flow

First, the user signs or submits an order to the origin protocol. Second, a resolver decodes that payload and returns the common representation through a query. Third, one or more solvers compare the opportunity with their liquidity, inventory, latency and cost of capital. Finally, the selected solver performs the steps, and the protocol's mechanism verifies the result before releasing payment.

What it standardizes and what it leaves out

The proposal standardizes how an opportunity is resolved and presented to solvers. By itself it does not define a universal bridge, messaging system, liquidity network or single dispute mechanism. Two compatible implementations can offer very different guarantees because their security depends on how they verify and settle execution.

Integration risks and decisions

A team should pin the exact draft version, audit the resolver, validate that payments and variables are unambiguous, constrain replay and expiry conditions, and study what happens if one part of the operation executes while another fails. It should also assess solver concentration: an open format improves access, but does not create competition or liquidity by itself.

An example for assessing solver assumptions

Suppose an order requires delivery of an asset on another network before a deadline, followed by payment to the solver. The destination address is insufficient: the solver needs to know which evidence unlocks payment, when it is sufficient and what could prevent payment after capital has been committed.

In the draft’s architecture, the EVM resolver can be queried through eth_call. Its response includes instructions and assumptions for the solver to evaluate. The query does not execute the order or guarantee that external dependencies retain their observed state.

Technical review should exercise expiry during execution, permission changes and execution evidence rejected by the settlement system. The aim is to locate committed capital and establish the procedure for completing or closing the operation. A common representation makes instructions easier to read; safety depends on those instructions and their assumptions being correct.

Why it may matter while still Draft

ERC-7683's thesis is that interoperability does not require every protocol to share one internal logic. It can standardize the meeting point where executors read and compare orders. If the draft converges and gains adoption, it reduces the cost of integrating new intent markets; until then, teams should treat it as an evolving interface rather than a guarantee of final compatibility.