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 documentation describes nonce queries as the way to determine an account’s transaction count; EIP-1559 defines the fee fields that govern a replacement’s gas bid.

A revert is different: the transaction consumed gas, but the swap state changes did not persist. For a router swap, a common cause is a minimum-output condition that the pool can no longer satisfy after the price moves; a deadline that has passed or an allowance that is too small can also revert the call. The explorer’s decoded error, if available, is useful, but the receipt status and token balances are stronger evidence than a wallet’s generic “failed” message.

What should you do with a pending transaction?

For a genuinely pending hash, first check whether the sender’s nonce is still unconfirmed. A later transaction from that wallet is normally blocked behind the gap, even if its gas bid is generous. Base blocks arrive quickly under normal conditions, so a transaction that remains pending well beyond the wallet’s usual confirmation time deserves a nonce and fee check rather than repeated clicking.

  1. Find the transaction hash. Open it on a Base explorer and record the sender, nonce, status, and fee fields.
  2. Compare the account nonce. Check the latest confirmed nonce and, where supported, the pending nonce. If the transaction’s nonce is already below the confirmed count, it has been consumed; refresh the explorer and inspect the receipt.
  3. Decide whether to wait or replace. If the nonce is still pending and the transaction fee cap is below current Base conditions, use the wallet’s speed-up function to rebroadcast the same transaction with the same nonce and higher fee fields. Wallets and RPC nodes apply different replacement thresholds, so there is no universal percentage that guarantees acceptance.
  4. Cancel only if the wallet supports a same-nonce replacement. A cancellation is typically a zero-value self-transfer using the stuck transaction’s nonce and a higher fee bid. It competes with the original; if the swap is included first, cancellation cannot undo it.
  5. Verify the result before retrying the swap. Wait for the replacement or cancellation receipt, then confirm the nonce is consumed and check token balances. Only then build a fresh swap.

Changing the nonce manually is usually the wrong fix: it may create a nonce gap and hold later transactions behind it. I would use the wallet’s replacement flow, because it preserves the nonce and transaction signing details that the wallet already knows.

How do you fix a swap that reverted?

Once the failed receipt is confirmed, resubmit only after correcting the reason for the revert. If the route moved beyond the configured minimum output, request a fresh quote and choose a slippage tolerance that reflects the token’s volatility and pool depth; increasing it blindly can accept a materially worse execution. For a deadline failure, use a fresh transaction with a new deadline rather than attempting to revive the mined call.

Check that the wallet is on Base and holds enough ETH for the network fee, and that the allowance covers the input amount if the token requires approval. BaseSwap can provide the swap interface, but it cannot make a reverted onchain call succeed retroactively; the contract evaluates the route and limits at execution time. Before acting, ask yourself: have I confirmed the transaction’s onchain state and nonce, or am I reacting to the wallet’s label alone?

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

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