Across is tracked From Deposit to Fill or Refund

Across is an intent-based crosschain bridge whose deposit record lets a user follow one transfer from origin confirmation through a relayer fill, a signed speed-up, or an expiry refund. The key object isn’t a bridge balance; it’s a deposit identified by its origin chain and deposit ID, or by its transaction hash. Pending means no relayer fill has settled on the destination yet. A speed-up revises the promised output amount and, where needed, the recipient or message under the depositor’s signature. Filled ends the delivery path. Expired opens the refund path, and refunded confirms the return transaction. This page focuses on reading, adjusting, and closing that lifecycle rather than repeating the broader protocol overview.

One Lifecycle Now Covers Fills and Refunds

Either way, Across deposit tracking now follows the intent as a state machine, replacing guesswork with a small set of explicit states.

Four core labels describe ordinary transfer progress: pending, filled, expired, and refunded. Pending means the origin deposit exists without a completed destination fill. Filled means a relayer delivered the specified output, and the tracker can return the fill transaction reference. Expired means the fillDeadline passed before delivery, so the refund lifecycle begins. Refunded means the return transaction has completed. The indexing service polls relevant events every 10 seconds and reports an expected 1-to-15-second indexing delay, so refreshes faster than 10 seconds don’t reveal a newer indexed state.

Transaction Hash Lookup

The first lookup method uses the origin transaction hash. On EVM chains, that hash contains 32 bytes, displayed as 0x plus 64 hexadecimal characters. One value is enough for the tracker to locate the deposit event and its destination fill reference. This route suits a wallet receipt because the hash already names the submitted transaction.

Origin Chain and Deposit ID

The second method pairs the deposit ID with the origin chain ID. That pairing prevents identical numeric deposit IDs on different SpokePools from being confused. Ethereum uses chain ID 1, Optimism 10, Polygon 137, Base 8453, and Arbitrum 42161. Those identifiers describe networks, not amounts, so they’re written without thousands separators.

Read the Deposit Record Before Changing It

The Across deposit record fixes the terms that a later fill, speed-up, or refund must reference exactly.

Start with the origin and destination chain IDs, then match the input token, output token, input amount, output amount, depositor, recipient, and fill deadline. Token units matter at the smallest precision: USDC uses 6 decimals on Ethereum, Arbitrum, Base, Optimism, and Polygon, while WETH uses 18 decimals. Thus, 1 USDC is encoded as 1,000,000 base units, while 1 WETH is 1,000,000,000,000,000,000 wei. The displayed balance should agree with the destination token’s own decimal scheme; a raw integer without its token contract and chain doesn’t describe the promised delivery.

A confirmed origin transaction proves the deposit action, not the destination delivery. The recipient may see no new balance while status remains pending, and the origin wallet’s lower balance doesn’t prove a relayer filled. Treat fillTxnRef as delivery evidence and depositRefundTxnRef as return evidence. The fill deadline is a Unix timestamp in seconds, distinct from the exclusivity deadline that temporarily reserves the fill for one relayer.

When Should You Use a Speed-Up?

Use an Across speed-up while a deposit remains unfilled and a lower output amount improves the relayer’s economic incentive.

Terms the Signature Can Revise

Current Across contracts let the depositor authorize three mutable fields in one update: updated output amount, updated recipient, and updated message. The input amount, input token, output token, origin chain, destination chain, deposit ID, and fill deadline stay bound to the original deposit. The authorization uses an EIP-712 typed-data signature that includes the origin chain ID, which binds the update to the recorded intent.

Relayers aren’t obliged to accept the revision, and a fill that already completed leaves no pending intent to amend.

A Worked Output Revision

In this worked example, both changing inputs are hypothetical: the original output is 1,000.000000 USDC, and the revised output is 998.500000 USDC. Subtracting gives 1.500000 USDC of additional spread available to the relayer. Dividing 1.500000 by 1,000.000000 produces a 0.15% reduction. If a relayer accepts the update and fills it, the recipient gets exactly 998.500000 USDC on the destination chain. Across V3 doesn’t split that outcome into partial fills; the intent fills once in full.

The Signature Is a Bounded Amendment

The Across speed-up signature authorizes one revised fill path and doesn’t move another input balance from the depositor.

The typed payload covers the deposit ID, origin chain ID, updated output amount, updated recipient, and updated message. An externally owned account signs through EIP-712. A contract depositor can validate the signature through ERC-1271, provided that wallet implements the standard. After verification, the origin SpokePool emits a RequestedSpeedUpDeposit event containing the update, and a relayer may use it with fillRelayWithUpdatedDeposit. The relayer still references the original relay data, so a different chain, token pair, or input amount identifies different terms and fails the required match during destination execution. The same material is presented Across comparison in depth.

Across exposes four core user-facing lifecycle states for an ordinary deposit: pending, filled, expired, and refunded. A speed-up doesn’t create a fifth state, a second deposit ID, or additional input token units. The wallet should display the exact revised output, recipient, and message before signing because those three fields define the authorized delivery.

What Happens After the Fill Deadline Passes?

After the Across fill deadline passes unfilled, the deposit becomes expired and enters the settlement-backed refund sequence.

Expired isn’t refunded. The input funds remain in the origin SpokePool until the Dataworker includes the refund in a settlement bundle. Bundles are grouped around a roughly 1.5-hour cycle, then pass UMA’s optimistic challenge period. A finalized refund root travels through the relevant canonical bridge, and onchain execution sends assets to the configured refund address. Because that sequence combines bundle timing, a challenge window, and chain delivery, several hours is the correct expectation; the fill deadline itself isn’t a refund arrival estimate.

The Swap API default sets refundAddress to the depositor and refundOnOrigin to true. A custom integration may select another controlled address or request a destination-chain refund, and its quote states the resulting refund token and chain. HyperCore is a special route: its origin chain ID is 1337, while refund-on-origin processing surfaces on HyperEVM chain ID 999 rather than the HyperCore order book.

Only refunded closes the return path; expired marks eligibility and processing.

Balances and Transaction References Close the Loop

A completed Across lifecycle needs the terminal status, the matching transaction reference, and the expected balance on the correct chain.

Filled returns the destination chain ID and fill transaction reference. The destination chain’s explorer should show the recorded recipient, output token, and authorized output amount. On an ERC-20 route, the transaction logs record the token delivery. Because the indexer has a 1-to-15-second reporting delay, the onchain fill may appear before the status response changes. Match the token contract as well as the ticker, since the same symbol alone doesn’t identify an asset across chains.

Refunded returns the deposit refund transaction reference. Check the origin chain under the default configuration, or the refund chain stated in a custom quote. Retain two records after closure: the origin deposit reference and whichever terminal reference applies, either the destination fill or the refund. The deposit ID and origin chain ID keep both records attached to the same lifecycle.

The Best Fit Is an Observable, Time-Bounded Transfer

This lifecycle suits Across users who want one recorded action, one adjustable intent, and a verifiable terminal transaction.

It fits a USDC or WETH transfer between Ethereum, Arbitrum, Base, Optimism, or Polygon when the user expects a destination balance and wants a defined response if no relayer fills before the deadline. Integrators using viem or ethers can persist the origin chain, deposit ID, and hash, then poll the status API at the recommended 10-second interval. Users receive the same conceptual sequence in the bridge interface: deposit, read status, consider a signed revision while pending, then verify the fill or refund transaction. Every route still ends at the token and chain written into its specific record.

The decisive habit is to follow the recorded deposit rather than a generic wallet activity feed. That keeps the output balance, speed-up, and refund tied to the same intent from entry through closure.