If a cross-chain swap is pending or failed, capture the route state and transaction identifiers before retrying; screenshots preserve what you saw, while on-chain records help establish what happened. For example, a route may show “pending” even after its source-chain transaction has confirmed, because the destination step is still outstanding.
What can a screenshot prove?
A screenshot can document the information presented to you at a particular time, but it cannot prove that funds settled on either chain. For a quickswap attempt, preserve the displayed status, the assets and networks involved, the amount, any transaction hash or message identifier, and the time you captured it.
If your case involves an Ethereum-to-Solana route, quickswap’s Ethereum-to-Solana routing explains that routing context; here, the key question is what evidence distinguishes a slow route from a failed one. Keep the original image, and make a separate copy if you need to mark it up.
Do not include a seed phrase, private key, password, or recovery code in a screenshot. If an address is needed to identify your transaction, check that it is the public wallet address and not a secret credential.
Why can “pending” and “failed” mean different things?
A cross-chain route can have several stages: a transaction is submitted on the source chain, that chain records it, a cross-chain message is relayed, and an action is attempted on the destination chain. A delay or error at one stage does not tell you by itself whether an earlier stage succeeded.
For example, say you swap an asset from Ethereum to Solana. Your source transaction may have a confirmed receipt while the Solana-side action has not yet appeared; that is different from a source transaction that reverted. Ethereum’s JSON-RPC reference defines a receipt status for a transaction, while Solana’s documentation describes transaction signatures and confirmation status. Check the relevant chain record instead of treating an app label as the final result.
A route can also look incomplete when the destination wallet or token view has not refreshed, or when the destination asset appears under a different token identifier than expected. Compare the destination transaction and token details with the route information before concluding that funds are missing.
What should you capture before taking action?
Capture a small, legible record that connects the route shown to the transactions you can verify. These steps help preserve the evidence without exposing wallet secrets.
- Record the route details. Capture the source and destination networks, asset names, approximate amount, and displayed status in one image if possible.
- Save the identifiers. Copy the source transaction hash and any route or message identifier shown; capture the destination transaction hash too if one exists.
- Capture the error in context. Include the full error text and nearby route details, rather than cropping to a single word such as “failed.”
- Write down the time. Note the date, time, and time zone for each capture, especially if the status changes. Keep the original file so its timestamp and contents remain available.
- Check both chains. Look up the source hash on its chain and the destination hash, if available, on the destination chain. Record whether each transaction is pending, confirmed, or reverted.
- Compare before retrying. If the source transaction confirmed, check whether the destination action completed before submitting another swap. A second attempt can create a separate transaction and make the history harder to interpret.
When is a screenshot enough to explain the dispute?
A screenshot is most useful when it preserves a temporary state or an error that may disappear after a refresh. Pair it with transaction hashes and chain records whenever the question is whether an asset moved, a transaction reverted, or a destination action completed.
If quickswap still shows a pending or failed state, compare that state with the records for each leg and keep the timeline: route displayed, source transaction submitted, source result, and any destination result. This makes it clearer whether the issue is a delayed message, a reverted transaction, or a mismatch between the displayed route and what the chains recorded.
Use screenshots to document what the route showed, and use transaction records to check what each chain did. Together, they give you a clearer basis for deciding whether to wait, investigate a specific leg, or avoid repeating a swap that may already be in progress.
Top comments (0)