Dodoex Order History and Swap Confirmation Checks

Order History and the blockchain receipt

Order History provides the trading record, while the blockchain receipt reports execution of the transaction behind it. The history entry includes status, rate, creation date, and transaction hash. Use the date and pair to locate an entry, then use its hash for a precise match. A displayed rate alone cannot establish completion. The receipt and resulting token movements answer whether the submitted operation succeeded.

The account and network behind the record

A useful status check starts with the same account and network the wallet used for submission. A different account can show an unrelated balance, while a different network leads to unrelated transaction records. Keep those identifiers alongside the hash when investigating a missing order.

Wallet connection

The wallet and application must support the selected network, and the connected account must hold the intended input amount on it. Before submitting an approval or swap, ensure the account also has enough native currency to cover gas. Connection gives the application an account to interact with; it does not itself submit a swap. Before authorizing anything, compare the account shown in the application with the account shown in the wallet. Reconnecting another account does not move the original account’s assets.

Token identity

A token’s contract and network identify the asset involved in the transaction. Symbols alone can leave ambiguity. For receipt reconciliation, compare token contract addresses with the assets you selected, and identify any native asset by its network. Keep the distinction between a network’s native asset and a token representation of that asset, because their balances and approval requirements can differ.

Approval before the swap signature

A token approval authorizes a spender to access a specified amount of a token. An approval transaction does not itself exchange the approved tokens. If the wallet shows a successful approval, the next question is whether you also submitted the swap. Separate operations have separate transaction records, so compare their actions before interpreting a success label.

An existing sufficient allowance can remove the need for another approval. When an approval is necessary, inspect the token, spender, and spending cap before accepting it. A larger allowance extends the amount the spender can access; it does not improve the swap’s price. An allowance below the intended input can require another approval, with another network charge.

The final review before submission

Before confirming the swap, check its input amount, output asset, slippage tolerance, and any configured deadline. If the confirmation shows a minimum received amount, make sure you accept it. Resolve an unexpected network, asset, or amount before confirming the wallet request. After any required approval, the trading flow uses Confirm Order followed by wallet confirmation.

Output and price movement

The quote describes expected output under the quoted conditions. Slippage tolerance limits the adverse movement the transaction permits during execution. Where the confirmation displays a minimum received amount, compare it with the output you can accept. Liquidity and price impact affect the quote itself; raising tolerance does not repair poor liquidity or create a better price.

Deadline and authorization

A configured transaction deadline limits how late the swap may execute. An expired deadline can prevent execution even if the transaction eventually reaches the blockchain. Wallet authorization and network processing occur at different moments. Until you authorize submission, you can decline the request and reconsider the trade without sending that swap transaction.

Gas estimates and actual charges

The network fee depends on the transaction’s execution work and the network’s fee conditions. Approval and swap transactions can each incur gas. A route involving more contract interactions can require more execution work, so an earlier transaction’s charge is not a fixed price for the next swap.

An included transaction that reverts still incurs charges for gas consumed. This explains why a failed swap can reduce the gas balance without delivering output tokens. Compare the actual transaction charge with the wallet’s earlier estimate, and keep network charges separate from trading fees and price impact. A gas deduction by itself does not identify a successful trade.

What proves that my swap completed?

A successful swap transaction and matching output delivery establish completion of the intended exchange. Start with the hash associated with the swap, then inspect the receipt and token movements on the correct network. A success label for an approval or another contract action answers a different question.

A transaction receipt’s execution status distinguishes a successful top-level call from a reverted call. Inclusion in a block therefore needs an execution-status check. A pending transaction has not yet supplied the same evidence as a successfully executed transaction.

The token movements explain what the operation accomplished. Match the input asset, output asset, amounts, and receiving account. Routing may involve intermediate contracts, so the transaction’s top-level destination can be a contract rather than your receiving account. Inspect the final token delivery instead of interpreting the destination field as the complete swap result.

View image file

The quoted output and recorded output serve different purposes. The quote supports the decision before submission; the executed amounts describe the completed trade. Compare them alongside the accepted execution constraints. Preserve the quote separately if you need to investigate a difference later, because a refreshed quote describes a new market state.

History services and wallet displays present blockchain data through their own interfaces. A missing entry or stale balance alone does not prove failure. When the displays disagree, use the matching transaction receipt and account’s token balance to distinguish an execution problem from a display problem.

Destination delivery for a cross-chain order

A cross-chain order requires destination delivery in addition to the originating transaction’s progress. Confirmation on the starting network establishes only that stage. Match the order’s selected destination network, output token, and recipient when checking completion, and use the cross-chain order details to follow the remaining processing.

Cross-chain order services can cache status information, so an unchanged display does not establish that processing has stopped. Preserve the originating hash and any destination transaction record the order provides. A bridge-related delay requires examination of that order’s status; the same-network missing-token checks cannot explain every cross-chain outcome.

Records for the next action

A useful retained record includes the network, account, transaction hash, execution status, token amounts, and actual network charge. Keep an approval record separate from its swap, and preserve any error text for a failed transaction. Before another submission, resolve the original transaction’s status and review a fresh quote.