Web3 ERC-7683 explained: the cross-chain intents standard

Every intent protocol used to describe orders in its own format, so a solver that wanted to fill orders from ten protocols had to write ten integrations. Liquidity ended up split by integration effort rather than by price. ERC-7683 is an attempt to fix that by standardising how solvers read orders, without forcing every protocol to settle them the same way.

What the current draft defines

Each protocol publishes orders as an opaque payload and points to a resolver contract. A solver calls the resolver's resolve function off-chain, through eth_call, and gets back a description of the order in common terms:

• Steps: the contract calls the solver must make, in dependency order.
• Variables: values the solver chooses (such as where it is paid) or that come from execution, queries or witnesses.
• Payments: what the solver will receive, on which chain, once the designated step has run.
• Assumptions: conditions the resolver cannot verify itself, which the solver must check before filling.
• Attributes on each step: tokens it spends, gas, timing bounds and how reverts are treated.

With that, a solver vets a resolver once and can then evaluate any order it resolves — safety, profitability and payment — without protocol-specific code.

What changed from the earlier draft

The earlier version standardised more of the order lifecycle: order structs, opening orders on-chain or through a signed gasless order, and a fill function on the destination chain. The authors replaced it because the structs still carried protocol-specific fields, its spend and receive bounds made profitable orders look unprofitable, it assumed an escrow-first design that excludes fill-first designs based on resource locks, and its large structs and events added gas. Some writing about ERC-7683 still describes the earlier version.

What it deliberately leaves out

• A common escrow, settlement contract or fill function.
• How fills are verified and how solvers are repaid.
• How prices are set, whether by auction, oracle or otherwise.
• How users authorise and create orders.

Interoperable addresses — addresses that can refer to accounts outside the EVM — come from a separate standard, EIP-7930, which ERC-7683 requires.

What it means for your product

If you run or integrate an intent protocol, exposing orders through an ERC-7683 resolver makes them readable to any solver that supports the standard, which can mean more competition and better prices on your routes. It does not make the protocol safe: the standard is explicit that security depends on the resolver, settlement contracts, assets and any cross-chain systems involved. Those still need their own design, audit and limits.