ERC-7683 Explained: How Cross-Chain Intent Solvers Work

ERC-7683 is an Ethereum draft that gives solver software a common way to read orders from different intent protocols. A protocol-specific payload passes through a resolver, which translates it into structured steps, variables, payment terms and assumptions; a solver can then assess whether to fulfil the order. As of 5 October 2026, the canonical proposal is still marked Draft. Crucially, ERC-7683 standardizes a solver-facing order representation—not a universal bridge, order feed, settlement contract or guarantee of cross-chain payment.

What ERC-7683 standardizes

An intent protocol lets a user express an outcome as an order: an offer of payment in exchange for specified requirements. Protocols can encode and settle those orders differently. ERC-7683 focuses on the part a solver needs to inspect them.

Component	Role in the flow
Order payload	Protocol-specific data describing the offered order. The payload can remain opaque to a solver until it is interpreted.
Resolver	A protocol-provided interface that translates the payload into a common order representation, including execution steps and relevant conditions. The draft’s EVM interface is a `view` call intended to be queried off-chain with `eth_call`.
Solver (or filler)	Software or an operator that evaluates the resolved order, checks its assumptions and decides whether it can fulfil the requirements profitably and safely.
Settlement	The protocol’s own mechanism for verifying completion and paying the solver. ERC-7683 does not prescribe one universal settlement design.

The normalized order can describe steps, variables, dependencies and payment-related instructions. It can also expose assumptions—conditions a resolver cannot verify on its own but that matter to safe execution. The resolver is therefore an interpreter and an important trust boundary, not a cryptographic certificate that every external condition will hold.

The proposal also depends on ERC-7930, which defines interoperable, chain-qualified addresses. That helps represent which chain an address belongs to; it does not validate the recipient or provide cross-chain settlement.

How a cross-chain intent order can work

Consider a hypothetical user who wants an asset on one network in exchange for an asset they hold on another. The implementation details depend on the protocol, but the solver-facing flow can be understood in five stages:

The user states the desired result. An application presents an order and the terms the user is willing to accept. How the user authorizes it is determined by the application and protocol.
The protocol creates its order payload. The order may use that protocol’s own format, order-distribution service and settlement contracts.
A solver asks the resolver to interpret it. The resolver returns a structured description of the order, such as the calls to make, dependencies, payment terms and assumptions. Solvers can query the EVM resolver off-chain rather than executing the order just to decode it.
The solver checks feasibility. It evaluates the steps and external assumptions, including the relevant chains, assets, timing and settlement conditions. A solver can decline an order that does not meet its own safety or profitability requirements.
The solver fulfils and settles under that protocol’s rules. The specific transactions and proof of completion depend on the protocol. ERC-7683 does not make the order atomic or guarantee that a solver will accept it.

This separation is the point of the standard: a solver can potentially reuse an order-reading interface across multiple protocols rather than writing a wholly bespoke decoder for every payload. It does not mean every solver can execute every order. A solver still has to vet each resolver, understand the protocol’s settlement rules and support the relevant assets and chains.

What ERC-7683 does not standardize

ERC-7683 leaves protocols room to differ in how they create and authorize orders, distribute them, price them, verify settlement and execute fills. In particular, it does not require:

one shared order feed or auction;
a universal escrow, bridge or settlement contract;
one fill function or one transaction sequence;
a common payment guarantee, finality rule or trust model.

That scope matters. Reading the same order representation is not the same as sharing the same security properties. A resolver can make an order easier for a solver to understand, but it cannot erase the risks of a token contract, an external message system, chain liveness or protocol-specific settlement.

Security checks for builders

Treat a resolver and the system around it as part of the trust model, not as a substitute for one.

Pin and review resolver deployments. Verify the chain, address, bytecode and version against the protocol’s primary documentation. Solvers may choose to vet and whitelist resolver implementations.
Inspect the resolved order before acting. Check each target, call, token, amount, recipient, chain-qualified address, dependency and deadline. A normalized description should make requirements easier to inspect, not less important to validate.
Validate assumptions that the resolver cannot prove. The draft expects solvers to assess external conditions relevant to an order. Document how your system handles chain liveness, censorship, settlement contracts, tokens and cross-chain messages.
Test changing state and failure paths. A resolution that looked safe at one moment may become unsafe before execution. Simulate the relevant steps and define what happens if a transaction, message or settlement check fails.
Keep wallet authorization separate. ERC-7683 describes an order interface for solvers; it does not replace the account or permission model that authorizes an action. For that adjacent layer, see our guide to EIP-7702 and ERC-4337.
Keep solver roles distinct from block-building roles. A solver fulfils an order; it is not automatically an Ethereum block builder or relay. Our MEV-Boost explainer covers that separate layer.
Account for the draft status. The canonical ERC-7683 page is marked Draft. Pin the exact proposal and implementation version your integration targets, and re-check for changes before relying on interoperability claims.

Frequently asked questions

Is ERC-7683 a bridge?

No. It is a draft interface for representing protocol orders to solvers. A protocol may use a bridge or other cross-chain mechanism, but ERC-7683 does not define a universal one.

Does ERC-7683 guarantee that the solver gets paid?

No. The standard does not prescribe a universal settlement mechanism. Whether a solver is paid depends on the protocol’s contracts, verification rules and other assumptions, which the solver must evaluate.

Is ERC-7683 finalized?

No. As of 5 October 2026, the canonical Ethereum proposal page lists ERC-7683 as Draft. The proposal was created on 11 April 2024; its current status should be checked directly before implementation.

Sources

ERC-7683: Cross Chain Intents — canonical proposal, resolver interface, rationale and security considerations.
ERC-7930: Interoperable Addresses — the address format required by ERC-7683.
ERC-20: Token Standard — relevant token-transfer interface background.
ERC-7683 discussion on Ethereum Magicians — discussion linked from the proposal.

If your team is evaluating a cross-chain order flow, contact SignorCrypto to scope the resolver, solver and settlement integration against your security model.