Cross-chain relayers fill first and settle later

A cross-chain relayer makes a transfer feel fast by paying the recipient on the destination chain before it has collected the sender’s funds on the origin chain. The user’s deposit and the relayer’s fill are separate transactions on separate chains; a later settlement process checks that they match and reimburses the relayer. Across V3 is a useful example of this design, but contract names and reimbursement rules differ across protocols.

The timing split matters: a fast fill means the recipient has received funds, not that the relayer has been repaid or that every settlement step is final. Treasury operators comparing chain transfers may also need the separate account of QuickSwap treasury transfers, which covers that protocol’s treasury mechanics.

What does a cross-chain relayer do?

A relayer observes a user’s origin-chain deposit, checks its terms, then submits a fill transaction on the destination chain using its own inventory. In Across V3, the user deposits through the origin SpokePool, which emits a V3FundsDeposited event. A relayer monitors that event and calls fillV3Relay() on the destination SpokePool. The destination contract transfers the specified output to the recipient and records a FilledV3Relay event.

The deposit is the funding evidence; the fill is the delivery. The relayer bridges no message that instructs the destination contract to wait for the origin-chain transaction to complete before paying out. Instead, it takes the timing and inventory risk itself. That is why the user can receive the output before the protocol’s accounting has reimbursed the relayer.

A fill must satisfy the intent’s terms: destination chain, recipient, token and amount requirements, and its deadline. An intent may also name an exclusiveRelayer and an exclusivityDeadline. During that period, only the named relayer may fill; after it ends, other relayers can compete. This shapes who may act, but does not remove the requirement that the fill match the deposit.

How does a fast fill become a settled payment?

In Across V3, the off-chain Dataworker gathers deposit and fill events across supported chains, matches fills to deposits, and builds a root bundle. The bundle contains Merkle roots for relayer refunds, token rebalancing and slow fills, plus the block ranges the dataworker processed. A proposal goes to the HubPool on Ethereum with a bond, then enters a challenge period. If it is not disputed, the bundle can be finalized and its instructions executed.

The relayer’s refund is an accounting result of that process, not an automatic consequence of the destination transaction. The dataworker derives payment instructions from valid fills, and the relevant chain contracts execute those instructions after settlement. In V3, the relayer can specify a repayment chain through repaymentChainId; it need not always be the origin chain. The repayment choice affects the pool’s rebalancing needs and can affect the LP fee calculation.

This batching separates user latency from settlement latency. The fill can complete quickly because the relayer has local destination inventory. Reimbursement waits for aggregation, proposal, the challenge window and execution. That delay lets the system check many fills together rather than requiring an origin-to-destination bridge transfer to finish for every user before delivery.

What can fail between the fill and reimbursement?

A destination fill can succeed while later settlement takes longer or requires scrutiny. The bundle must include a valid fill that corresponds to a real deposit, with matching parameters and no duplicate accounting. Validators can reconstruct the expected bundle from on-chain events. If the proposed roots or block ranges are wrong, a challenger can dispute the proposal under the protocol’s optimistic verification process.

There are also failures before a fill. A relayer may not act before the fill deadline, may lack inventory on the destination chain, or may reject an order whose fees do not cover gas, capital costs and risk. If no relayer fills an Across V3 deposit, the system can include a slow-fill instruction in settlement. If the deadline expires without a fill, refund eligibility depends on the protocol’s rules and status; “pending” and “filled” describe user delivery, not relayer repayment.

• Pending: the deposit is recorded, but no relayer fill has been observed.
• Filled: a destination-chain fill has delivered the output; the refund may still be unsettled.
• Expired: the fill deadline passed without a fill, making the deposit eligible for the protocol’s refund path.
• Refunded: the refund transaction has completed.

These states are specific to the cited Across tracking model; other protocols expose different status names and recovery paths. For an integrator, the practical distinction is to track the destination fill separately from settlement and refund status. A successful fill answers whether the recipient was paid. It does not, by itself, prove that the relayer’s reimbursement bundle has finalized.

What should a user infer from a fast fill?

A fast fill is a liquidity service backed by a relayer’s balance sheet. The relayer prices the time between fronting funds and collecting reimbursement, along with gas and the chance of settlement complications. That makes the user’s speed independent of the slower accounting path, while making fill availability dependent on relayer participation and available inventory.

For most users, the useful check is the destination-chain transaction and the protocol’s deposit status, rather than an assumption that a completed transfer has also completed relayer settlement. For operators, the key review is whether the protocol’s fill contract enforces the intent terms, how the settlement layer validates event matching, and what the protocol does when a fill never arrives. The central trade-off is direct: relayers shorten delivery time by advancing capital, and the protocol repays them only after its settlement rules accept the fill.