4 Checks to Reconcile a Pending Across Transfer

To verify an escrow balance, compare the tokens held by the origin SpokePool with the transfer claims and settlement activity recorded for that chain and token. A contract’s balance alone cannot prove your deposit is safe or refunded: funds are pooled, and each transfer moves through deposit, fill, and settlement states.

A block explorer shows what one contract did; an acrossbridge service status view connects the origin deposit to a destination fill, which is the more useful comparison when your transfer is pending. For an acrossbridge transfer, keep the origin chain, transaction hash, and deposit ID together so you do not confuse a similar transfer from another chain.

Four checks separate escrow from an unpaid claim

  • Match the deposit to its chain and token.
  • Check whether the destination fill occurred.
  • Separate user delivery from relayer repayment.
  • Check expiry, partial fills, and refund status.

1. Match the deposit to its chain and token. Find the successful deposit transaction and the SpokePool event it emitted. Match the origin chain, deposit ID, input token address, amount, recipient, destination chain, and fillDeadline. Token symbols are not enough: the same symbol can refer to different contracts, and balances must be compared in the token’s smallest units.

2. Check whether the destination fill occurred. Look for the matching fill event on the destination SpokePool or query the deposit status. Current deployments use the updated FundsDeposited and FilledRelay event names; older interfaces may label them V3FundsDeposited and FilledV3Relay. Match the event parameters, not just an explorer’s “success” label. If the destination transaction failed or no matching fill exists, the recipient has not been paid by that transaction.

3. Separate user delivery from relayer repayment. A relayer can front destination funds and wait for later reimbursement through protocol settlement. So a filled transfer can still appear as an outstanding relayer claim even though the recipient already received tokens. The origin SpokePool’s token balance is pooled capital, not a deposit-specific vault; it may rise or fall as bundles rebalance funds. A lower balance than the sum of deposits is not, by itself, evidence that a particular claim is unpaid.

4. Check expiry, partial fills, and refund status. A deposit past its fillDeadline may become eligible for a refund, but expiry is not the same as refund execution. A refund is processed through a later settlement bundle and can take hours. Partial fills also change the accounting: the remaining amount may follow a slow-fill path instead of a full refund. Use the status endpoint as a useful index, then confirm terminal actions on-chain.

Use the claim state to decide what to do next

For a balance reconciliation, group records by chain, token contract, and settlement block range. Compare the SpokePool’s token balance with deposits, fills, refund executions, and bundle transfers over that same range. Then inspect the bundle’s block bounds and relevant roots: relayer refund roots represent amounts owed to relayers, while slow-relay roots represent deposits queued for fallback fills. A raw balance comparison that ignores these pending claims and movements will not balance reliably.

For example, say 100 USDC leaves your wallet on Base, and the matching destination fill sends 99.8 USDC to your recipient. Before the fill, your claim is for delivery; after it, delivery is complete, while the relayer’s reimbursement can remain unsettled. If no fill appears and the deadline has passed, look for expiry and then an origin-chain refund execution to the configured refund address. Do not resend the same transfer just because reimbursement is still pending.

If the status view and chain events disagree, trust the confirmed chain events for what happened and check that you used the right chain, token, and deposit ID. In your place, I’d save both transaction hashes, verify the recipient’s destination balance, and wait for the refund or settlement path indicated by the on-chain state before taking another action.

Comments

Post a Comment

Popular posts from this blog

How Do Sequential Cross-Chain Swaps Work From Your Wallet?

If the token you want is not bridgeable, choose a route that swaps into a transferable token, bridges it, then swaps again on the destination chain. That is a sequential cross-chain swap: one goal, but several transactions or contract actions under the hood. Before you confirm, check the estimated amount you will receive and whether the route needs more than one wallet approval. A route can swap before and after the bridge A route uses an intermediate token when the source asset cannot travel directly to the destination or when another path gives a better result. For example, say you hold Token A on Ethereum and want Token C on Optimism. The route might swap A for a bridgeable stablecoin B on Ethereum, transfer B, then swap B for C on Optimism. This is the kind of route a cross-chain aggregator such as Super Bridge can present as one transfer to review. The screen may show your input and expected output together, while execution still depends on a source-chain swap, a bridge step, and...
Read more

Pending Base Swaps: Diagnosis and Recovery

A pending swap on Base is an unconfirmed transaction; a failed swap is already included but its contract call reverted. That distinction decides whether to wait, replace the transaction, or fix the swap conditions and submit again. A wallet’s spinner alone cannot tell you which state you are in. Is the transaction pending, dropped, or reverted? Start with the transaction hash in a Base block explorer, then check its receipt and nonce. If no receipt exists, the transaction has not been included; if the receipt has status 0, it was included and reverted. A missing result can also mean the wallet or RPC endpoint lost track of the hash, so compare the sender address and nonce against another Base RPC or explorer before resubmitting. This check matters when using BaseSwap : retrying a swap with a new nonce while the original is still pending can leave two trades queued. The first included transaction consumes that nonce, and the second same-nonce transaction cannot also execute. The Base do...
Read more

iswap integrators

A production AMM integration needs to choose among exact-input swaps on a V2 path, exact-input swaps through V3 pools, and exact-output swaps. The deciding condition is whether the user fixes what they spend or what they receive, then whether the selected pools and token behavior match the router call. Key points Quote from the exact pools and fee tiers you intend to execute against; a displayed rate alone is not an execution bound. For exact input, derive amountOutMin from the quote and an explicit tolerance; for exact output, cap spend with amountInMax. Set a short transaction deadline, but treat it as an expiry check, not price protection or a defense against sandwiching. V2 exact input fits reserve-based routes A V2 exact-input swap spends a fixed token amount and accepts any output at or above amountOutMin. The router computes amounts across the address path, transfers the input, then invokes each pair in sequence; the pair enforces its invariant as the swaps settle. For a constan...
Read more