ERC-7683 is the cross-chain intents standard for the Ethereum ecosystem, ratified in early 2025 and now implemented by major intent-based networks including Across, UniswapX, and Eco. It defines a single struct, GaslessCrossChainOrder, that any wallet can produce and any solver can fill. The goal is to remove the per-bridge integration burden that has plagued cross-chain UX since the multichain era began in 2021.
​

The standard matters because every cross-chain protocol previously shipped its own order format, its own filler API, and its own settlement contract. A wallet wanting to support five bridges had to integrate five SDKs, maintain five fee oracles, and reconcile five different finality models. ERC-7683 collapses that into one struct and one settlement interface. The EIP itself was authored by Mark Toda and Hart Lambur, and reference implementations from Across and Uniswap shipped in Q2 2025.
​

ERC-7683 is an Ethereum standard for representing cross-chain intent orders. It defines two structs and one interface. The first struct, GaslessCrossChainOrder, contains the user's intent: input token, input amount, output token, output amount, destination chain, deadline, and a settlement contract. The second struct, ResolvedCrossChainOrder, is what the settlement contract returns after parsing the gasless order — the same data plus solver-specific fill instructions. The interface, IOriginSettler, defines two methods: open() for permitted orders and openFor() for permit2-based orders.
​

The "gasless" in GaslessCrossChainOrder means the user does not pay gas on the source chain. The user signs an EIP-712 message; a solver submits the signature on-chain and pays the gas. The user's input funds move into escrow via permit2, then to the solver after the destination delivery is verified. The full ERC text includes the ABI definitions and a reference flow diagram.
​

The standard is intentionally minimal. It does not specify how the destination chain is reached, who the solver is, or what verification primitive proves delivery. Those choices live one layer down in the implementation. The standard's job is to make the order portable: a wallet emits one struct; any compliant settler can read it.
​

The flow has four steps. First, the user constructs a GaslessCrossChainOrder in their wallet, signs it via EIP-712, and submits the signed order to a solver mempool or order book. Second, a solver reads the order, decides if the spread is profitable, and either ignores or accepts. Third, the accepting solver delivers the output on the destination chain — sending USDC to the user's address on Optimism, for example. Fourth, the destination delivery emits a verifiable event; the source-chain settlement contract reads that event via a bridge oracle (Hyperlane, LayerZero, CCIP) and releases the user's input funds to the solver.
​

The settlement contract is the trust anchor. It holds the user's input funds in escrow during the entire flow. If the solver fails to deliver by the deadline, the funds return to the user. If the solver delivers but the verification fails, the funds stay in escrow until a fallback resolution path runs — typically an arbitration window where solvers can submit additional proofs. Across documentation walks through a complete flow with code samples.
​

The orderData field inside the struct is implementation-specific. Across uses it to encode its hub-and-spoke routing. UniswapX uses it for Dutch-auction parameters. Eco uses it for solver-network selection across its 15-chain stablecoin coverage. The standard's flexibility here is what allows it to span very different protocol designs while keeping the wallet-side integration uniform.
​

The user pays gas on the source chain to open the order directly via the settlement contract's open() method. This is useful for high-value or time-sensitive orders where the user wants to skip the solver-mempool latency. The trade-off is paying source-chain gas, which on Ethereum mainnet during Q1 2026 averaged $4.20 per cross-chain order according to Etherscan's gas tracker.
​

The user signs but does not submit. The solver submits the signed order via openFor() and pays the source-chain gas. This is the default for retail flows because users hate paying gas on the source chain. The solver recovers the gas cost as part of the spread it earns on the fill. UniswapX documentation reports 94% of UniswapX volume uses the gasless variant.
​

The clearest use case is cross-chain stablecoin transfer. A user holds USDC on Base and wants USDC on Solana. With ERC-7683, the user signs one order; a solver bridges and delivers; settlement confirms within ~12 seconds median per Across's Dune dashboard. The user never sees the bridge.
​

The second use case is cross-chain swap. The user holds USDC on Arbitrum and wants ETH on Polygon. The order specifies USDC-in, ETH-out, destination Polygon. A solver bridges the USDC, swaps to ETH, and delivers. The user signs one EIP-712 message and receives a single transaction hash on Polygon.
​

The third use case is cross-chain payment routing for production teams. Apps integrating Eco Routes emit ERC-7683 orders programmatically: a SaaS platform billing in stablecoins lets the customer pay from any chain, and the order routes the funds to the platform's treasury chain. The platform integrates once and inherits cross-chain payment from every chain Eco supports.
​

For solver networks, integrating ERC-7683 means implementing the IDestinationSettler interface and the OriginSettler interface. The OriginSettler accepts user-signed orders, escrows the input funds, and emits an Open event that solvers monitor. The DestinationSettler accepts solver-submitted fills, verifies the fill against the order's specifications, and emits a Filled event that the verification primitive relays back to the source chain.
​

Solver-side integration involves three components: an order-monitoring agent (websocket subscription to the OriginSettler's Open events), a pricing engine (decides whether to fill), and a fill executor (constructs and submits the destination-chain delivery transaction). Across's contract repository includes a reference solver implementation in TypeScript; the same patterns apply to any ERC-7683-compliant network.
​

The portability benefit shows up immediately. A solver written to fill Across orders can extend to UniswapX or Eco orders by adding the relevant orderData decoders; the core monitoring, pricing, and execution logic is shared. This is what allows solver liquidity to consolidate across networks rather than fragment per protocol.
​

As of April 2026, the major intent networks have shipped ERC-7683 endpoints. Across migrated its production solver network in Q3 2025; per Across stats, ERC-7683 orders now make up 88% of total Across volume. UniswapX's V3 release in November 2025 made ERC-7683 the default order format. CoW Protocol added an ERC-7683 adapter in February 2026.
​

Wallet adoption lags behind protocol adoption, which is the typical pattern for new EVM standards. Safe, Argent, and Rabby all support emitting ERC-7683 orders as of Q1 2026. MetaMask added native support in version 12.4 (March 2026). The remaining wallet long-tail will follow throughout 2026 as the standard becomes the assumed integration target for cross-chain UX.
​

The standard does not solve verification. It assumes a verification primitive (Hyperlane, LayerZero, CCIP, Wormhole) is available between the source and destination chains; the user's funds depend on whichever bridge the settlement contract uses. L2Beat's bridge security tracker rates each verification model on its trust assumptions.
​

The standard does not standardize fee disclosure. Different settlement contracts may expose fees differently, and a wallet displaying "you will receive X" needs to query each contract individually. There is active discussion in the ERC-7683 working group about a complementary EIP for fee transparency, but no draft has been ratified as of April 2026.
​

Solver-side fragmentation remains. The standard makes orders portable, but solvers still maintain protocol-specific liquidity inventories, gas-price models, and routing logic. A solver capable of filling Across orders is not automatically capable of filling UniswapX orders, even though both use ERC-7683. Convergence at the solver layer will take longer than convergence at the standard layer.
​

ERC-7683 is not the only cross-chain standard, and understanding where it fits relative to alternatives clarifies its scope. IBC (Inter-Blockchain Communication) is the Cosmos-ecosystem standard for cross-chain message passing; it predates ERC-7683 by years and operates at a lower layer (raw message passing rather than intent expression). IBC is a verification primitive that an ERC-7683 settlement contract could use, not a competitor at the same layer.
​

ERC-3009 defined gasless transfers via signed authorizations, but only for single-chain ERC-20 movements. ERC-7683 generalizes the gasless concept to cross-chain flows. The two standards serve different problem shapes; ERC-3009 is the right primitive for single-chain stablecoin transfers, while ERC-7683 handles the cross-chain case.
​

The Solana ecosystem is developing its own intent format via SPL token-2022 extensions and the SVM-side intent execution networks. These are not interoperable with ERC-7683 at the standard level, but orchestration layers can emit the appropriate format per destination chain. Eco's API does this internally, so a team integrating Eco emits one request that becomes ERC-7683 for EVM destinations and the SVM-native format for Solana destinations.
​

Eco implements ERC-7683 across its 15-chain stablecoin orchestration network. A team integrating Eco emits a GaslessCrossChainOrder via the Eco SDK; the orchestration layer routes the order to the solver and settlement primitive best suited for the route — Hyperlane for fast EVM-to-EVM, CCTP for native USDC, alternative paths for SVM and MVM destinations. The integration is one SDK call regardless of which underlying primitive serves the route. Eco's role is the orchestration layer above the standard: ERC-7683 makes the order portable; Eco picks the right solver and settlement layer for each fill.
​

For production stablecoin teams (payments, treasury, exchange-backend), the value is consistency. The same SDK call delivers USDC to a user on Solana, USDT to a treasury on Tron, and PYUSD to a counterparty on Ethereum. The team writes one integration. The orchestration layer handles the routing.
​

For production teams building cross-chain stablecoin flows, ERC-7683 changes three things. First, integration surface area shrinks. A team that previously needed to integrate three or four bridge SDKs to cover their routes now integrates one ERC-7683 endpoint and inherits coverage across every solver network that supports the standard. Engineering work concentrates on the application logic instead of bridge-specific quirks.
​

Second, vendor lock-in decreases. Because the order format is standardized, switching from one solver network to another is a configuration change rather than a re-integration. A team unhappy with one network's spreads or fill rates can route to another without rewriting application code. This puts competitive pressure on solver networks to maintain quality.
​

Third, audit and compliance burden simplifies. Internal security reviews of cross-chain flows can focus on the standard's spec and the team's order construction logic, rather than auditing each underlying bridge's contract surface. Compliance attestations against industry standards become more meaningful when the standards are widely adopted. The ERC-7683 spec is a single document that auditors can reference across implementations.
​

No. ERC-7683 is a standard for representing cross-chain intent orders. It uses bridges underneath for verification but is not itself a bridge. A bridge moves tokens; ERC-7683 expresses what the user wants and lets a solver figure out which bridge to use.
​

As of April 2026, Across, UniswapX, CoW Protocol, and Eco have shipped production ERC-7683 endpoints. Wallet support includes Safe, Argent, Rabby, and MetaMask. The standard is now the default integration target for new cross-chain protocols.
​

The standard itself is EVM-native, but settlement contracts can verify deliveries on non-EVM chains via cross-chain message protocols. Eco uses ERC-7683 to express orders that settle on Solana and Tron via its orchestration layer, even though the standard's struct lives on the source EVM chain.
​

ERC-4337 is account abstraction — making the wallet programmable. ERC-7683 is intent expression — making the user's request portable across solvers. They compose: an AA wallet can emit ERC-7683 orders. The two cover different layers of the stack.
​

No. The settlement contract picks the verification primitive. Implementations exist using Hyperlane, LayerZero, CCIP, and Wormhole. The standard is intentionally agnostic to the underlying message-passing layer.
​