How Relay Refunds Failed Treasury Transfers on the Source Chain

A source-side refund returns a treasury transfer’s funds on the origin chain when a Relay solver cannot complete the requested destination fill. The treasury’s deposit goes to a Depository contract tagged with an orderId; if the solver cannot deliver the destination outcome, it sends funds back to the user on the origin chain and asks Relay’s Oracle to attest to that refund. The process ties the return to settlement, but it does not make every failed transfer an automatic refund.

How does a source-side refund work?

The Depository holds the treasury’s origin-chain deposit while a solver attempts the destination action using its own capital. The orderId links the deposit to the solver’s commitment. This differs from a lock-and-mint bridge flow: the solver can deliver the destination asset before the origin deposit is used to reimburse it.

If the solver determines that it cannot fill the order, it sends funds to the user on the origin chain. It then requests a refund attestation from the Oracle. The Oracle service reads the origin-chain transaction and checks that the refund matches the order. An authorized signer returns a signed attestation, which the solver submits to the Oracle contract on Relay Chain. That contract verifies the signature and applies the corresponding settlement action on the Hub. The refund is settled like a fill, so the solver’s return of funds and its reimbursement are linked by protocol accounting.

For the wallet-facing sequence, see this Relay Bridge guide to a cross-chain transfer; it covers the transfer steps while this account focuses on failed delivery and source-side recovery. For treasury operations, the key record is the specific order: the sender, the orderId, the origin deposit, the refund transaction, and the Oracle attestation should reconcile.

What does the treasury need to configure?

The treasury uses the same order flow as another sender; “treasury transfer” is an operational context, not a separate refund contract or protocol role. Before signing, treasury operators should verify the origin chain, asset, amount, intended destination action, and recipient encoded in the order. They should also establish which address the route treats as the user receiving a refund.

That last check matters because a treasury may deposit from a controlled wallet while naming another beneficiary for the destination. The protocol documentation describes the refund as a payment to the user on the origin chain, but does not establish that every application route returns to the original transaction sender. Treasury controls should therefore map the actual configured refund recipient to an address the organization can monitor and reconcile.

• Match the orderId in the deposit record to the solver commitment.
• Confirm the intended destination chain, asset, amount, and recipient before authorization.
• Record the designated source-chain refund address in the treasury’s transaction workflow.
• Reconcile any return against its origin-chain transaction and the order’s settlement record.

This is useful when treasury funds must be accounted for at the source even if destination execution fails. It also adds a dependency: the fast path requires a solver to detect the deposit, determine that the fill cannot succeed, and execute the return. The Oracle verifies the event afterward; it does not itself move the refund to the treasury.

What can prevent or change the refund?

A destination fill can fail because the solver lacks suitable liquidity or because the destination contract action errors. The solver’s fast-refund path is to return funds on the origin chain rather than wait for an expiry window. That is a solver-driven recovery mechanism, not a user-triggered timeout guarantee. If the solver does not issue a refund, the mere failure of a destination step does not prove that funds have returned.

The returned asset or amount can also differ from the original treasury input when the route includes an origin-chain swap. If that swap completed before destination delivery failed, the asset available for return may be the swap output. Execution price, fees, slippage, or return costs can affect the amount. Treasury accounting should compare the actual origin-swap output with the actual return, rather than compare the return directly with an estimate of the destination asset.

A short operational check is enough: locate the order record, inspect whether a refund transaction is linked, then verify its status, network, token contract, amount, and receiving address on the relevant explorer. A failed destination transaction alone is not evidence of a completed refund. If no return appears, treat the order as unresolved and use the protocol or application’s documented recovery route.

What is confirmed about the recovery path?

The documented fast-refund path confirms a source-chain transfer by the solver, an Oracle attestation of that event, and settlement on the Hub. It does not confirm a universal refund deadline, a guaranteed return of the original token, or a single fallback procedure for every application route. Relay’s protocol documentation notes that product-layer recovery options may exist, while identifying the solver-driven attestation flow as the directly evidenced protocol path.

For a treasury, the practical distinction is between a failed destination execution and a settled source-side return. Track them as separate states. Close the transfer only after the refund transaction reaches the intended, controlled address and the order’s settlement records agree.