Across protocol is traceable from deposit to fill or refund

Following a USDC deposit from Arbitrum to Base

A USDC deposit from Arbitrum to Base is a two-chain record: the origin SpokePool receives funds, then a destination relayer supplies USDC.

On Arbitrum, chain ID 42161, the confirmed receipt proves that the origin SpokePool accepted the deposit. It does not prove that Base, chain ID 8453, received the output. Open the same record in the Across Status Tracker, confirm the quoted recipient, and read the destination token rather than relying on the wallet's combined portfolio value. USDC uses 6 decimal places, so a raw balance change must be interpreted in millionths of one USDC. The fill completes when the destination transaction credits that specified token and recipient on Base.

Keep the origin hash beside the route details until delivery. An EVM transaction hash is 32 bytes, while a standard EVM address is 20 bytes; both appear as longer hexadecimal strings in interfaces. Matching the full values prevents a Base recipient from being confused with the Arbitrum depositor. The pair of chain records describes one transfer.

Reading pending before taking another action

A pending Across deposit is an indexed origin event whose matching destination fill has not yet appeared in the tracking service record.

Pending covers several ordinary moments: the origin receipt is new, the Across indexer has not ingested it, or no matching fill is visible yet. The documented indexing lag is 1 to 15 seconds, and a 10-second polling interval fits that cadence. Refreshing every second only repeats the same indexed view. A user-facing integration can stop rapid polling after 60 attempts, which creates a 10-minute observation window, then switch to a slower background check without creating another deposit.

Compare the origin record in Arbiscan with the destination address in BaseScan when the tracker lags. Etherscan serves the same role for Ethereum, chain ID 1. A pending label is a reason to preserve the existing record, not repeat the transfer. Optimism routes use chain ID 10, as explained Across protocol rewards.

What proves that a relayer filled the deposit?

A destination fill is an on-chain SpokePool execution that transfers the specified output to the recipient and marks the relay hash filled.

A further page states it Inside protocol. The current universal settlement interface emits FilledRelay with origin chain ID, deposit ID, recipient, output token, output amount, relayer, repayment chain, and fill type. Older Across V3 records expose the legacy FilledV3Relay name. The label differs, yet the decisive evidence remains a destination-chain event tied to the origin deposit. The tracking response also exposes a fill transaction reference once status becomes filled.

Across V3 allows one complete fill for a relay hash; partial fills are not supported.

The SpokePool's on-chain FillStatus enum has three ordered values: Unfilled at 0, RequestedSlowFill at 1, and Filled at 2. A separate FillType field distinguishes FastFill, ReplacedSlowFill, and SlowFill. Those labels explain how delivery occurred, while the recipient's balance answers whether the quoted asset arrived. A replaced slow fill still ends in the same Filled state because a relayer supplied the output before a bundled slow relay completed.

Read the destination receipt before treating an interface animation as completion. For a USDC route, compare the event's output amount with the recipient's token balance using 6-decimal precision. If Base is the destination, the fill transaction belongs to chain ID 8453, even though the deposit transaction remains on Arbitrum 42161.

Fill deadline, exclusivity, and the point of expiry

The fill deadline is a 32-bit Unix timestamp after which the destination SpokePool rejects a normal fill and the tracker reports that deposit expired.

In that configuration, Across records three time controls around a deposit: quote timestamp, exclusivity deadline, and fill deadline. Each is stored as an unsigned 32-bit value in the EVM interface. The exclusive relayer has sole fill rights until the exclusivity deadline; afterward, another relayer may supply the output while the fill deadline remains open. Expiry begins only when the fill deadline passes. Confusing those two deadlines leads to a false refund expectation during an open fill window.

A 32-bit unsigned integer spans 0 through 4,294,967,295. For these deadline fields, the value represents Unix time in seconds, so interfaces should compare it with the destination chain's time context rather than a local clock display. The quote supplies the actual deadline for that deposit; it is not a network-wide duration. A signed speed-up changes authorized output terms before the deadline, whose encoding remains bounded by 4,294,967,295.

Choosing the lookup key that survives a page refresh

An Across lookup key is either the origin transaction hash or the pair of origin chain ID and deposit ID from the event. Event-level tracking pairs originChainId with depositId, because a bare ID lacks chain context. Current FundsDeposited records use a 256-bit deposit ID; legacy V3FundsDeposited records use 32 bits. Ethereum is chain ID 1, Optimism 10, Polygon 137, Arbitrum 42161, and Base 8453. For the running route, the event key begins with Arbitrum 42161.

Four status labels and their control boundaries

The Across protocol status vocabulary is a four-state user view that separates destination delivery from the later return of origin-side escrow for ordinary tracking.

Pending and expired both leave the input associated with the origin-side deposit, but they authorize different next steps. Filled moves the user's attention to the destination balance, even though protocol settlement continues behind the interface. Refunded moves attention back to the configured refund chain. This four-row model keeps user delivery separate from relayer reimbursement, which the HubPool, Dataworker, and UMA Optimistic Oracle coordinate later.

How does a refund complete after expiry?

An Across refund is an on-chain return of escrowed funds to the chosen refund address after the fill deadline passes without destination delivery.

Expired is not the final return event. The input remains escrowed in the origin SpokePool while the Across Dataworker includes the deposit in a settlement bundle. The bundle reaches the HubPool on Ethereum, enters the UMA Optimistic Oracle challenge process, and then sends the refund root through the relevant canonical bridge. The minimum interval between root-bundle proposals is about 1.5 hours, so the path naturally extends beyond the fast-fill window. Canonical bridge timing adds another chain-specific interval.

The Swap API uses two refund controls. refundAddress identifies the receiver, and refundOnOrigin is a Boolean that defaults to true. True returns the selected refund token on the origin side; false selects the quoted destination-side refund path when supported. Once the status reads expired, polling every 60 seconds is proportionate. The deposit closes only after an on-chain refund transaction credits that address and the tracker reports refunded.

The return amount and token follow the quote's refund configuration, not the destination output balance. Keep the expired record open through bundle processing, then compare the refund transaction with the receiver's token balance on the quoted network, such as Ethereum chain ID 1.

Changing the fill terms without opening a second deposit

A speed-up authorization is a signed Across update that changes fill economics or delivery fields while preserving the original deposit record identity.

The current speedUpDeposit call carries six arguments: depositor, deposit ID, updated output amount, updated recipient, updated message, and depositor signature. The signature authorizes three mutable delivery fields: amount, recipient, and message. Lowering the output amount increases the economics available to a relayer, while a recipient update redirects delivery under the same authorization. The input amount, origin transaction, and original escrow do not move again. The Across protocol interface emits a RequestedSpeedUpDeposit event for the update.

Read the updated amount and recipient before signing because the next fill can use those terms. Tracking continues under the same origin chain and deposit ID; no second deposit is created. The fill event records the updated output details, so the destination balance should be checked against the authorized amount. One signature adjusts one existing deposit identity.

Closing the record on the correct chain

A closed Across record is one whose destination output or configured refund has arrived on the chain identified by the quote parameters. Filled closes the user-facing delivery path after the specified output token reaches the recipient. Refunded closes the unwind path. Keep three references with the record: origin transaction hash, deposit ID plus origin chain ID, and destination fill or refund transaction. A USDC transfer from Arbitrum to Base closes against Base chain ID 8453 after a fill.