My cross-chain swap is stuck — diagnose by symptom and source chain (BTC / ETH / SOL / TRC20 5-minute decision tree)

Read your symptom on the left, find your source chain in the middle, follow the action on the right. If your symptom does not match a row here, jump to the matching symptom section below and read the full version.

This is the most common false-alarm. You see your deposit confirmed on the source explorer. You refresh the swap page. The order still says processing. Nothing is broken — the aggregator is waiting on a per-chain safety-block count before releasing destination funds, because a too-early release exposes the solver to reorg risk.

Here are the per-chain thresholds that real bridges and solvers actually use (sampled 2026-06-17). Note the distinction: confirmation count (block depth, used heuristically by bridges) and protocol finality (irreversibility guaranteed by the chain's consensus) are different concepts.

Sources: en.bitcoin.it/wiki/Confirmation, blocknative.com/blog/anatomy-of-a-slot, li.fi/knowledge-hub/ethereum-finality-and-bridges, solana.com/developers/guides/advanced/confirmation, eco.com — TRC-20 confirmation time. All sampled 2026-06-17.

The worry threshold is roughly 3× the typical end-to-end fill for your route. An ETH→SOL swap that has been silent for 15 minutes after source confirmation is genuinely worth a support ping. A BTC→ETH swap still silent at 25 minutes is not — wait one more block on BTC before opening a ticket.

You opened the swap, walked away, came back to sign — and now the quoted output is different, or the page is asking you to re-fetch a quote. This is not a front-run. It's the routing model doing exactly what it's supposed to do.

Cross-chain quotes have short TTLs because they lock a price the solver/relayer has to honor. Two distinct mechanics matter here, depending on which engine routed your order (UpSwap routes through both):

• NEAR Intents (solver-bid auction). A solver bus broadcasts your intent to all connected solvers, waits up to 3,000 ms for bids, and returns the best fill. The default min_deadline_ms is 60,000 ms — one minute — though the UI may request 30s–2 min. After the deadline, deposits arriving late are refunded. Source: docs.near-intents.org — solver relay, sampled 2026-06-17.
• Relay (single-relayer model). For EIP-3009 permit deposits, Relay locks a no-slippage quote with permitExpiry default 600s (10 minutes). For non-permit flows, quotes are revalidated at fill time — no fixed-price guarantee. Source: docs.relay.link — get-quote, sampled 2026-06-17.

Between display and execution, two things can shift:

• Underlying market price. Stable-stable pairs (USDT↔USDC) drift typically under 0.05% per minute. Volatile pairs (ETH↔BTC) can drift 0.1–0.5% per minute.
• Destination-chain gas. On ETH L1, a 10-gwei swing changes a typical swap cost by roughly $0.30–$1. On BSC/SOL/TRC20 the absolute delta is under $0.10. Aggregators show the net (post-fee) receive amount, so this shifts the number you see, not a separate fee line.

What changes on a re-quote: the receive amount updates, the quote ID rotates, a new deadline is issued, and you must sign again. That is the entire flow. If the re-quoted rate moved more than your slippage tolerance allows, do not sign — review the new number first. Quote expiry protects you from a stale rate; signing a fresh stale rate would defeat the point.

You signed the deposit transaction. The wallet immediately shows the debit locally — that is just the wallet writing to its own ledger. On-chain, the tx may be in one of three states:

1. Still in mempool waiting for the next block. Most common when you used a low gas price or low BTC fee rate.
2. Included in a block but the aggregator has not yet detected the required confirmations.
3. Confirmed on-chain but the solver/relayer has not yet broadcast the destination fill (see Symptom 1).

Your next move depends on whether you picked the wrong network or the wrong fee. These are different problem classes — do not conflate them:

For where your funds physically sit during each of these states, jump to Guide #1. The short version: on non-custodial deposit-address flows, your funds are at an address the swap contract or solver controls — you can verify which address by inspecting the source tx hash on the explorer, then cross-checking against the deposit address the widget displayed.

A solver can decide it cannot fill your intent. The usual triggers: deposit arrived after the quote deadline; deposit amount fell short of amountIn; the underlying price moved past the slippage band; destination liquidity dried up; the recipient Associated Token Account (ATA) on Solana does not exist and no auto-create budget was reserved.

When that happens, source-chain funds are rebroadcast back to the original deposit address — or to refundTo if you supplied one in the intent. The refund tx is a normal on-chain transfer (the refund tx network fee is the on-chain fee paid by this refund transaction itself). You can watch it land in real time on the source-chain explorer.

Two things to expect:

• Per-chain refund window (sampled 2026-06-17):

  Source chain	Typical refund window	Refund tx network fee typical
  BTC	10–60 min, can stretch to 1–2h under high mempool fees	$2–$5 (highest, mempool fee market)
  ETH	1–5 min for visible status	$1–$3 (sub-gwei base fee era, ERC20 refund tx ~21k–65k gas)
  BSC	~1.1s finality post-Fermi; refund visible within 5–15s	$0.01–$0.10 (sub-gwei gas, 21k–65k gas units)
  SOL	~13s finalization, refund visible within 30s	$0.001–$0.05 (base + priority fee)
  TRC20	~57s finality, refund visible within 1–2 min	$0.30–$1 (Energy/bandwidth via TRX burn)

  Operationally safe envelope to quote a worried user: 5–30 min across all five chains.
• The refund pays its own network fee. Miners on BTC, validators on ETH/SOL/BSC, Super Representatives on Tron — the source-chain block producers collect the refund tx fee. There is no path to refund 100% of the deposited amount.

When the refund truly does not come back:

• Vendor bug (solver crashed mid-flow, race condition not detecting deposit). Escalate with the source tx hash. Usually resolved manually within 24–72h.
• Deep chain reorg. Rare on ETH/SOL/TRC20/BSC. Possible on BTC for under-6-confirmation deposits. Vendor must re-detect after reorg settles.
• Refund destination is a smart contract that cannot receive (Gnosis Safe without payable fallback, deprecated contract). Refund tx reverts; support reroutes to a user-supplied EOA.
• Wrong-network deposit. Different problem class — see Guide #2.

Source: docs.near-intents.org — 1Click API, docs.relay.link, sampled 2026-06-17.

If your stuck swap is genuinely a source-chain problem (tx not landing, not just waiting for confirmations), the fix lives in chain-specific mechanics. Here is the compact reference you actually need.

BTC — Replace-By-Fee (RBF) and Child-Pays-For-Parent (CPFP). A stuck BTC tx is almost always a low-fee tx losing the mempool fee market. Median sat/vB on quiet weekends has dipped as low as 0.10–2 sat/vB; medium-priority is typically 5–20 sat/vB (source: mempool.space, sampled 2026-06-17). Playbook:

1. Check the tx on mempool.space — is it RBF-signaled? (Note: Bitcoin Core 28+ supports Full RBF, which makes opt-in signaling no longer strictly required if the receiving node has it enabled; BIP-125 opt-in is the older standard most wallets still flag.)
2. If yes: open the sending wallet, find Bump fee / Speed up / Replace transaction. The wallet rebroadcasts the same inputs at a higher fee. Miners drop the old version (two txs cannot spend the same input).
3. If no: use CPFP. The recipient — or the sender, if a change output exists — spends the unconfirmed output with a high-fee child tx. The child pulls the parent into a block.
4. Worst case: wait. Bitcoin Core default mempoolexpiry evicts unconfirmed txs after ~14 days. After eviction the input is spendable again.

RBF requires the sender to bump. The recipient cannot use RBF — they must use CPFP. Source: bitcoincore.org — opt-in RBF FAQ, sampled 2026-06-17.

ETH — nonce ordering and the 12-second slot. Ethereum executes txs from one address in strict nonce order. If nonce N is stuck pending (gas too low), nonces N+1, N+2 all stay pending even if they paid huge gas. The network will not skip ahead. Fix: replace nonce N with a new tx at the same nonce and higher gas. Most wallets call this Speed up or Cancel. To true-cancel, send a 0-ETH self-transfer with nonce=N and higher gas. Source: etherscan — cancel pending tx, sampled 2026-06-17.

On finality: a tx included in a 12s slot is the new head but not yet finalized. The Fast Confirmation Rule (2026 deployment, see fastconfirm.it) gives a hard non-revert guarantee after a single 12s slot when ≥75% of staked ETH attests with under ~3s latency. Conservative bridges still wait 15–35 conf; two-epoch finality is 768s (~12.8 min). Current median gas is roughly 0.14–0.77 gwei (snapshot 2026-06-17 09:24 UTC via etherscan gastracker) — sub-gwei is normal post-Dencun/Pectra.

BSC — EVM nonce ordering, post-Fermi speed. BSC follows the same strict nonce ordering as Ethereum (same EVM semantics — Speed up / cancel work identically). Post-Fermi (deployed 2026-01-14), block time is 0.45s with practical finality of ~1.125s via BEP-590 fast-finality. Gas is sub-gwei in normal conditions; there is no RBF mechanic (RBF is a BTC-specific concept) — replacement happens via same-nonce, higher-gas resubmission. BSC's main stuck-tx failure mode is a same-nonce race when a wallet auto-rebroadcasts; check the explorer for the actual landed tx hash.

SOL — Associated Token Account rent and dropped txs. SOL finalizes in ~13s (32 slots of Tower BFT supermajority). The two most common failure modes:

• ATA rent. Sending an SPL token to a recipient who has never held it requires creating an Associated Token Account. Standard SPL token account (165 bytes) costs 0.00203928 SOL; with the immutable-owner extension (170 bytes), 0.00207408 SOL — calculated as two years of rent at 3,480 lamports per byte per year. Rent is the chain's rent-exempt minimum, refundable if the ATA is later closed. If the swap recipient does not exist and no party budgets the rent, the destination fill cannot complete. Source: docs.gemwallet.com — Solana rent, sampled 2026-06-17.
• Dropped tx vs failed (on-chain) tx. Symptoms: wallet shows sent, signature never appears on Solscan, or shows failed with no balance change. Root causes: priority fee too low on a contested write-locked account (fee markets are per-account, not network-wide), compute unit budget too low, slot congestion dropping the packet before it reaches the leader, or the recent_blockhash expired (~150 slots ≈ 60s validity). Recovery: resubmit with a fresh blockhash, higher priority fee, and correct CU limit. Base + priority fees are still consumed on a failed on-chain tx; a dropped (never-landed) tx costs nothing. Source: rpcfast — why Solana txs get dropped, sampled 2026-06-17.

TRC20 — Energy and bandwidth. Tron does not have a user-facing gas price. Each address gets 600 free bandwidth points per day; a TRC20 transfer uses Energy (TVM computation) plus ~345 bandwidth. A USDT transfer needs ~65,000 Energy if the recipient already holds USDT, or ~131,000 Energy if the recipient address is new to USDT. If you have no staked Energy and no rented Energy, the network burns TRX from your balance to cover Energy at the burn rate — approximately 6.5 TRX (existing recipient) or 13 TRX (new recipient), plus ~0.345 TRX bandwidth.

The classic failure: "Insufficient TRX to cover network fees" / "Out of Energy". Your USDT stays safe in the sender wallet — the failed broadcast does not move tokens. You may lose 100–300 sun (under $0.0001) in bandwidth on the failed attempt. Fix: top up a 3–5 TRX buffer, stake TRX for Energy, or rent Energy from a market (cheaper than burning, no lockup). Source: gasstation.ai — Insufficient TRON Energy fix, sampled 2026-06-17.

The triggers for an actual support escalation are narrower than people assume. Most stuck swaps resolve within the chain-specific wait windows above. Open a ticket when:

• You are past 3× the typical end-to-end fill window for your route (e.g. >15 min on an ETH→SOL, >2h on BTC→USDT).
• A refund was initiated but is past 30 min on ETH/SOL/TRC20/BSC or 2h on BTC.
• You sent to a deposit address on the wrong network (this is not auto-recoverable on most flows — see Guide #2).
• The source tx hash shows the deposit confirmed at the address the widget displayed, but the order shows failed with no refund visible.

Four fields to prepare before pinging. A support agent with these four can usually triage in one round-trip; without them, you both lose hours:

1. Order ID — the UpSwap-issued swap reference. Found in the URL or confirmation screen.
2. Source transaction hash — the on-chain hash from your sender wallet. This proves the deposit was broadcast and gives the agent a chain-of-evidence anchor.
3. Destination address — where you expected to receive. This confirms intent versus what was actually entered into the widget (catches typos, network mismatches).
4. Screenshot of the widget at the time of failure — timestamp, displayed quote, error message if any. Reproduces the visual state the agent cannot otherwise see.

Reach support at @upswapservice on Telegram or [email protected] via the official website footer. For a small non-custodial team, expect a first reply within 30 minutes during working hours; off-hours and weekends run 2–12h. Forensic cases — wrong-network deposit, stuck across chains — take 1–5 business days because they require upstream vendor coordination.

For perspective: when users panic, they reach for hack narratives. The most-cited recent example is the December 2023 Ledger Connect Kit npm compromise: a former Ledger employee was phished, malicious code was injected into the Connect Kit package, and ~$600k was drained from users of SushiSwap, Revoke.cash, and other DApps embedding the widget. Source: ledger.com — security incident report. That was a widget code-supply-chain failure — the displayed deposit address itself was swapped for an attacker address by injected JavaScript. It was not a routing failure, and it was not a custody failure.

A non-custodial deposit-address model — where you send to a contract-derived or solver-derived address and the destination payout is observable on-chain — does not protect against widget-supply-chain attacks. It does protect against a separate class of failures. Here is the boundary, drawn cleanly:

The honest framing: non-custodial routing removes the FTX/Bybit failure classes while leaving widget integrity to standard browser hygiene — verify the domain on any in-browser swap interface, cross-check the deposit address, prefer hardware-wallet signing. For the full physical-location-of-funds breakdown, see Guide #1; for the comparative framing of how each vendor handles these boundaries, see UpSwap vs ChangeNOW.

If you arrived here from a high-volume mainstream pair, the same symptom triage applies — your route's specific timing envelope is what changes. The most-traveled corridors covered by UpSwap include BTC→USDT, ETH→USDT, ETH→SOL, BTC→ETH, and SOL→USDT. For network-switch USDT moves between ERC20 and TRC20 — a common stuck-transaction trigger — see USDT ERC20 → TRC20 and USDT TRC20 → ERC20 alongside Guide #2.