How Across relayers front funds before finality

Across relayers can pay a recipient on the destination chain before the origin deposit has reached finality because they advance their own tokens against an observed deposit event. The transfer then passes through three stages: the user escrows funds, a relayer fills the intent, and settlement verifies the fill before arranging repayment. The user gets destination funds early; the relayer carries the waiting time and the risk that the origin transaction is reorganized.

What happens when a user initiates a transfer?

The user’s input tokens are escrowed in the origin chain’s SpokePool, which emits a deposit event containing the transfer instructions. Those instructions identify the destination chain, output token and amount, recipient, and fill deadline. The event gives relayers the data they need to decide whether to fill. For a broader comparison of transfer cost, speed, and risk, the acrossbridge explainer covers the route choice in more detail.

Escrow matters because the transfer is not atomic across chains: the destination payment cannot execute as one transaction with the origin deposit. Instead, the origin SpokePool holds the user’s tokens while the relayer acts on the deposit information. A relayer checks the parameters and the offered economics, including its destination gas cost and the time its capital may remain tied up. Some deposits also specify an exclusive relayer, which has the right to fill during the stated exclusivity period.

How does the relayer front funds before finality?

The relayer calls the destination SpokePool’s fill function and supplies its own tokens to the recipient. The destination contract records the fill, so another relayer cannot simply claim the same intent as unfilled. The recipient receives the requested output without waiting for the whole settlement cycle.

This is a short-term advance, not a completed cross-chain transfer of the user’s escrowed tokens. The relayer has converted an observed origin event into a destination payment and a later repayment claim. If the origin chain reorganizes and removes the deposit, the evidence supporting that fill may no longer be valid. The relayer bears that finality risk, along with the possibility of a software error that produces an invalid fill. Its fee compensates for the fill’s costs and risks; the amount actually repaid is calculated under protocol rules and can be reduced by the applicable liquidity-provider fee.

The advance also separates two meanings of “final.” A destination fill can be recorded and usable by the recipient while the origin deposit is still exposed to reorganization risk. Later, the settlement proposal itself must pass its verification process before repayment instructions are executed. Seeing a fill is therefore evidence that the recipient was paid, not proof that the relayer has already been reimbursed.

How does settlement verify the fill and repay the relayer?

Settlement aggregates fills across chains into a bundle, checks them against the corresponding deposits, and encodes repayment and pool-rebalancing instructions. The dataworker proposes the bundle to the HubPool on Ethereum. In the optimistic verification stage, the proposal can be challenged; a valid bundle proceeds after the challenge period, while a dispute is resolved through the protocol’s dispute process.

Once the bundle is accepted, its instructions are delivered to the relevant SpokePools, where a relayer can claim repayment using the applicable refund proof. The repayment chain can differ from both the origin and destination chains, subject to the protocol’s token and route rules. Liquidity in the HubPool and SpokePools supports this flexibility: settlement accounts for valid fills, while rebalancing instructions move capital between pools as needed.

Across V4 adds a further settlement step for chains using its ZK settlement architecture. After the optimistic bundle process, Ethereum finality is awaited for the stored settlement message; a proof of Ethereum state can then be verified on the destination chain before the message and repayment instructions are executed. That proof stage concerns settlement delivery. It does not remove the relayer’s earlier exposure to an origin-chain reorganization while fronting funds.

What can delay or prevent reimbursement?

A fill is repayable only if it matches a valid deposit and passes the bundle’s accounting checks. Validators check that the relevant chain block ranges, fill parameters, fees, and repayment instructions are consistent. If a proposed bundle contains an invalid fill or incorrect accounting, it can be disputed rather than treated as settled.

Repayment also depends on the requested chain and refund address being valid for the transfer. The system calculates the repayment token and amount under its route rules; the relayer does not necessarily receive the same token on the same chain where it paid the recipient. If no relayer fills a deposit before its deadline, the protocol can instead use liquidity-provider capital for a slow fill, or the expired deposit can become eligible for a refund under its status and bundle rules.

The mechanism makes faster delivery possible by moving the wait from the user to the relayer. A fill is the early payment; settlement is the later verification and repayment process. The open question at any given moment is not whether those are separate steps, but whether the particular deposit and fill remain valid through the checks that authorize repayment.