ERC-7683 Cross-Chain Intents: How Ethereum Is Standardizing Multi-Chain Settlement

Ethereum's rollup-centric roadmap created dozens of Layer 2 chains, each with its own liquidity, bridging infrastructure, and settlement assumptions. Moving tokens between them requires navigating a patchwork of bridges, each with different trust models, fee structures, and latency profiles. ERC-7683 proposes a standard for cross-chain intents: a shared interface that lets users express what they want (swap token X on chain A for token Y on chain B) and lets competing solvers figure out how to execute it. Rather than picking a bridge, the user describes an outcome. The execution details become someone else's problem.

What Is Intent-Based Cross-Chain Execution?

In the traditional model, a user interacts directly with a bridge contract: locking tokens on the source chain, waiting for a finality proof, and minting or releasing tokens on the destination. The user chooses the path, bears the execution risk, and waits for cross-chain message verification. This process can take minutes to hours depending on the bridge's security model.

Intent-based execution inverts this. The user signs an order expressing the desired outcome: “I have 1,000 USDC on Arbitrum and want 1,000 USDC on Base.” A network of solvers (also called fillers or relayers) competes to fill that order. The winning solver fronts capital on the destination chain immediately, then settles with the user's escrowed funds on the origin chain after verification. The user gets near-instant execution without choosing a bridge, managing gas on the destination chain, or understanding the underlying cross-chain messaging protocol.

Key distinction: Bridges move tokens. Intents move outcomes. A bridge is infrastructure the user must select and trust. An intent is a constraint the user publishes for any solver to satisfy.

Why Ethereum Needs a Standard

Several protocols already use intent-based models: Across, UniswapX, CoW Protocol, and others. But each defines its own order format, settlement interface, and solver registration process. A solver built for Across cannot fill UniswapX orders without a separate integration. This fragmentation limits solver competition, reduces cross-chain liquidity efficiency, and forces applications to pick a single intent protocol rather than accessing a unified solver market.

ERC-7683 addresses this by defining a common language. Any protocol that implements the standard produces orders that any ERC-7683-compatible solver can read, evaluate, and fill. Proposed in April 2024 by Mark Toda (Uniswap Labs), Matt Rice, and Nick Pai (Across Protocol), the specification went through public review on the Ethereum Magicians forum and has since attracted support from over 70 protocols and Layer 2 networks, according to the official project site.

How the ERC-7683 Specification Works

The standard defines three layers: order types that users sign, a resolution interface that translates protocol-specific data into a canonical format, and settlement contracts that handle escrow and fill verification on each chain.

Order Types

ERC-7683 supports two order submission modes. A GaslessCrossChainOrder is signed off-chain via EIP-712 and submitted by a solver on behalf of the user, meaning the user pays no origin-chain gas. An OnchainCrossChainOrder is submitted directly by the user in a standard transaction. Both contain a fillDeadline (when the order expires), an orderDataType identifier, and an opaque orderData blob carrying protocol-specific parameters like minimum output amounts or auction curves.

The Resolution Layer

The opaque orderData is where each protocol encodes its own logic: Dutch auction pricing, oracle-based rates, fixed spreads, or multi-leg routes. Solvers do not need to understand every protocol's encoding. Instead, they call the resolve() function on the origin settlement contract, which translates any order into a ResolvedCrossChainOrder: a standardized struct containing the user address, chain IDs, deadlines, and critically two arrays: maxSpent (the maximum the solver will spend filling the order) and minReceived (the minimum the user receives). A third array, fillInstructions, tells the solver which destination chain contracts to call and what data to pass.

This resolution happens off-chain via eth_call, costing no gas. The solver reads the resolved order, calculates profitability, and decides whether to fill.

Settlement Flow

The end-to-end flow works in five steps:

1. The user signs an intent (gasless) or submits a transaction (on-chain) to the IOriginSettler contract, which escrows funds and emits an Open event containing the resolved order.
2. Solvers monitor for Open events, evaluate resolved orders for profitability, and race to fill.
3. The winning solver calls fill() on the IDestinationSettler contract on the target chain, delivering tokens to the user.
4. The destination settlement contract verifies the fill and generates a settlement proof (via cross-chain messaging, optimistic verification, or other mechanisms).
5. The origin contract releases escrowed funds to the solver once settlement verification completes.

Speed vs. trust tradeoff: The solver fronts capital before settlement verification completes. Users get near-instant execution because they receive funds as soon as the solver fills. The solver absorbs the finality and settlement risk, pricing it into their fee.

The Solver Economy: Who Fills Orders and How

Solvers are the economic engine of intent-based systems. They are typically automated market-making bots or professional trading firms that maintain token inventory across multiple chains. When a solver fills an order, it fronts tokens from its own balance on the destination chain, then gets reimbursed from the user's escrowed deposit on the origin chain after settlement.

How Solvers Get Paid

Solver revenue comes from the spread between what the user deposits and what the solver delivers. If a user deposits 1,000 USDC on Arbitrum requesting 998 USDC on Base, the solver delivers 998 USDC and keeps the 2 USDC difference (plus reimbursement for destination-chain gas). The fee is embedded in the order via the gap between maxSpent and minReceived in the resolved order. Competition among solvers compresses these spreads: production data from Across Protocol showed average fees of 0.05% to 0.15% on stablecoin routes as of 2025, compared to 0.2% to 0.5% on traditional bridges.

Inventory Management

Running a solver requires capital on every chain where you fill orders. If a solver fills 100 USDC orders on Base, its Base balance drops while its Arbitrum balance grows (from settlement reimbursements). Solvers must constantly rebalance inventory across chains, using bridges, atomic swaps, or centralized exchange withdrawals. This rebalancing cost is factored into their pricing. Solvers with better inventory management and lower rebalancing costs can offer tighter spreads, creating a natural advantage for larger, more sophisticated operators.

Pricing Mechanisms

Protocols using ERC-7683 can implement different pricing strategies within the orderData field:

• Dutch auctions: the price starts high (expensive for the solver) and decreases over time until a solver fills, naturally discovering the market-clearing price
• Oracle-based pricing: orders reference on-chain price feeds and set minimum output amounts accordingly
• Fixed spreads: simple fee percentage applied to the transfer amount
• Request-for-quote (RFQ): solvers submit bids off-chain and the best price wins

How Intents Differ from Bridges

The distinction matters for application developers, users, and liquidity providers. Here is how the two approaches compare across key dimensions:

Who Is Building on ERC-7683?

The standard has moved well beyond proposal stage. Multiple production protocols route volume through ERC-7683 orders, and a growing solver network competes for fills.

Protocol Implementations

The Open Intents Framework

In February 2025, the Ethereum Foundation launched the Open Intents Framework (OIF) in collaboration with Hyperlane and Bootnode. Building on ERC-7683 as its foundation, OIF provides open-source smart contracts, solver implementations, and an SDK. The initiative attracted support from over 30 teams including Arbitrum, Optimism, Polygon, ZKsync, and Starknet, signaling broad Layer 2 alignment around intent-based interoperability.

Implications for Cross-Chain Stablecoin Transfers

The most immediate application of ERC-7683 beyond trading is stablecoin payments. Today, sending USDC from Arbitrum to Optimism requires choosing a bridge (Circle's CCTP, a third-party bridge, or a bridge aggregator), paying bridge fees, and waiting for settlement. For payment applications that need to move dollars across chains, this friction is a barrier.

With intent-based routing, a payment application can submit a single ERC-7683 order: “deliver 500 USDC to this address on Base.” The solver handles chain selection, bridging, and gas. From the application's perspective, it is a single API call with near-instant settlement. This model could simplify cross-chain stablecoin infrastructure significantly, especially for applications operating across multiple rollups.

The fee compression from solver competition also matters. Traditional bridge fees of 0.2% to 0.5% add up for high-volume payment flows. Intent-based routes averaging 0.05% to 0.15% could make cross-chain stablecoin transfers economically viable for smaller payment amounts where bridge fees previously consumed too much of the transfer value.

The Redux: Programmable Fillers

Despite production adoption, the original ERC-7683 design has known limitations. In February 2026, Francisco Giordano (OpenZeppelin) proposed a major redesign called “Redux: Programmable Fillers”, developed with contributions from Across, Uniswap, and LI.FI.

The motivation centers on four problems with the original design:

• The orderData field is opaque bytes, so solvers still need per-protocol integrations to interpret order-specific logic
• maxSpent and minReceived provide loose bounds; some protocols set UINT256_MAX, making orders appear unprofitable when they are not
• The interface assumes escrow-first design, which is incompatible with “fill-first” protocols that use resource locks
• Gas overhead from unnecessary calldata in gasless order submissions

The Redux architecture replaces the origin/destination settler model with a resolver-centric design. A new IResolver interface returns structured steps (on-chain calls the solver must execute), variables (solver-determined values like payment addresses), payments (how the solver gets compensated), and assumptions (safety requirements). This enables “programmable fillers” that can consume any protocol's orders without prior protocol-specific integration, moving closer to a truly universal solver network.

Limitations and Open Questions

Solver Centralization

While the standard is permissionless, the economics favor large solvers. Running inventory across 10+ chains, managing rebalancing, and competing on latency requires significant capital and infrastructure. If a small number of solvers dominate fill rates, the system risks recreating the centralization that fragmented bridges were supposed to avoid: just with different intermediaries. This is analogous to MEV extraction on Layer 1, where searcher competition tends to consolidate around sophisticated actors.

Settlement Verification

ERC-7683 standardizes order expression and fill interfaces but does not prescribe how settlement verification works. Each protocol still implements its own proof system: optimistic verification with challenge periods, ZK proofs, or trusted relayer attestations. This is an intentional design choice (allowing flexibility), but it means the trust model varies by protocol even when the order format is identical.

MEV and Front-Running

Intent-based systems introduce their own front-running risks. A solver that sees a pending intent can front-run the fill on the destination chain or manipulate prices on AMMs before filling. The fillDeadline and auction mechanisms help mitigate this, but the problem is not fully solved. The Redux proposal's “assumptions” field addresses some scenarios by letting orders specify conditions that must hold at fill time.

ERC Status

As of August 2026, ERC-7683 remains in Draft status on the official EIP registry. Production implementations run on the original draft specification while the Redux redesign works through the review process. This is common for Ethereum standards: ERC-20 was widely deployed before formal finalization. But it means the specification could change in ways that require existing implementations to upgrade.

What This Means for Bitcoin

ERC-7683 is a response to a problem that Ethereum created for itself. The rollup-centric roadmap shattered liquidity across dozens of execution environments, and intent-based standards are an attempt to paper over that fragmentation. As explored in our analysis of lessons Ethereum L2s offer Bitcoin scaling, cross-chain complexity compounds as the number of rollups grows. Every new L2 adds another chain for solvers to maintain inventory on, another settlement path to verify, and another source of liquidity fragmentation.

Bitcoin's Layer 2 landscape faces a version of this challenge. As more protocols launch (Lightning, Liquid, various rollups and sidechains), users could end up navigating the same multi-chain complexity. Spark takes a different approach: rather than building bridges between fragmented settlement layers, it provides a unified protocol where Bitcoin and stablecoin transfers settle on a single system with native Lightning interoperability. There is no need for solver networks or intent standards when all payments resolve within one protocol.

That said, the intent model offers a genuinely useful abstraction for ecosystems that have already fragmented. For Ethereum's rollup landscape, ERC-7683 may be the most pragmatic path to usable cross-chain payments. The question is whether the solver economy can stay competitive enough to deliver on the promise of low fees and instant execution at scale, or whether it will consolidate into another form of intermediated infrastructure.

Developers building on Bitcoin can explore Spark's SDK and documentation for an alternative approach to instant, cross-protocol settlement without the overhead of cross-chain coordination. For a broader view of how settlement models compare across blockchains, see our payment finality comparison.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.