Acrossbridge relayers fund destination fills before protocol repayment

Open fills and exclusive fills

Open fills let relayers compete for an unfilled intent, while exclusive fills temporarily reserve execution for one address. Across Protocol permits anyone to run a relayer, although each deposit's execution conditions govern which address may fill it. The RFQ, or request-for-quote, layer supplies the order and quoted economics; the relayer network supplies destination execution. Relayers discover deposits through the origin SpokePool's V3FundsDeposited event. That event records the intent, giving operators the deposited terms against which to evaluate a possible fill.

An exclusive intent identifies an exclusiveRelayer with sole fill rights until its exclusivityDeadline . Other relayers can compete after exclusivity ends, subject to the intent's fill deadline.

The separate fillDeadline limits the time available to deliver the output. Ending exclusivity opens competition; reaching the fill deadline closes the ordinary fill window. The relayer calls fillV3Relay() on the destination SpokePool. That contract records the successful fill so competitors cannot fulfill the same intent again.

Destination inventory and pooled liquidity

Relayers provide immediately available destination tokens, while liquidity providers support reimbursement on routes backed by pooled capital. The user deposits input tokens into an origin SpokePool. A relayer spends its own inventory through the destination SpokePool, which handles fulfillment. Pooled liquidity bridges the funding gap between that delivery and repayment, giving those capital sources different roles. Mainnet fills typically take about two seconds. The recipient receives funds before settlement repays the operator, whose inventory must cover the intervening capital commitment.

The HubPool on Ethereum coordinates settlement and holds liquidity-provider capital, while SpokePools handle deposits and fills on supported chains. An off-chain Dataworker reconciles the activity and assembles settlement bundles. A bundle groups valid repayment claims, avoiding a separate settlement proposal for every individual fill.

The Dataworker matches destination fill events against their origin deposit events and checks the parameters. It then groups valid repayments by chain. Root bundles also carry rebalancing instructions and slow-fill data for deposits that relayers have not filled. These instructions have different purposes from the repayment claims that reimburse relayers.

In the hub-and-spoke settlement flow, roughly 1.5 hours is the minimum interval between bundle proposals. A proposal still needs to clear its challenge period before finalization and payment execution. Disputes or settlement delays can extend the capital commitment. The proposal interval therefore does not establish a reimbursement deadline.

Repayment choices and operating costs

Relayers can request a supported repayment chain to manage inventory, subject to token-routing and address rules. UMIP-179 initially selects origin-chain repayment for Lite-chain origins or missing pool routes for the origin input token or its equivalent on the requested chain. Address validation and chain-specific fallback rules can change that selection. If no valid repayment address results, settlement omits that repayment from the refund root. The destination chain fixes where they must deliver the user's output. The repayment choice concerns where the relayer recovers its capital, which may differ from both the origin and destination chains.

Acrossbridge Relayers Fund Destination Fills

• Repayment choices and operating costs
• Does an origin deposit confirm a relayer's delivery?
• Repayment verification and capital exposure
• V4 settlement and relayer repayment

Open full-size image

The liquidity-provider, or LP, fee is zero when the relayer takes repayment on the deposit's origin chain. This repayment choice requires no cross-chain pool rebalancing. Repayment elsewhere can incur an LP fee, with pricing dependent on token, route, and pool utilization. That LP component compensates liquidity providers and sits outside the filling relayer's own compensation.

The relayer's compensation covers destination gas, the opportunity cost of committed capital, and execution risk. Destination gas varies by network, while the reimbursement delay affects the opportunity cost of committed capital. Gross fees therefore cannot establish profit without accounting for the operator's actual expenses and exposure.

The RFQ implementation uses fixed quoted fees and speed-based competition. Fresh quotes can still differ as gas prices, liquidity utilization, and market conditions change.

---

Does an origin deposit confirm a relayer's delivery?

A confirmed origin deposit establishes escrow and the intent; a destination fill record establishes relayer fulfillment. The filled status from /deposit/status reports the completed destination fill. Tracking accepts either the deposit transaction hash or the combination of originChainId and depositId .

Open full-size image

This hypothetical case assumes a transfer to a wallet, without embedded actions or partial fills. The observations are illustrative: the deposit either receives a matching destination fill or expires without one. With a matching FilledV3Relay event and filled status, the recipient can proceed using the delivered output tokens. The relayer's reimbursement may remain outstanding, because the destination fill confirms a different payment.

If the deposit stays pending before its fill deadline, continue tracking that deposit. Once the deadline passes without a fill, and no partial fill occurred, expired indicates refund eligibility. Continue tracking the refund through settlement until refunded reports its return. Expired deposits can take several hours to refund through bundle settlement. A local polling timeout establishes neither expiry nor a completed refund, so it cannot establish that those funds are available for another transfer.

Repayment verification and capital exposure

Optimistic bundle verification exposes proposed repayments to challenge before the protocol finalizes them. The Dataworker posts a bond with its proposal. During the challenge period, an observer can compare repayment and rebalancing instructions with the underlying chain activity, then dispute an invalid bundle. A proposal that nobody disputes can finalize after its challenge period.

UMA token holders resolve disputed bundle validity through the Data Verification Mechanism. The losing party forfeits its bond, with part paying oracle fees and the rest rewarding the winner. An honest actor must challenge an invalid proposal for the optimistic dispute mechanism to intervene.

Relayer software bugs, chain reorganizations, and settlement delays remain concrete sources of exposure. A reorganization can reverse a fill that had appeared confirmed, whereas delayed reimbursement can tie up operating inventory longer than expected. Bonded verification addresses the validity of settlement proposals, leaving operators responsible for their own software and capital exposure.

V4 settlement and relayer repayment

Across V4 changes settlement while preserving the relayer's destination-fill role. V3 uses chain-specific canonical-bridge adapters; V4 uses Succinct SP1 proofs of Ethereum state. SP1Helios verifies those proofs, and UniversalSpokePool executes verified settlement messages. UMA's Optimistic Oracle still verifies repayment bundles on Ethereum. After the optimistic challenge period, the Finalizer waits for Ethereum finality before requesting a proof. Proof generation and destination message execution remain prerequisites for the relayer refunds that depend on this V4 settlement path.

Open full-size image