Across relayers weigh gas and capital costs before filling cross-chain intents
Across relayers front destination-chain tokens and evaluate whether expected repayment covers those tokens, capital costs and transaction fees. A fill delivers the requested output before the protocol reimburses the operator through settlement. During that interval, the spent inventory cannot fund another fill. Gas prices, token values and the allowed repayment location therefore influence which deposits an operator accepts. The choice also changes where inventory returns and which liquidity provider (LP) fee applies. A confirmed delivery establishes one part of the transaction; repayment still requires a valid deposit match and settlement execution.
Upfront Inventory and Deferred Repayment
An inventory-funded fill spends tokens on the destination chain before settlement replenishes the relayer’s balances. The origin deposit specifies the required output token, amount and recipient. The operator needs access to that output inventory at the destination. Holding the economic equivalent elsewhere does not make it immediately spendable there. Once a valid fill succeeds, the recipient has the delivered tokens while the operator awaits repayment. This timing gap creates working-capital demand even when the user’s transfer appears complete.
Delivery Evidence and Repayment Entitlement
A destination receipt proves execution on that chain, while settlement determines whether the fill qualifies for reimbursement. Relayer repayment requires a fill that matches an eligible origin deposit. Matching includes token identities, amounts, chain information and the recipient under the applicable protocol rules. Authorized deposit updates also need their required signatures. A transaction hash alone does not establish this relationship, and an arbitrary token transfer does not substitute for a protocol fill.
Repayment records identify the refund token, chain and address. The refund-token mapping follows the input token on the resolved repayment chain, so repayment can restore a different asset from the output token spent on delivery.
Destination Gas and Settlement Overhead
Destination transaction fees depend on the execution that the fill requires and the chain’s fee model. On Ethereum Virtual Machine (EVM) chains, gas usage and the effective gas price determine the execution-fee component. Rollup chains can also charge for publishing transaction data or apply other configured components. A contract callback adds work beyond token delivery for an EVM V3 fill with a nonempty message and a contract recipient. Its execution behavior belongs in the cost estimate.
Gas spending extends beyond successful fills when an operator submits approvals, rebalancing transfers or repayment-execution transactions. Each transaction has its own payer, and permissionless refund execution means the relayer need not personally submit every repayment transaction. Bundling distributes settlement work across multiple fills, reducing repeated verification overhead. It does not remove the destination transaction that an inventory-funded fill requires. Budgeting only for successful delivery omits operational transactions that consume the same gas reserve.
When Is a Fill Worth Its Cost?
Fill profitability requires expected repayment value to exceed the output inventory’s value and other operating costs. The input/output spread cannot answer that question when the tokens differ in value or decimal scale.
Expected repayment starts from the deposit’s input amount, less the applicable LP fee. Comparing its value with the output tokens is simpler for a same-asset transfer. A different output asset introduces a conversion-value difference that raw token units conceal.
Transaction spending reduces the remaining margin. An estimate should include fill execution and any costs that the operator bears while maintaining inventory. The relayer fee compensates the operator for performing the service. It does not establish net profit after those expenses.
Capital cost measures the effect of committing inventory until repayment becomes usable. Longer settlement delays increase that commitment for the same fill. A positive margin can therefore accompany insufficient capacity for further deposits. Available balances must cover the output amount and the gas needed to execute the fill.
Finality and implementation risks also affect the fill decision. An origin-chain reorganization can change or remove the deposit that supports reimbursement. Incorrectly constructed fill data can defeat the matching rules. A higher quoted fee does not repair either defect or turn an invalid fill into a payable one.
Repayment Location and Inventory Recovery
Repayment-chain selection changes the LP charge and the location of recovered inventory. Under the V3 settlement rules, origin-chain repayment avoids the cross-chain LP fee. It also returns inventory away from the destination that funded delivery. Rebuilding that destination balance may require a separate transfer with its own cost and timing considerations.
| Repayment Choice | Inventory Effect | Token and Chain Conditions |
|---|---|---|
| Origin chain | Replenishes inventory on the deposit chain | Repayment uses the input token on its origin chain |
| Destination chain | Replenishes the repayment token on the fill chain | The equivalent input token needs an eligible repayment route there |
| Another supported chain | Directs repayment toward another inventory allocation | The equivalent input token needs an eligible repayment route on that chain |
| Repayment restores the eligible input-token equivalent, which may differ from the asset spent on delivery. | ||
Requested repayment locations remain subject to token routes and deployment rules. The V3 settlement specification selects the origin chain for deposits from a Lite deployment before applying any repayment-address fallback. Missing pool-rebalancing routes can also cause the resolved chain to fall back to the origin. A chain’s presence in the broader protocol does not mean every token can repay on it. The requested chain is therefore not necessarily the chain that settlement applies.
Capital Turnover During Settlement
Capital turnover depends on settlement execution, so fast recipient delivery does not imply equally fast reimbursement. A Dataworker groups valid fills into repayment bundles. Optimistic repayment bundles undergo a challenge period before finalization. UMA’s Optimistic Oracle provides the mechanism for resolving bundle disputes. Message delivery and refund execution on the repayment chain add their own dependencies. Bundle proposal, bundle finalization and receipt of funds therefore describe different accounting states.
Usable inventory falls as unsettled fills accumulate. A longer delay ties up more inventory at the same pace of new fills. Total inventory can also look sufficient while the required destination token runs short. Settlement monitoring needs to follow outstanding repayments and where the recovered balances will land. Successful fill receipts record inventory spending. A refund leaf can execute while payment remains deferred, so confirm the repayment in the relayer’s token balance. A quoted user fill-time estimate addresses delivery to the recipient. It does not promise when the relayer will regain spendable capital.
Competition, Exclusivity and Fill Deadlines
Fill eligibility requires the operator to respect the deposit’s deadline and any active exclusivity window. A nominated relayer has temporary fill rights for that deposit. Other operators may fill after the window ends, provided the fill deadline and remaining conditions still permit execution. Open deposits create a race for inclusion, so latency and transaction ordering affect who earns compensation. A higher gas bid can increase transaction spending without creating exclusive rights. The operator’s cost threshold still applies when an exclusive opportunity becomes available.
RPC Reliability and Signing Exposure
Reliable chain data and signing controls affect both repayment risk and the cost of operating a relayer. Remote procedure call (RPC) access supplies deposit events, destination fill status and transaction receipts. Stale or inconsistent responses can distort a bot’s view of available fills. Event coverage, provider health and confirmation tracking therefore belong alongside inventory accounting. A low transaction-fee estimate offers little value when the bot acts on incomplete chain history.
The relay bot needs signing access to spend inventory and pay transaction fees, and its key material controls real balances. Restricted secret-file permissions and isolated execution reduce exposure; neither substitutes for correct fill construction. Infrastructure charges enter operating costs even when a bot submits no fills. Evaluating a relayer operation includes RPC service costs, process upkeep and key management. Those expenses reduce the margin that an operator can keep from apparently attractive deposits.
Useful questions about Across relayers
Can the V3 Relay Bot Simulate Fills Without Submitting Them?
The documented V3 bot supports SEND_RELAYS=false to review simulated fills before enabling relay submission. This mode helps inspect proposed transactions and approvals without committing to live fills. Simulation still reflects the state and assumptions available at that moment. It cannot promise that the deposit will remain unfilled, gas prices will remain unchanged or eventual settlement will reimburse an incorrectly matched fill.
Must a Relayer Operate a Dataworker to Receive Repayments?
A relayer does not need to operate the Dataworker that proposes settlement bundles. The roles perform different tasks: relayers supply destination tokens, while Dataworkers construct repayment and rebalancing instructions. The proposed bundle still needs verification and execution before repayment arrives. Proposers must meet the HubPool settlement contract’s proposal requirements and post its configured bond.
What Happens to Gas Spending If a Competing Fill Executes First?
An EVM fill transaction that reaches execution after the same intent is already filled can revert and still consume gas. The successful competing fill prevents another payment for that intent. A transaction that never reaches inclusion has no on-chain execution fee. Transaction receipts distinguish these outcomes; submitting a transaction or receiving its hash does not establish a successful fill.
Which Contract Needs an ERC-20 Allowance for a Direct Fill?
For a direct ERC-20 fast fill through an EVM SpokePool, the token payer must authorize that destination SpokePool to spend the required output token. The allowance belongs to that token contract and spender. It is separate from the depositor’s origin-chain approval and does not replace the payer’s token balance. Other execution interfaces can use a different token payer.
Are Partial Fills a Way to Reduce the Capital Required by a V3 Deposit?
A standard V3 fill does not support partial fulfillment, so dividing the requested output across several smaller relayer contributions does not satisfy that deposit. The fill must deliver its required output amount. A smaller independent deposit creates a different obligation; it does not partially complete the original one. Capital planning therefore needs to respect the full output requirement of each accepted fill.
How Does a depositor-authorized speed-up Affect a relayer’s Margin?
A valid depositor-authorized reduction in the output amount can increase the margin available to a relayer using that update. The signature authenticates the changed terms, and the operator must evaluate the effective output alongside the applicable repayment and costs. The relayer has the option to use an authorized update; it cannot create a lower output requirement unilaterally. The documented Solana SpokePool does not support V3 speed-ups.
Is a Repayment Address Valid on Every Supported Chain?
No. The refund address must be valid on the resolved repayment chain and controlled by the relayer. V3 settlement uses the fill sender as a fallback for an invalid address, except when the fill or resolved repayment is on a Solana Virtual Machine (SVM) chain. Where the required token routes exist, this fallback also changes repayment to the destination chain. If the final address remains invalid, settlement excludes repayment from the refund root. The documented recovery path uses a separate administrative refund bundle after the relayer supplies a valid address.
Does an application’s Extra Fee Go to the Relayer?
An optional application fee goes to the configured application-fee recipient, separately from protocol LP and relayer fees. It compensates the integrator rather than the operator that fronts the fill. A transfer’s total charge can therefore include revenue that the relayer never receives. Profitability calculations need the operator’s own repayment and costs, not the application’s aggregate fee figure.
updated