Across Prime

Introduction

This paper introduces Across Prime, a design for a capital efficient trustless fast bridge.

Solving interoperability for Ethereum and other blockchains requires “fast” bridging—bridges that can move assets and actions between chains at faster-than-finality speeds. Intent-based bridge designs, like what Across protocol offers today, are the leading design to solve this problem.

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. Most such bridges—like Across—use an “escrowed” model where payment is escrowed until the intent is verified as “filled”. This escrowed design introduces capital costs as relayers must wait before being repaid; relayers effectively act as short-term lenders to fill user intents.

Across Prime introduces a “bonded” model where the relayer puts down a collateralized bond to secure a particular path from an origin chain to a destination chain. This allows the user to send money directly to the relayer on the origin chain. The bonded model is significantly more capital efficient than the escrowed model while maintaining most of the security and decentralization benefits.

Mechanism

Across Prime is an evolution of the fast bridge design.

In a fast bridge, a user has some intent about what they want to happen on the destination chain (such as receiving an asset, sending an asset to someone else, or taking an action on some application). The user makes a payment on an origin chain to some third-party relayer in return for them filling that intent.

One key question in designing intent-based bridges is how to solve the problem of fair exchange. What prevents the relayer from taking the user’s payment without filling their intent?

Trusted

The simplest version of an intent-based bridge solves the fair exchange problem using a trusted relayer. This is the version implemented by applications like Relay today.

In the trusted bridge model, the user pays the relayer on the origin chain, and the relayer fulfills the intent on the destination chain.

If the relayer is honest, this model can be very efficient. However, it does not protect the user against a malicious relayer. Additionally, the need to trust the relayer makes it difficult to have multiple independent relayers, which limits competition and scalability. The trusted model may also be exposed to custodial or regulatory risks.

Escrowed

When there is some way of sending messages from the destination chain to the origin chain (a “settlement oracle”), other designs for fast bridges become possible. One is the “escrowed” model. This is the model used in Across today, as well as the design contemplated for crosschain UniswapX.

In this design, the user makes their payment not to the relayer, but into escrow on an origin chain smart contract. The relayer fills the intent on the destination chain with their own capital, then uses the oracle to prove fulfillment before user funds are released back to the relayer.

This escrow system is well described by the ERC-7683 standard for crosschain intents, where the escrow contract and settlement oracle are abstracted into a “settlement system”. The Open Intents Framework builds on this standard with reference implementations for ERC-7683 compatible relayers and modularized settlement systems.

If the oracle is slow or expensive, there is a simple “optimistic” variation of this design, where the relayer puts down a deposit, and the intent is assumed to be fulfilled unless someone challenges the fill within a certain challenge period.

In all versions of the escrowed model, the payment on the origin chain is stuck in escrow until intent fulfillment is verified, creating a capital cost for relayers. Depending on the oracle and the security assumptions of the challenge period, this may be as long as a few hours.

The bonded model is a way to reduce or eliminate this capital inefficiency.

Bonded

Across Prime introduces a different kind of trustless fast bridge: “bonded” bridging. In this model, the relayer receives the payment on the origin chain immediately. The user’s safety is guaranteed by a security deposit provided by the relayer, with the bond determining the maximum amount that the relayer can have “in flight” at any given time. If the relayer fails to complete any of the actions they were paid for, the user can claim a refund from that security deposit.

This is much more capital efficient than the escrowed model, particularly if the settlement oracle is slow.

For example, suppose a relayer has a bond of $1,000, the origin and destination chains each produce one block every two seconds, and the settlement oracle takes one hour to finalize:

Using the bonded model, users can make up to $1,000 in payments every four seconds. (As discussed below, users need to wait two blocks between payments in order to confirm that the relayer completes the desired action from the previous payment on the destination chain.) This results in a total hourly bandwidth of up to $900,000.

In the escrowed model, each payment would need to be locked up for an hour to wait for the settlement oracle to finalize, so making $900,000 in payments would require locking up a total of $900,000 in capital for one hour—making it up to 900 times less capital efficient than the bonded model (given the assumptions of this example).

The bonded model is more capital efficient since bonds are “reusable” as soon as the intent is completed on the destination chain, even if the settlement oracle takes much longer to finalize. This quality makes it practical to use much slower (and more secure or more decentralized) settlement oracles—such as the one-week canonical bridge to exit from an optimistic L2—since the capital cost is no longer proportional to the latency of the settlement oracle.

At first glance, the bonded design appears to present an unfortunate tradeoff: the relayer will only be able to support large payments if they keep a large bond locked up at all times. This suggests the design could be incompatible with a market structure where users occasionally need to send large transfers that overwhelm the relayer’s bond requirements. But we can tweak the bonded model to fix this—in the case where the bond is insufficient to cover the user’s desired payment, we can immediately add the user’s funds directly to the relayer’s bond, increasing the bond size “just-in-time”. 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.

Protocol

Here is a simple version of a bonded protocol for bridging ETH across chains (though it could easily be generalized to fulfilling arbitrary intents). It includes some important logic to handle edge cases, including “contention” (the risk that multiple users will attempt to send payments to a relayer at the same time, causing the total amount in flight to exceed the security deposit).

As the first step, suppose Bob wants to become a relayer for a particular route, where a route is defined as the path from a specific origin chain to a specific destination chain. Bob puts down some amount of ETH, securityDeposit, on the origin chain (say, Arbitrum), and specifies which destination chain they will support (say, Base).

The origin chain has a “turnstile contract,” which tracks a value, cumulativePayments, for the cumulative amount of payments made to Bob for that route, as well as a Merkle root of all intents filled through it (where each new root is keccak256(oldRoot, order)). Every time a payment is made to Bob for that route, the cumulativePayments value is incremented, the Merkle root is updated, and a payment event is emitted with the new Merkle root and new value for cumulativePayments.

The destination chain has a “fulfillment contract,” which also tracks the intents filled through the route. It has a Merkle root that corresponds to the one on the origin chain, so that when all intents on that route have been fulfilled, the Merkle roots match.

A user, Alice, wants to send ETH from Arbitrum to Base. She consults a list or API for relayers that support that path, and picks Bob. She checks Bob’s Merkle root on the destination chain, and looks at recent payment events on the origin chain until she finds a matching root, noting the cumulativePayments value from that event as confirmedCumulativePayments.

She confirms that Bob’s relayer bond is large enough to refund the payments on all currently unfulfilled intents, plus her own. She signs an ERC-7683 GaslessCrossChainOrder, with the following information in the orderData field:

• payment: the amount of ETH Alice is willing to pay to Bob (the relayer) on Arbitrum
• confirmedCumulativePayments: The value that Alice computed for the total cumulative payments that have been fulfilled. As discussed below, this number helps the turnstile contract enforce that Bob’s security deposit will be sufficient to reimburse Alice.
• destinationAmount, destinationAddress: the amount of ETH that Alice wants to receive on the destination chain, and the address she wants to receive it at. This could easily be replaced with arbitrary intents, as long as it can be enforced by the fulfillment contract.

Alice gives this intent to Bob (the relayer), who submits it to the turnstile contract on the origin chain. The turnstile contract checks that the intent is being submitted by Bob, and that securityDeposit is greater than cumulativePayments + payment - confirmedCumulativePayments. It then adds the payment amount to cumulativePayments, hashes the order into the Merkle chain, and transfers payment directly from Alice to Bob.

Bob can also specify that he wants to deposit some of the payment into his bond, instead of receiving it immediately. This could be helpful if Bob does not currently have enough in his bond to cover Alice’s payment.

The turnstile contract fires an event that includes the hash of the order, the new cumulativePayments, the destination chain ID, and the new Merkle root.

Bob now fills the user on the destination chain, passing their order through the fulfillment contract. The fulfillment contract verifies that the order has been fulfilled, hashes it, and adds it to the Merkle chain. It also fires an event noting the new Merkle root.

If Bob did not fill some intent, then after a challenge period, anyone could challenge Bob on the origin chain. Pending challenges prevent Bob from withdrawing his bond until he has proven that the order was fulfilled on the destination chain (by using the slow message bridge to prove that the Merkle roots match). If there are multiple pending challenges, whichever order was included first in the Merkle chain takes precedence.

Extensions

Arbitrary Bond Collateral

In the example given above, the payment currency is the same as the bond currency. It would be inefficient for each relayer to bond in each currency. The model can be extended to support arbitrary bond collateral provided that the user (Alice) signs off on a minimum exchange rate she’ll accept for the duration of her order. Alice’s payment amount (which locks up Bob’s bond) will then be “padded” with her conservative exchange rate, protecting Alice from changes in the relative value of her payment currency versus Bob’s bond currency during her order.

Since Alice’s order should get filled very quickly (in seconds), the actual padding required can be quite modest while still fully protecting Alice.

Multiple Destinations

In the simplified version of the bonded model described above, there is a security bond required by each relayer for each route. In the example above, Bob (the relayer) deposited a bond on Arbitrum specifically allocated to the Arbitrum→Base route. If Bob needs to deposit a bond for each and every route, the bonds required would reduce the capital efficiency of the system.

To mitigate this, each origin chain bond could be used to cover many destination chains. This puts some additional burden on the user, who now must check each destination chain in the set to verify which unfilled intents are outstanding. The user must also trust the sequencers or pre-confirmations for each destination chain. If the user prefers isolated trust assumptions, they could require the relayer to have separate bonds dedicated to each path.

Discussion

Gas Efficiency

As discussed above, the bonded model can be dramatically more capital efficient than the escrowed model. It can also offer a meaningful improvement in gas efficiency, since in the happy case, it only requires two transactions (one on the origin chain and one on the destination chain), while the escrowed model requires a third transaction on the origin chain for settlement.

ERC-7683 Compatibility

Across and Uniswap have proposed ERC-7683, a broadly supported standard for crosschain intents. This standard was authored with the escrowed intent model in mind, however it is generally compatible with Across Prime’s bonded design. Following the ERC-7683 spec, originSettler can be set to Across Prime’s turnstile contract, and destinationSettler is simply the Across Prime fulfillment contract on the destination chain. The orderData and event structures proposed by the standard remain unchanged.

Mint-and-Burn Bridge Compatibility

In the bonded model relayers receive the user’s payment on the origin chain before they must fill the user on the destination chain. This means that if the payment currency is a mint-and-burn token (like Circle’s USDC, Hyperlane’s Warp Tokens, LayerZero’s OFTs, Wormhole’s NTTs, etc), the relayer does not need to have any inventory on the destination chain to support the flow, albeit with slower fills times.

In these situations, the user could trade modestly slower fill times in exchange for cheaper fills. One example flow: (i) user publishes their intent with a longer fill time (e.g. 3 minutes) and sends mint-and-burn tokens to relayer; (ii) relayer uses the mint-and-burn bridge to move these tokens to the destination chain; (iii) after the mint-and-burn bridge completes, relayer fills user.

In this structure, Across Prime functions as a superset of all available bridging methods: if an instant fill is available (because the relayer holds inventory on the destination chain), the user will receive an instant fill; if inventory is not available, the user will receive a fill at the approximate speed and cost of the underlying mint-and-burn bridge.

Prior work

There has been much prior work on intent-based crosschain protocols, including many escrow-based designs, as well as some architectures that bear a closer resemblance to Across Prime’s bonded model.

Across

Across originated the escrowed intent design, combining it with optimizations for “batch settlement”. In Across, users deposit funds into escrow on the origin chain before relayers race to fill the user on the destination chain. Every period (approximately 1 hour), all completed fills are summarized into a Merklized bundle that “batch repays” each relayer for all refunds owed on each chain. This bundle is optimistically verified on Ethereum mainnet before funds are released. This design intelligently minimizes gas costs via batch repayments, but requires relayer capital to be locked for ~1hr, creating significant capital costs.

Orbiter Protocol

Orbiter’s design goals share some qualities that resemble Across Prime. Like Across Prime, Orbiter requires relayers (called makers) to post a bond before asking users to send funds directly to the relayer (aka maker). This bond must be larger than the funds being sent to the relayer. Orbiter’s design, however, doesn’t handle contention; the protocol cannot prevent two or more users from mistakenly sending a relayer more funds than the bond can cover. Across Prime prevents contention and enforces proper margining via the turnstile contract.

UniswapX (Crosschain)

Crosschain UniswapX is not yet implemented. It follows a similar design to Across without batch settlement. For each bridge transaction, user funds are escrowed on the origin chain; relayers then fill users on the destination chain. Funds are only released from escrow after an optimistic challenge period has passed. Across Prime bypasses the costs associated with the individual escrow and verification of each bridge transaction.

Relay Protocol

Relay protocol is currently implemented as a centralized, trusted relayer. Relay has shared designs to decentralize their implementation with a separate “settlement chain” where relayers must escrow funds before receiving deposits directly from users. This settlement chain requires individual escrow and settlement of each transaction before the relayer receives their escrowed funds. Across Prime saves on uncertainty, gas costs, complexity by sidestepping the entire need for per-transaction escrow or settlement. Users simply have to verify that a relayer is properly bonded.

Further Work

Current fast bridges often rely on escrow models, which hinder capital efficiency by locking relayer funds during settlement delays. This paper introduced Across Prime, a fast bridge design employing a "bonded" model. This bond can be reused almost immediately, decoupling capital velocity from settlement latency and vastly improving both gas and capital efficiency.

If you are interested in developing Across Prime, or working on related intent based bridge designs, reach out to this paper’s authors or the Across team.