What Records to Keep After a Cryptocurrency Exchange

Main Takeaways

• Save the order ID, asset and network on each side, quoted amounts, addresses, timestamps, displayed fees, status history and applicable terms.
• Record every relevant transaction hash, not just the deposit transaction. An exchange may have separate incoming and outgoing transfers.
• Verify the network, destination address, amount and transaction status independently in a suitable blockchain explorer or wallet.
• Never place a seed phrase, private key, wallet password or two-factor authentication code in an exchange folder or support message.
• Protect records containing wallet addresses, identity documents or compliance correspondence with encryption and controlled access.

The Minimum Vocabulary You Need

Order ID

An order ID identifies the request inside the exchange service. It helps support locate the operation, but it is not a blockchain identifier and cannot independently prove that a network transfer occurred.

Transaction hash or TXID

A transaction hash is the identifier used to find a network transaction. Bitcoin derives a TXID from serialized transaction data, while Ethereum applications use a transaction hash to retrieve the transaction and, once available, its receipt. ^[1]

Network

The asset ticker alone may not identify the transfer route. Tokens with the same familiar symbol can exist on different networks, and an address may be valid-looking without being valid for the intended route. Save the exact network name shown for both the deposit and payout.

Confirmation and finality

A broadcast transaction is not necessarily settled. It can first appear as pending and later be included in a block. Network-specific confirmation or finality indicators show how far that process has progressed; for example, Ethereum distinguishes inclusion from later justified and finalized states. ^[2]

Transaction receipt

On Ethereum-compatible networks, a receipt can show whether execution succeeded or failed, along with the block, gas used and event logs. A hash by itself therefore does not prove that a token transfer or contract call completed successfully. ^[3]

What to Save from the Exchange Order

Create one record package for each exchange rather than relying on browser history or an email inbox. Capture information while the order page is still accessible.

• Order identifier: the complete order or application ID.
• Creation details: date, time and time zone, plus any displayed payment window or expiry time.
• Exchange direction: the asset sent and the asset expected in return.
• Networks: the deposit network and payout network exactly as displayed.
• Amounts: the requested deposit amount, expected payout amount and actual amounts recorded after completion.
• Pricing record: the displayed rate or calculation method, including whether it was described as fixed, floating or otherwise conditional.
• Costs: service and network fees if the interface itemizes them. Do not reconstruct a fee from memory.
• Deposit instructions: the service’s receiving address and any required memo, tag, payment ID or similar routing field.
• Payout instructions: your destination address and any associated memo or tag.
• Status history: screenshots or exports showing meaningful changes such as awaiting deposit, processing, completed, expired, refunded or placed under review.
• Applicable conditions: the version or dated copy of relevant order terms, especially where a quote, payment window or compliance condition affected the result.
• Communications: support case numbers and messages connected to delays, corrections, refunds or verification requests.

Verification requirements can vary by exchange direction and compliance results. Record what was actually requested for the specific order, but avoid retaining unnecessary duplicate identity documents in an ordinary transaction folder. Requirements should be checked before creating a new order rather than inferred from an earlier exchange.

What to Save from the Blockchain Transactions

Most completed exchanges involve at least two movements: your deposit to the service and the service’s payout to you. Refunds, split payouts or operational wallet arrangements can introduce additional transactions.

Do not assume that the total value displayed for a Bitcoin transaction equals your payment. A Bitcoin transaction can contain multiple inputs and outputs, including a change output. Identify the output associated with the relevant destination address. ^[1]

Privacy-focused networks require a different verification model. With Monero, public blockchain data does not openly reveal the recipient and amount in the same way as a transparent ledger. A transaction ID, destination address and transaction key can be used to prove a particular payment, but disclosing that key reveals information that would otherwise remain private. Keep such proof separately in encrypted storage and share it only when necessary. ^[4]

Mechanism Map: From Order to Verifiable Record

1. You create an order. The service records the chosen direction, networks, amounts, destination details and order conditions. Observable result: an order page or confirmation containing a unique ID. Check: confirm that every address, network and memo matches your intended transfer before sending.
2. You broadcast the deposit. Your wallet signs the transaction locally and submits it to the selected network. Observable result: the wallet produces a transaction hash. Check: open that hash through an independently selected explorer or verify it through the wallet.
3. The network processes the deposit. Nodes propagate the transaction, and a miner or validator may include it in a block. Observable result: its state changes from pending or unconfirmed to included and progressively confirmed or finalized. Check: review the block and current status rather than relying solely on the exchange interface.
4. The service matches the transfer to the order. It compares the observed payment with the deposit instructions and applies its operational and compliance checks. Observable result: the order status changes or the service requests clarification. Check: compare the credited asset, network and amount with the deposit transaction.
5. The service initiates the payout. A separate transaction sends the output asset to the destination supplied in the order. Observable result: a new transaction hash appears in the order record or receiving wallet. Check: verify the destination, relevant transferred amount and successful network status.
6. You archive the evidence. The order details and network records are stored together under the order ID. Observable result: the exchange can be reconstructed without relying on the service account remaining accessible. Check: confirm that the archive contains both sides of the operation and opens correctly from backup.

A Realistic Recordkeeping Scenario

Suppose an exchange interface currently confirms that a particular BTC-to-USDT direction and selected payout network are available. The user saves the order ID, deposit address, BTC amount requested, USDT destination address, selected network, displayed calculation and order creation time.

After sending BTC, the wallet supplies a TXID. The user records it and checks the corresponding output to the service’s deposit address. Once the service processes the order, a second hash appears for the USDT payout. The user verifies that transaction on the correct network, checks the destination address and confirms successful execution where the network provides a receipt.

The final folder contains an order export, the incoming BTC TXID, the outgoing USDT transaction hash, status evidence and any relevant correspondence. Availability of that pair or network on a later date cannot be inferred from this record; current directions must be checked before each new exchange.

Security: Keep Evidence Without Creating a Theft Kit

Transaction records and wallet credentials belong in different security categories. An order archive may contain public addresses, hashes and receipts. It must never contain the wallet’s seed phrase or private key. Anyone obtaining those secrets may gain control of the wallet, and legitimate support should not need them. ^[5]

• Store records in an encrypted folder or encrypted password manager attachment.
• Use a neutral filename based on the order ID rather than exposing asset holdings or personal details.
• Keep a second protected backup so a device failure does not erase the only copy.
• Export text, CSV or PDF data when available; screenshots alone are harder to search and may omit full addresses.
• Open explorers and support pages from known bookmarks or independently verified domains to reduce phishing risk.
• Redact unrelated balances, account identifiers and identity data before sending evidence to another party.
• Never send seed phrases, private keys, passwords, authentication codes or remote-access credentials to someone claiming to investigate a transaction.

If support requests a transaction hash, order ID or destination address, provide only the fields needed for that case. A request for wallet recovery secrets is a warning sign, not a normal verification step.

Where the Evidence Model Has Limits

An on-chain record can demonstrate that a transaction was included and can expose technical details allowed by that network. It does not, by itself, prove the commercial purpose of the payment, the identity of the parties, the exchange rate agreed through an off-chain interface or ownership of an address at a particular time.

The reverse is also true. A completed order status does not replace blockchain verification. The page may describe the service’s internal state while the payout transaction remains pending, failed or recorded on a different network.

Records may also have tax and accounting consequences that depend on the user’s country, transaction purpose and legal status. In the United States, exchanging one digital asset for another can be a reportable disposal, and IRS materials identify details such as the timestamp, asset, amount, value, transaction type, fees and basis as relevant records. ^[6] Other countries can apply different definitions and retention requirements, so no universal storage period or reporting treatment should be assumed.

Failure Points and Their Visible Signs

Wrong network

Sign: the transaction exists, but not on the network named in the order, or the expected wallet balance does not change. Compare the chain identifier, token contract where relevant and complete destination address. A valid transaction on the wrong network is not evidence of payment through the required route.

Missing or incorrect memo

Sign: the deposit address and transaction are valid, but the order remains unmatched. Save the hash and contact the service through its official channel. Do not send another payment until the required next step is clear.

Pending or dropped deposit

Sign: the wallet created a hash, but no block inclusion appears or the transaction later disappears from the usual pending view. A locally displayed “sent” label does not guarantee confirmation.

Failed contract execution

Sign: an Ethereum-compatible transaction has a hash and block but its receipt reports failure. Receipts distinguish successful and failed execution, so block inclusion alone is insufficient. ^[3]

Amount mismatch

Sign: the network amount differs from the order’s deposit requirement after accounting for where the wallet fee was charged. Preserve the original quote and actual transaction details instead of editing the record to make them appear consistent.

Incomplete payout evidence

Sign: the order says completed, but the archive contains only the deposit TXID. Find and save the payout transaction separately. If the service used multiple transactions, retain each hash relevant to the amount received.

Phishing or fabricated support

Sign: a message requests a seed phrase, private key, authentication code, software installation or remote device access. Stop communication and return to the service through a previously verified channel. Ethereum’s official security guidance specifically warns that recovery phrases and private keys must not be shared. ^[5]

Understanding Check

After organizing the archive, you should be able to explain and verify:

• which record identifies the service order and which identifier locates a blockchain transaction;
• what asset and network were selected for each side of the exchange;
• which transaction represents the deposit and which represents the payout or refund;
• whether each relevant transaction is pending, confirmed, finalized, successful or failed according to that network;
• how the actual transferred amounts relate to the order without confusing fees, change outputs or unrelated transfers;
• why blockchain evidence cannot establish every off-chain term or legal consequence;
• which files may be shared during a dispute and which wallet secrets must remain private.

Before starting another operation, confirm the currently available direction and network, then open the exchange order page and prepare a secure record template so the essential details can be captured before funds are sent.