RPC delays can leave swaps pending after broadcast

A swap can remain marked “pending” after a wallet sends it because the interface, its RPC provider and the blockchain may learn about the transaction at different times. Ethereum’s JSON-RPC documentation describes the node methods apps use to send transactions and request chain data; a delayed response can leave the screen behind the network.

For the pool mechanics behind a blackhole swap, the execution path matters: an interface can report submission before the chain has a result. A transaction hash shows that a request was created and broadcast, but it does not by itself show that the swap completed.

What does “pending” mean for a swap?

“Pending” usually means the wallet has not yet observed a completed transaction receipt; it does not mean the tokens have moved. The transaction may be waiting for inclusion in a block, or it may have been included while the wallet’s RPC endpoint has not returned the receipt.

Ethereum’s eth_getTransactionReceipt method returns receipt details after a transaction is included; before then, the result can be null. A wallet that polls one endpoint may therefore keep showing “pending” even if a block explorer or another node has already seen the transaction.

That gap is a reporting delay, not proof of a failed swap. The same status can also reflect a transaction that has not reached the network or one waiting behind an earlier transaction from the same account.

How can you tell whether the swap succeeded?

Check the transaction hash on an explorer for the correct network, then look for a receipt and its execution status. A successful receipt means the transaction ran without an execution error; it does not alone confirm that the wallet received the amount expected from a swap.

For a token exchange, inspect the transaction’s token transfers and the destination balance. The quoted output is an estimate made before execution; the actual amount can differ because the pool price changes or the swap’s slippage limit is reached. If execution fails, the transaction can still be recorded on-chain and incur a network fee.

Use these signals in order:

• No hash: the wallet has not shown evidence that it submitted the transaction.
• Hash, no receipt: the transaction may still be pending, or the RPC endpoint may be behind.
• Receipt with failed status: execution reverted; check the transaction details before trying again.
• Successful receipt: verify the token transfers and resulting balance to confirm the swap outcome.

What should you do when an RPC update is late?

First, wait briefly and refresh the transaction view or check the hash using a reliable explorer for the same network. If the explorer shows a receipt, the wallet’s status display has not caught up; avoid submitting the swap again until you confirm the first transaction’s outcome.

If there is no receipt, check whether the wallet shows an earlier pending transaction from the same address. On Ethereum-style networks, transactions use sequential nonces, so an earlier transaction can hold up later ones. MetaMask’s guidance explains that speed-up and cancel actions replace a pending transaction using its nonce; they are not a way to erase a transaction already confirmed on-chain.

The practical rule is to trust the receipt and token transfers over a spinner or status label. When an RPC endpoint is slow, check the transaction hash first, then act only after establishing whether the original swap is pending, failed or complete.