ERC-7683 is a cross-chain intents standard that defines two order types — GaslessCrossChainOrder and OnchainCrossChainOrder — that any solver can fill across any pair of chains. Authored by Hart Lambur (Across) and Mark Toda (Uniswap Labs) and finalized in late 2024, ERC-7683 standardizes the message format users sign when they want to move assets cross-chain, leaving the routing decision to a competitive solver network.
This article walks through the order struct, the settlement contracts, the dispute window, and how Across, Eco, LI.FI, and Uniswap implement ERC-7683 in production. It also covers the standard's relationship to ERC-7802 (cross-chain token standard) and how orchestration platforms compose ERC-7683 with messaging rails like CCTP, Hyperlane, and LayerZero.
What Is ERC-7683?
ERC-7683 defines a generic order format for cross-chain intents. An intent is a user's signed declaration of what they want done — "send 10,000 USDC from Arbitrum to Base, expire in 5 minutes" — without specifying how. A solver network competes to fill the intent: any solver can submit the order on the destination chain, deliver the assets, and claim the source-chain payment. The user signs once; the solver bears the routing complexity.
ERC-7683 grew out of two production systems. Across had been running an intent-based bridge since 2021, with Across Protocol routing more than $5 billion in cumulative volume by mid-2024 per DeFiLlama Across data. Uniswap Labs published UniswapX, an intent-based DEX, in 2023. Both teams converged on the order-struct shape and submitted it as a standard.
Adoption began in 2025. By April 2026, ERC-7683-compatible orders had crossed $2 billion in cumulative settlement, with Across, Eco, LI.FI, UniswapX, and Symbiosis as primary fillers. erc7683.org tracks the implementer registry.
How ERC-7683 Orders Work
An ERC-7683 order is an EIP-712-signed struct. The user signs an order containing source-chain inputs (what they're paying), destination-chain outputs (what they want), a settler contract address, a fill deadline, and an order data hash. The solver receives the order off-chain, simulates the fill, and decides whether to take it.
Two order types in the spec:
GaslessCrossChainOrder— the user signs an EIP-712 message; the solver submits both the source-chain "open" call and the destination-chain "fill" call. The user pays no source-chain gas.OnchainCrossChainOrder— the user submits the order on-chain themselves via anopencall. Used when the source chain doesn't support cheap signature-based flows.
The settler contract on each chain implements the IOriginSettler and IDestinationSettler interfaces. The origin settler escrows the user's source-chain inputs when the order opens. The destination settler verifies the fill and releases payment to the solver.
Settlement Flow
Concrete example: a user signs an order for 1,000 USDC on Arbitrum out, 999 USDC on Base in (the 1 USDC delta covers solver fee), 5-minute deadline.
User signs the EIP-712 message off-chain.
Solver submits
openon Arbitrum's settler, providing the user's signature. The settler verifies the signature and escrows 1,000 USDC.Solver submits
fillon Base's settler, sending 999 USDC to the user's destination address. The destination settler emits aFilledevent.An attestation oracle (Across's relayer network, Hyperlane's mailbox, or another chosen oracle) propagates the fill proof back to Arbitrum.
The Arbitrum settler verifies the fill proof and releases the escrowed 1,000 USDC to the solver.
Total elapsed time depends on the oracle. Across uses an optimistic settlement window (~30 minutes default). Hyperlane delivers proofs in minutes once the destination block finalizes. The user's experience is fast — the destination fill happens in seconds; the solver's reimbursement is what's delayed.
The Solver Network
Solvers are off-chain agents that monitor open orders, simulate profitability, and fill the orders that clear their threshold. A solver needs:
Liquidity on both source and destination chains (or rapid access to it through inventory rebalancing).
A fill engine that can submit transactions in milliseconds when an order appears.
A risk model for the dispute window — solvers fronting capital before settlement face a finality risk if the source-chain transaction reverts.
The competitive dynamic compresses the user-paid premium. Production order flow on Across in 2025 showed average fees of 0.05–0.15% on USDC routes, per Dune analytics on Across fees. The same routes through bridges that don't pool solver liquidity cost 0.2–0.5%.
Implementations
Major intent platforms implement ERC-7683 in 2026.
Across Protocol
Across, the original intent bridge, was the reference implementation for ERC-7683's order struct. Across's relayer network bids on orders, fills them on the destination chain, and reclaims source-chain inputs through Across's optimistic verification. Across intents architecture docs describe the system.
UniswapX
UniswapX is Uniswap Labs' intent-based DEX. The contracts were ERC-7683-compatible from launch. UniswapX orders cover same-chain swaps and have been extended for cross-chain. The integration with Universal Router lets users sign one ERC-7683 order that resolves to a Uniswap pool fill on the destination chain.
LI.FI
LI.FI aggregates bridges and DEXes; its solver network supports ERC-7683 orders alongside its proprietary intent format. LI.FI's solvers route through whichever underlying rail (CCTP, Hyperlane, LayerZero) gives the best fill price.
Eco
Eco's stablecoin orchestration network treats ERC-7683 as a partner standard. An ERC-7683 order targeting a stablecoin route flows through Eco's solver layer, which selects the underlying transport (CCTP for USDC, Hyperlane for non-CCTP routes, LayerZero for tokens with OFT support). The orchestration sits one layer above the intents standard — ERC-7683 defines the message; Eco picks the route.
The Dispute Window and Solver Risk
The standard does not specify how source-chain finality is verified. Implementations choose:
Optimistic verification (Across) — the solver claims the fill, a challenger window opens, and after a challenge-free period the solver is paid. Cheaper but slower.
Cryptographic proof (Hyperlane mailbox, ZK light client) — the destination chain verifies a Merkle proof of source-chain inclusion. Faster but with proof-generation cost.
Trusted attestor (Wormhole guardians, LayerZero oracle/relayer split) — a multisig or designated set of attestors signs that the source event happened. Lowest latency, highest trust assumption.
Solvers price the dispute window into the spread they charge. Faster verification reduces solver capital lockup, which compresses fees.
Limitations
ERC-7683 standardizes the order shape but leaves several pieces undefined:
Pricing. The standard does not specify how solvers compete on price (auction, first-come-first-served, batched). Each implementation handles this off-chain.
Settlement guarantee. If no solver fills the order before the deadline, the user's funds remain escrowed and they can withdraw — but the standard leaves recovery semantics to the settler implementation.
MEV protection. A signed off-chain order is visible to any solver, including MEV searchers. Some implementations route orders through private mempools to limit front-running; the standard does not prescribe this.
For the broader cross-chain standard family, see ERC-7802 (cross-chain token standard) and ERC-7811 (wallet asset discovery).
Why ERC-7683 Matters for Stablecoin Orchestration
Stablecoin teams shipping cross-chain payment, treasury, or trading flows benefit when every solver and every bridge speaks the same intent format. Eco's orchestration network treats ERC-7683 as a primary intake format: a user or treasury app signs a single order, and Eco's solver selection picks the underlying rail (CCTP, Hyperlane, LayerZero) that best fits the route. The standard handles the message shape; the orchestrator handles solver selection, liquidity, and finality. Read the stablecoin automation platforms overview and the essential ERC standards reference.
FAQ
What is the difference between ERC-7683 and a bridge?
A bridge moves assets through a fixed mechanism (lock-and-mint, burn-and-mint, or liquidity pool). ERC-7683 is a message format that lets a competitive solver network choose which bridge or rail to use. Multiple bridges can sit underneath an ERC-7683 order; the user doesn't pick the rail, the solver does.
Who pays the gas on an ERC-7683 order?
For a GaslessCrossChainOrder, the solver pays gas on both source and destination chains. The fee is built into the spread between source-chain inputs and destination-chain outputs. For an OnchainCrossChainOrder, the user pays source-chain gas to open the order; the solver pays destination-chain gas to fill.
What happens if no solver fills my order?
The order has a fill deadline. If no solver fills before the deadline, the user can call withdraw on the origin settler to reclaim their inputs. Specific recovery semantics are implementation-defined; check the settler contract's docs before submitting orders.
Is ERC-7683 the same as UniswapX?
No. UniswapX is Uniswap Labs' production intent-based DEX. ERC-7683 is the standardized order format that UniswapX, Across, and others all implement. UniswapX is one product; ERC-7683 is the protocol.
Does ERC-7683 work for non-EVM chains?
The standard is EVM-native (settlers are smart contracts, signatures are EIP-712). Solver networks can extend into non-EVM destinations through gateway contracts, but the on-chain settler interfaces are EVM-only. Cross-VM intents require a separate adapter layer.

