Skip to content
DeFi Reference

Cross-chain intents and solvers

1. TL;DR

Section titled “1. TL;DR”

A cross-chain intent lets a user sign “I want X on chain B” instead of constructing the actual cross-chain transfer, outsourcing the how to a competitive market of relayers or solvers who front their own capital to fill it fast, then get reimbursed later through some settlement mechanism. The three fulfillment models — trusted, escrowed, and Paradigm’s newer bonded design (Across Prime) — trade off capital efficiency against how much you have to trust the relayer, while a separate line of research (OneBalance, Anoma) asks whether the whole account model, not just the fulfillment step, should be redesigned around signed intents instead of chain-specific transactions. Paradigm’s 2023 essay on intents remains the standard warning that outsourcing execution risks recreating the same order-flow centralization intents were meant to avoid.

2. Explain it simply

Section titled “2. Explain it simply”

Analogy

Section titled “Analogy”

Instead of driving your own car across a border yourself — waiting in line, filling out forms, converting currency along the way — you tell a trusted courier service “get 1,000 of this currency to my cousin in the next country by tonight” and pay them here. A cheap courier just takes your word and your money on faith (trusted); a more careful one has you put your payment in an escrow box that only opens once an independent inspector confirms delivery (escrowed); and the newest kind puts up their own collateral bond big enough to cover several trips at once, so they can hand you cash the moment you pay them and only settle the paperwork with the escrow box later, in bulk (bonded).

ELI5

Section titled “ELI5”

Normally, using two blockchains means doing all the technical steps yourself: send on chain A, wait, then do something on chain B. An intent instead lets you sign one message saying what you want to end up with, and pay a stranger (a solver or relayer) to make it happen using their own money first — you get your result fast, and they collect your payment afterward once they can prove they delivered. The tricky part is proving delivery without waiting a long time, since two blockchains have no fast, cheap way to check on each other, so different systems solve “trust but verify quickly” differently: assume good faith, lock the payment until proven, or put up a big deposit that gets forfeited if the solver cheats.

Step-by-step walkthrough

Section titled “Step-by-step walkthrough”

Scenario: Alice wants to move 1 ETH from Arbitrum to Base as fast as possible, using Across Prime’s bonded model. Relayer Bob has posted a security deposit of $1,000 on Arbitrum for the Arbitrum→Base route.

  1. Before (state: Alice has 1 ETH on Arbitrum, 0 on Base; Bob’s bond = $1,000, cumulative payments = $0). Bob has registered as a relayer for this route by depositing $1,000 into the route’s “turnstile contract” on Arbitrum.
  2. Alice checks Bob’s bond. She confirms on Base that Bob’s Merkle root of filled intents matches the latest payment event on Arbitrum, and that his security deposit is large enough to cover all currently unfulfilled intents plus her own payment.
  3. Alice signs and pays. She signs an ERC-7683 order specifying her payment (1 ETH-equivalent, say $3,000) and submits it to the turnstile contract, which checks that securityDeposit ≥ cumulativePayments + payment − confirmedCumulativePayments, then transfers her payment directly to Bob and updates the Merkle chain.
  4. Bob fills on Base. Bob immediately sends the equivalent ETH to Alice on Base through the fulfillment contract, which records the fill in its own Merkle chain.
  5. After (state: Alice has ~1 ETH on Base within seconds; Bob has been paid on Arbitrum and can reuse his bond as soon as the fill is proven, without waiting for any slow cross-chain message). If Bob had not filled Alice, anyone could challenge him on Arbitrum after a challenge period, freezing his bond until he proves fulfillment via the (slow) canonical bridge, or lose it.

Common misconceptions

Section titled “Common misconceptions”
  • Myth: An intent is just a fancy transaction. Reality: A transaction specifies exactly one computational path; an intent is a signed set of constraints that permits any of several computational paths a solver might choose (Konstantopoulos & Kilbourn, Paradigm, 2023-06).
  • Myth: Solvers/relayers are risk-free middlemen. Reality: In escrowed and bonded designs they front their own capital and bear settlement-latency or reorg risk; in Across’s escrowed design that capital can be locked for roughly an hour waiting for the Dataworker’s batch (Across docs, as of 2026-08).
  • Myth: More decentralized solver networks always mean less centralization risk. Reality: Chitra, Kulkarni, Pai and Diamandis show competitive solver markets can drive most solvers out and converge toward an oligopoly, cited directly in Anoma’s own intent-machine proposal (ethresear.ch/t/19109, 2024-03).
  • Myth: OneBalance and Anoma solve the same problem as Across. Reality: Across-style systems fix fulfillment (how a specific transfer gets filled fast); OneBalance redesigns the account (bundling all-chain balances into one credible-commitment account) and Anoma proposes a protocol-level intent interface usable by any network — they are complementary layers, not competitors.
  • Myth: Bonded bridging (Across Prime) requires locking as much capital as the payment volume. Reality: The bond is reused as soon as the destination fill completes, decoupling capital requirements from settlement-oracle latency — this is the whole point of the design.

If you only remember one thing

Section titled “If you only remember one thing”

An intent moves the “how” of a cross-chain transfer off the user and onto a competitive market of solvers, and every intent architecture is really a choice about how quickly and cheaply that market can prove it delivered.

3. How it works

Section titled “3. How it works”

Three fulfillment models for fast bridging

Section titled “Three fulfillment models for fast bridging”

Across Prime (Paradigm, 2025-05) frames fast cross-chain bridging as a fair-exchange problem — what stops a relayer from taking a user’s payment without filling the intent? — and lays out three answers of increasing capital efficiency:

  1. Trusted. The user pays the relayer directly on the origin chain and trusts them to fill the destination chain. Efficient if honest, but no protection against a malicious relayer, and limits how many relayers can compete (used today by Relay).
  2. Escrowed. The user’s payment sits in origin-chain escrow; the relayer fills the destination chain with their own capital, then proves fulfillment to a “settlement oracle” before escrow releases payment. This is Across’s model today and what ERC-7683 was written around. Capital cost is proportional to oracle finality time — for Across’s ~1-hour Dataworker batching, capital is tied up roughly an hour per fill.
  3. Bonded (Across Prime). The relayer posts a security deposit bounding how much they can have “in flight,” and the user pays the relayer directly rather than into escrow; if they fail to deliver, the user claims a refund from the bond. Because the bond is reused as soon as the destination fill is verified locally — independent of oracle speed — this can be up to 900x more capital-efficient than escrow when the oracle takes an hour (Paradigm, 2025-05).

Formalizing the bonded model’s capital efficiency

Section titled “Formalizing the bonded model’s capital efficiency”

Let BB be a relayer’s bond, TblockT_{\text{block}} the time between blocks, and ToracleT_{\text{oracle}} the settlement oracle’s finality time. Under the bonded model, a relayer processes up to BB roughly every 2Tblock2T_{\text{block}}, giving hourly bandwidth of about B⋅36002TblockB \cdot \frac{3600}{2T_{\text{block}}}. Under escrow, the same hourly volume requires locking B⋅Toracle1 hourB \cdot \frac{T_{\text{oracle}}}{1\text{ hour}} of capital, since each payment sits idle until finality. The efficiency ratio is approximately Toracle2Tblock\frac{T_{\text{oracle}}}{2T_{\text{block}}} — with Tblock=2sT_{\text{block}}=2\text{s} and Toracle=3600sT_{\text{oracle}}=3600\text{s}, exactly the 900x figure Across Prime derives.

Decentralizing the solver layer itself

Section titled “Decentralizing the solver layer itself”

Fast-bridge fulfillment answers “how does one relayer get paid safely,” but a separate line asks how a whole network of solvers should coordinate. An ethresear.ch proposal introduces “Abstracted Transaction Objects” (ATOs) — an intent broken into per-operation objects a solver can optimize — routed through a “driver” that broadcasts ATOs to specialist solvers, scores competing solutions by a “Degree of Expectation” (fields helping the user, e.g. bridge reputation, over fields hurting them, e.g. slippage), and accepts the highest-scoring simulated solution (ethresear.ch/t/16608, 2023-09). Its first iteration keeps a single DAO-governed “driver” as trusted coordinator, decentralization deferred — a concrete instance of the centralization-first tradeoff Paradigm’s essay warns about.

Redesigning the account, not just the fulfillment

Section titled “Redesigning the account, not just the fulfillment”

OneBalance proposes “Credible Accounts”: rather than fixing how one transfer gets filled, it wraps a user’s balances across every chain into one virtual account secured by a “credible commitment machine” (TEE, MPC, smart contract account, or future VM primitive), representing cross-chain requests as “resource locks” — a commitment to escrow state conditional on a fulfillment proof or expiry, similar to a deposit or ERC-20 approval but enforced within the account (ethresear.ch/t/19557, 2024-05). A resource lock separates fulfillment time from settlement time: a solver can deliver SOL against a locked ETH commitment at Solana speed, without waiting for Ethereum finality, since the lock itself prevents double-spending while the solver fills it.

Anoma goes a level higher, proposing itself as a universal intent interface rather than an intermediary chain: applications write intents once, and those can be “ordered, solved, and settled anywhere” — Ethereum L1, any rollup, EigenLayer AVSs, Cosmos, or Solana — with no single “Anoma chain” intents must pass through (ethresear.ch/t/19109, 2024-03). Its four claimed affordances: permissionless intent infrastructure, intent-level composability (matching intents across applications that never integrated), information flow control (who learns what, at state/matching/network level), and heterogeneous trust (independent trust assumptions per ordering, storage, and compute).

4. Worked numeric example

Section titled “4. Worked numeric example”

Continuing Alice and Bob’s Across Prime transfer from §2, compare capital efficiency against the escrowed alternative using the formula from §3, with Tblock=2sT_{\text{block}} = 2\text{s} on both Arbitrum and Base, and a settlement oracle that takes 1 hour to finalize (illustrative, matching Across Prime’s own published example):

ModelBandwidth per $1,000 bondCapital locked for $900,000/hour of volume
Bonded (Across Prime)$1,000 reusable every 4 seconds → up to $900,000/hour$1,000 (the bond itself)
Escrowed (Across today)$1,000 per hour-long fill$900,000 (locked for the full hour)

The ratio is exactly 36004=900\frac{3600}{4} = 900, matching Across Prime’s example. Bob can support far more traffic on the same route with a fixed bond, because as soon as his Base fill is confirmed locally, the same $1,000 is free to secure the next payment rather than sitting locked until Arbitrum’s settlement oracle (Across’s live Dataworker/UMA cycle runs roughly 1.5 hours, per Across docs, as of 2026-08) finalizes.

5. Where it’s used

Section titled “5. Where it’s used”

Ethereum

Section titled “Ethereum”
  • Across / Across Prime — escrowed fast bridging live today via a Hub-and-Spoke architecture (HubPool on Ethereum L1, SpokePools per chain, Dataworker batching fills roughly hourly); Across Prime is a proposed bonded upgrade from the same team. docs.across.to
  • UniswapX (crosschain) — proposed escrowed cross-chain intent design following ERC-7683, not yet implemented as of Across Prime’s writing (Paradigm, 2025-05).
  • OneBalance — Credible Accounts framework for account-level, multi-chain intent execution via resource locks; part of the CAKE Working Group’s broader chain-abstraction standards effort. ethresear.ch/t/19557
  • Anoma — universal intent-machine protocol aiming to be usable as an interface across the Ethereum ecosystem (L1, rollups, EigenLayer AVSs) and other networks. ethresear.ch/t/19109
  • CoW Protocol / batch auctions — same-chain intent settlement via solver competition; see /exchange/batch-auctions/ and /exchange/rfq-and-intents/ for the single-chain analogue of the solver-competition ideas discussed here.

Solana

Section titled “Solana”
  • Jupiter (JupiterZ / RFQ) — off-chain market-maker quote competition for swaps, conceptually a trusted-model intent system for same-chain execution; see /exchange/rfq-and-intents/.
  • deBridge (DLN) — cross-chain intent fulfillment with Solana as a first-class destination/source chain, using a validator-secured settlement layer broadly analogous to Across’s escrowed model.
  • n/a — no Solana-native bonded fast-bridge (Across Prime-style) implementation in sources. The bonded model is proposed generically over EVM chains with ERC-7683 compatibility; nothing in the fetched material describes a live Solana equivalent.
  • n/a — no Solana-specific OneBalance or Anoma deployment documented in sources, though both frameworks are explicitly designed to be chain-agnostic and name Solana as a target ecosystem.

6. Risks, attacks, and incidents

Section titled “6. Risks, attacks, and incidents”
  • Order-flow centralization. Paradigm’s warning: if intent execution is permissioned carelessly, migration from the public mempool “threatens to centralise block production on Ethereum,” since a builder with exclusive order flow gains a moat against competition (Konstantopoulos & Kilbourn, 2023-06).
  • Trust-based barriers to entry. A monopolist executor can extract rents and deny traction to any new intent format it doesn’t adopt, entrenching incumbents over new entrants (same source).
  • Opacity. Intent applications surrendering more execution freedom than plain transactions need proportionally more caution, since an intent that “materialises as a transaction with no clarity on how or by whom it was created” is the essay’s worst-case failure mode.
  • Reorg griefing in resource-lock/voucher systems. OneBalance- and EIL-style designs (see /cross-chain/cross-l2-interop/) note a source-chain reorg after a solver fills the destination side can let a user attempt to “steal” a fill; mitigations trade away some latency.
  • Solver-market oligopoly. Anoma’s proposal cites Chitra, Kulkarni, Pai and Diamandis (2024) showing competitive solver markets can still converge to oligopoly without protocol-level permissioning — permissionless infrastructure alone “does not change the mechanism design landscape” (ethresear.ch/t/19109, 2024-03).

7. Open problems

Section titled “7. Open problems”
  • Fee model for permissionless solving. The decentralized-solver thread leaves the reward mechanism unresolved, citing SUAVE-style auctions as inspiration but “still iterating on incentive model” (ethresear.ch/t/16608, 2023-09).
  • Cross-chain account validation heterogeneity. OneBalance’s Credible Accounts must migrate between candidate “credible commitment machine” architectures as the field matures — today’s best is expected to look “vastly different” in five years.
  • Solver decentralization sequencing. Both the ATO/driver proposal and Anoma treat fully permissionless, non-oligopolistic solving as an aspiration rather than a solved mechanism.
  • Whether bonded and escrowed models converge. Across Prime notes its design “could easily be generalized to fulfilling arbitrary intents,” but whether general-purpose systems (UniswapX-style) adopt bonding over escrow remains unresolved (Paradigm, 2025-05).

8. Ethereum vs Solana

Section titled “8. Ethereum vs Solana”
AspectEthereumSolana
Dominant fast-bridge modelEscrowed live (Across), bonded proposed (Across Prime)deBridge-style validator settlement; no bonded model documented
StandardizationERC-7683 for crosschain intents, adopted by Across/UniswapXNo equivalent cross-chain intent standard in sources
Solver-network decentralization researchActive (ATO/driver proposal, Anoma, OneBalance)Not documented as Solana-specific in sources
Settlement latency driving capital cost~1.5 hr Dataworker/UMA cycle (Across, as of 2026-08)Sub-second finality reduces the escrow-latency problem the bonded model targets

Solana’s fast finality means much of the capital-efficiency problem Across Prime solves for Ethereum-side settlement is naturally smaller when Solana is the destination chain — a relayer filling on Solana can often confirm quickly regardless of fulfillment model. The harder problem, per these sources, remains symmetric: whichever chain hosts the slow settlement oracle (typically an Ethereum-anchored one) still determines how long capital is locked in an escrowed design.

9. Reference doc

Section titled “9. Reference doc”

The reference

Section titled “The reference”

Across Prime — Hart Lambur, Matt Rice, Dan Robinson (Paradigm), 6 May 2025. paradigm.xyz/writing/across-prime

Summary of the reference

Section titled “Summary of the reference”

The paper frames fast cross-chain bridging as a fair-exchange problem: a relayer fronts capital to fill a user’s intent on the destination chain in exchange for payment on the origin chain, and the central design question is what stops the relayer from taking payment without filling. It reviews the trusted model (used by Relay today, efficient but no protection against a dishonest relayer) and the escrowed model (used by Across today and assumed by ERC-7683, where payment sits in origin-chain escrow until a settlement oracle proves fulfillment), noting that escrow capital cost scales directly with settlement-oracle latency — “as long as a few hours” depending on the oracle and challenge period.

Across Prime’s bonded model instead lets the relayer receive payment immediately, protected only by a security deposit sized to bound how much the relayer can have “in flight.” The paper walks through a protocol built on a per-route “turnstile contract” (tracking cumulative payments and a Merkle chain of filled intents) and a matching “fulfillment contract” on the destination chain, with a worked numeric example showing the bonded model can be up to 900x more capital-efficient than escrow when the settlement oracle takes an hour. Extensions cover arbitrary bond collateral (padding for exchange-rate risk since the bond currency may differ from the payment currency), multi-destination bonds (trading isolated trust assumptions for capital efficiency across routes), and compatibility with mint-and-burn bridges like CCTP, Wormhole NTT, or LayerZero OFTs, where a relayer can skip holding destination-chain inventory entirely at the cost of slightly slower fills.

The paper closes with a prior-work comparison against Across’s own escrowed design, Orbiter Protocol (a similar bonded idea that doesn’t handle “contention” — multiple users draining a bond simultaneously — the way Across Prime’s turnstile contract does), crosschain UniswapX (escrowed, not yet implemented at time of writing), and Relay Protocol (currently centralized, with a proposed decentralized settlement-chain design that still requires per-transaction escrow, unlike Across Prime).

Key quotes

Section titled “Key quotes”

“Fast bridges depend on third party relayers (aka solvers) to fill a user’s ‘intent’ on a destination chain in exchange for a payment on the origin chain.” (Introduction)

“The bonded model is a way to reduce or eliminate this capital inefficiency.” (Escrowed section, transitioning to Bonded)

“This tweak essentially allows the bonded model to ‘fall back’ to the escrowed design when the bond is not large enough, but with an added bonus: the escrow ‘bond’ can immediately be reused to secure payments of other users.” (Mechanism)

“Across Prime saves on uncertainty, gas costs, complexity by sidestepping the entire need for per-transaction escrow or settlement.” (Prior work, Relay Protocol comparison)

How to read the original

Section titled “How to read the original”

Background needed: what ERC-7683 standardizes (origin/destination “settlers,” order data), and the general shape of an optimistic-oracle challenge period (used elsewhere for escrow verification). Skip the fully worked Solidity-flavored protocol walkthrough (the “Bob and Alice” turnstile-contract mechanics) on a first pass if you just want the capital-efficiency argument — the numeric example under “Bonded” alone conveys the core result. The hardest part is the “Multiple Destinations” extension: it’s easy to miss that pooling one bond across many destination chains genuinely reduces total capital locked, but does so by making the user responsible for checking every destination chain in the pooled set for outstanding unfilled intents before trusting the relayer’s remaining capacity — read it as a capital-efficiency-vs-verification-burden tradeoff, not a free lunch.

What changed since

Section titled “What changed since”
  • Across’s live production system (as of 2026-08, per docs.across.to) still runs the escrowed Hub-and-Spoke model with roughly 1.5-hour Dataworker batching; Across Prime’s bonded design was proposed but its live deployment status is not established in these sources.
  • The Ethereum Interop Layer (EIL, 2025-11) proposes a structurally similar “voucher” mechanism — cross-chain liquidity providers front funds against a fee-bearing voucher redeemed atomically — independently arriving at a bonded-like design for account-level interop rather than bridge-level fulfillment; see /cross-chain/cross-l2-interop/.
  • ERC-7683 adoption (Across, UniswapX, the Open Intents Framework) has continued to standardize the escrowed model that Across Prime explicitly targets as a capital-efficiency upgrade rather than a replacement.

Secondary references

Section titled “Secondary references”
  1. Konstantopoulos & Kilbourn, “Intent-Based Architectures and Their Risks” (Paradigm, 2023-06) — read first if you want the centralization/trust/opacity risk framework this page’s §6 and §7 draw on.
  2. rishotics et al., “A decentralised solver architecture for executing intents on EVM blockchain” (ethresear.ch, 2023-09) — read if you want a concrete (if early-stage) solver-network mechanism with a scoring formula.
  3. thegostep & ankitchiplunkar, “Introducing OneBalance” (ethresear.ch, 2024-05) — read if you want the account-redesign angle (resource locks, credible commitment machines) rather than the fulfillment-layer angle.
  4. cwgoes, “[RFC] Anoma as the universal intent machine for Ethereum” (ethresear.ch, 2024-03) — read if you want the most protocol-agnostic, highest-altitude framing of what an intent standard could look like.

10. Sources

Section titled “10. Sources”