A transaction receipt records the result of an on-chain transaction after it has been included in a block. The key condition is whether the transaction has a receipt yet: until then, “pending” describes what your wallet or RPC provider sees, not a confirmed swap result.
What should you check first?
Start with the transaction hash and confirm you are looking at Avalanche C-Chain, whose mainnet chain ID is 43114. In an explorer or wallet activity view, check whether the transaction is pending, successful, or reverted, and whether its block is final. Avalanche C-Chain reaches consensus finality quickly—typically around a second—so a transaction that remains pending much longer often needs investigation rather than more waiting.
For a direct RPC check, call eth_getTransactionReceipt with the hash. A null result means that provider has no receipt for an included transaction; it does not prove the transaction was dropped. Check eth_getTransactionByHash as well: if that also returns null, the node may not know about the transaction, or its pending pool may have discarded it. A wallet can still show “pending” from cached state or a different provider.
When a receipt exists, read status, blockNumber, gasUsed, effectiveGasPrice, and logs. Status 0x1 means execution succeeded; 0x0 means it reverted. Calculate the execution fee as gasUsed × effectiveGasPrice in wei, then divide by 1018 to get AVAX. The gas limit is only a ceiling: the fee is based on gas used, and a reverted transaction can still consume gas.
Why can a swap appear stuck?
A pending transaction has not been included, so there is no receipt to diagnose yet. One common cause is a nonce gap: an earlier transaction from the same address has not been mined, holding later nonces behind it. Another is a fee bid too low for current block conditions. Compare the transaction’s nonce and fee fields with recent transactions from that address before deciding what to do.
Replacement transactions use the same sender and nonce. A wallet may offer to speed up the pending transaction by signing a replacement with a higher fee, or cancel it by sending a zero-value transaction to the same address with that nonce. Neither action erases the original from the network: whichever transaction with that nonce is accepted first takes the slot. If the original has already been included, a replacement cannot undo it.
For a token exchange on Avalanche, the pool call may also be waiting behind an earlier approval or another account transaction. If you were using Core wallet, compare its activity view with the transaction hash in an explorer; those views can differ temporarily if they query different RPC endpoints. The hash and receipt are the evidence to follow, rather than the wallet’s spinner or notification alone.
What does a reverted receipt mean?
A receipt with status 0x0 means the EVM included the transaction but execution failed, so the swap did not complete. State changes and emitted logs from the reverted call are rolled back, though the network still charges for gas consumed. The receipt may not contain a human-readable reason; a trace or a simulation against the prior block state can reveal one, but a later simulation may differ because pool reserves and balances have changed.
For example, suppose a route estimated 31.2 WAVAX for 1,000 USDC, while the signed call set amountOutMinimum to 30.5 WAVAX. If the route could deliver only 30.4 WAVAX when executed, a minimum-output check would revert the whole swap. A tighter minimum protects the expected price but makes failure more likely as price moves; a looser minimum improves execution probability while accepting a worse rate. This example is illustrative, not a quote or prediction.
Check the receipt’s gas usage and fee, then inspect the transaction input and any available trace for the specific failing condition: minimum output, deadline, insufficient allowance or balance, or a pool call that reverted. A receipt with status: 0 is not evidence that tokens were swapped. For context on the exchange itself, Blackhole swap DEX is an Avalanche example where these same receipt checks apply. Blackhole swap transactions still follow C-Chain receipt semantics; the router’s input and execution state explain why a particular attempt failed.
What should you do next?
If the receipt is successful, verify the token transfer logs and your resulting token balance; the top-level status alone does not establish that the expected asset arrived. If it reverted, the swap did not happen, so after confirming the balance, review the failed call’s parameters and current quote before submitting a fresh transaction. Avoid resending the same swap blindly while its original hash is still pending.
If there is no receipt, check the nonce and transaction visibility through a second reliable C-Chain endpoint, then decide whether to wait or replace it with the same nonce. A receipt is the dividing line: once it is final, diagnose execution; while it is absent, diagnose propagation, fees, and nonce ordering. Take the hash and those checks into your next step.
Top comments (0)