Does a token approval prove that a v2 bridge deposit succeeded?

A token approval only authorizes spending; it does not prove that a bridge deposit occurred. The ERC-20 deposit path required the SpokePool to transfer tokens from the depositor. Approval could succeed even if the subsequent deposit failed or never happened. A successful deposit transaction and its deposit event establish that separate operation.

Why could a legacy deposit report an invalid quote time?

The v2 deposit contract checked the quote timestamp against a configurable time buffer. A timestamp outside the accepted interval caused the deposit to revert. That check governed quote acceptance at deposit time; it did not specify the recipient's delivery deadline. The applicable contract configuration determines the interval for a historical transaction.

Could a depositor increase the relayer fee after a v2 deposit?

V2 supported depositor-authorized fee updates intended to encourage relayers to fill a transfer. The update required a signed message, and the destination fill checked that authorization. A higher offered fee did not itself deliver tokens or create destination liquidity. Its effect depended on a relayer executing a valid fill with the updated terms.

Which callback did v2 composable bridging use?

The v2 composable recipient interface used handleAcrossMessage. Its completion flag mattered because v2 allowed partial fills. The v3 migration replaced that callback with handleV3AcrossMessage and removed the completion flag alongside partial-fill support. Recipient contracts therefore needed version-specific callback handling; matching a function name alone did not establish compatibility.

Were a v2 transfer's recipient and amount private?

V2 deposit and fill events exposed transaction details, including addresses and amounts, on public blockchains. Those records supported matching a destination payment to its origin deposit. Using a different recipient address did not hide the relationship recorded by the bridge events. Someone inspecting those records could examine the transfer without controlling either wallet.

Across v2 Legacy Bridge Fees and Transfer Limits

Sep. 10, 2026 · updated

Across v2 used relayers to advance tokens on a destination blockchain, charging transfer fees for delivery and settlement liquidity. It is a deprecated protocol version, so its fee fields and partial-fill behavior belong to legacy transfers. Transfer costs combined relayer gas, relayer capital, and liquidity provider fees. An origin deposit recorded the request; destination fills established how much the recipient received. Available liquidity affected delivery, while enabled routes and valid deposit parameters constrained entry. Understanding an old transfer therefore requires its actual contract version, fee terms, and destination records. Present-day interfaces can use different rules.

Relayer funding before bridge settlement

A relayer supplied destination tokens from its own balance, allowing delivery before the protocol finished moving settlement funds between chains. The origin SpokePool held the deposit and recorded its destination instructions. After a valid fill, the protocol owed the relayer reimbursement. This separated the recipient's delivery time from the time needed to replenish the relayer's capital.

The HubPool supplied settlement liquidity, while SpokePool contracts handled deposits and fills on participating chains. A slow relay provided another delivery mechanism when relayers could not supply the required capital. That mechanism depended on pool funds reaching the destination and the relevant settlement instructions becoming executable. Fast delivery and slow settlement were consequently different parts of the design, with different liquidity dependencies.

Legacy deposit inputs and transaction records

A v2 deposit specified an origin token, amount, destination chain, recipient, relayer fee, and quote timestamp. The receiving contract required an enabled deposit route. A token balance alone did not establish route compatibility.

Contract identity matters when interpreting historical transactions. Later deployments changed function signatures and event structures. Decoding an old transaction with a newer interface can omit fields or assign them the wrong meaning.

The legacy deposit event was named FundsDeposited. Destination fills used FilledRelay. These records distinguish the request from its fulfillment and help identify the relevant protocol generation.

A matching deposit identifier needs its origin-chain and contract context. Recipient, token mapping, amount, and fee terms also matter when reconciling delivery. An unrelated transfer to the same wallet does not establish completion of the bridge request.

The components of a legacy fee

The v2 fee structure kept the liquidity provider charge separate from the relayer charge. The legacy total bridge fee percentage combined relayFeePct and lpFeePct. Both percentages used the deposited amount as their basis. Treating the relayer component as the entire bridge fee would therefore understate the deduction.

Relayer compensation

Destination gas

The gas component compensated the relayer for submitting the destination fill transaction. Network execution costs affected this component. The depositor's origin transaction had its own network charge, which belongs in an overall cost comparison even when the bridge quote focuses on destination delivery.

Capital availability

The capital component compensated the relayer for advancing tokens and waiting for repayment. Relayers also faced operational and chain-finality risks during that interval. These costs explain why a transfer's economics involved more than the destination transaction's gas usage.

Pool utilization

The LP fee reflected the liquidity pool's utilization and applicable rate model at the quote timestamp. Token and route configuration affected that model. A percentage from another transfer therefore does not establish the fee for a historical deposit with different inputs.

What limited a legacy transfer's size and delivery?

Available destination capital constrained fast fills, while route configuration and deposit validation governed whether a legacy request could enter the system. Those constraints served different purposes. Passing the deposit contract's checks did not reserve enough relayer inventory to finish delivery immediately.

V2 supported partial fills, so a relayer could deliver only part of a request. The v2 contract tracked cumulative filled amounts before fee deductions. Comparing that counter directly with a wallet's net token increase mixes different accounting bases. Completion requires full fulfillment of the request, alongside the corresponding delivery after fees.

Later fee responses also contain minimum and maximum amount fields, including delivery-related limits. Their presence does not establish a permanent v2 ceiling or historical liquidity level. A quoted delivery estimate describes expected conditions, rather than a contractually fixed arrival time.

Verify full delivery of an old transfer

Suppose a recipient needs the full amount due after fees from an old transfer before using those funds. The retained deposit record identifies the intended recipient and destination. Reconcile that request with its destination fills using the following conditions:

Match the deposit to the correct origin chain and SpokePool.
Confirm that the destination token matched the route's token mapping.
Use the applicable fee terms when comparing gross fulfillment with net delivery.
Confirm that the latest matching fill's totalFilledAmount equals the deposit's amount.
Confirm that successful destination transactions delivered the corresponding tokens to the intended recipient.

If matching fills cover only part of the request, the transfer remains incomplete. A payment to the wrong recipient or a failed destination transaction does not establish delivery, even if the origin deposit succeeded. A later successful fill must still satisfy the checks above.

Verify full delivery of an old transfer: Suppose a recipient needs the full amount due after fees from an old transfer before using those funds.; The retained deposit record identifies the intended recipient and destination.; Reconcile that request with its destination fills using the following conditions:

Open full-size image

Liquidity provision and settlement exposure

Liquidity providers supplied pool capital that supported relayer reimbursement and slow fills. This was a separate use of the protocol from sending a bridge transfer. LPs earned fees for committing capital, while available pool liquidity constrained withdrawals. Funds allocated elsewhere in the system could prevent every provider from withdrawing immediately.

Settlement bundles grouped instructions for repayments and pool rebalancing. The optimistic validation process allowed disputes during a challenge period before execution. Its security depended on the dispute rules and the underlying contracts, including their bridge integrations. A completed recipient payment did not mean that the relayer's reimbursement had already finished. These dependencies also explain why slow fills could take longer than a relayer-funded delivery.

Liquidity provision and settlement exposure: Liquidity providers supplied pool capital that supported relayer reimbursement and slow fills. This was a separate use of the protocol from sending a bridge transfer.; LPs earned fees for committing capital, while available pool liquidity constrained withdrawals.; Funds allocated elsewhere in the system could prevent every provider from withdrawing immediately.

Open full-size image

Historical reconciliation versus a new transfer

Historical reconciliation requires the rules that governed the original v2 deposit. A new transfer requires the interface and contracts that support its route now. Reusing a legacy fee parser or event decoder can produce incorrect amounts even when familiar field names remain.

Open full-size image

The transition to v3 changed fee handling and removed partial fills. The recommended migration from the suggested-fees integration to the Swap API is a separate integration change: a legacy API label does not identify a transaction as v2. New integrations should use the maintained Swap API rather than reconstructing the old deposit flow. For an existing v2 record, historical contract data remains the appropriate basis for explaining fees and delivery.

Across v2: questions and answers

Does a token approval prove that a v2 bridge deposit succeeded?: A token approval only authorizes spending; it does not prove that a bridge deposit occurred. The ERC-20 deposit path required the SpokePool to transfer tokens from the depositor. Approval could succeed even if the subsequent deposit failed or never happened. A successful deposit transaction and its deposit event establish that separate operation.
Why could a legacy deposit report an invalid quote time?: The v2 deposit contract checked the quote timestamp against a configurable time buffer. A timestamp outside the accepted interval caused the deposit to revert. That check governed quote acceptance at deposit time; it did not specify the recipient's delivery deadline. The applicable contract configuration determines the interval for a historical transaction.
Could a depositor increase the relayer fee after a v2 deposit?: V2 supported depositor-authorized fee updates intended to encourage relayers to fill a transfer. The update required a signed message, and the destination fill checked that authorization. A higher offered fee did not itself deliver tokens or create destination liquidity. Its effect depended on a relayer executing a valid fill with the updated terms.
Which callback did v2 composable bridging use?: The v2 composable recipient interface used handleAcrossMessage. Its completion flag mattered because v2 allowed partial fills. The v3 migration replaced that callback with handleV3AcrossMessage and removed the completion flag alongside partial-fill support. Recipient contracts therefore needed version-specific callback handling; matching a function name alone did not establish compatibility.
Were a v2 transfer's recipient and amount private?: V2 deposit and fill events exposed transaction details, including addresses and amounts, on public blockchains. Those records supported matching a destination payment to its origin deposit. Using a different recipient address did not hide the relationship recorded by the bridge events. Someone inspecting those records could examine the transfer without controlling either wallet.