After a cryptocurrency exchange, save enough information to connect three parts of the operation: the service order, the transaction sent to the service, and the transaction received from it. A transaction hash alone may identify an on-chain event, but it does not normally preserve the exchange direction, quoted terms, order status, support correspondence, or the reason an amount differs from the original estimate. The practical aim is a record that can be used to trace a delayed transfer, explain the operation for accounting or tax purposes, and communicate with support without disclosing wallet secrets.
This analysis covers recordkeeping for a completed or attempted crypto-to-crypto exchange. It does not determine how long a particular person must retain records or what must be reported in a specific country. Tax, anti-money-laundering, and record-retention rules differ by jurisdiction and may change.
How the Claims Were Checked
Technical claims are based primarily on protocol documentation and official project materials describing transaction identifiers, transaction fields, confirmation status, and payment proofs. Regulatory and recordkeeping claims use publications from the IRS, FATF, and FTC. Source freshness matters most for tax reporting and compliance requirements, so dated regulatory material is distinguished from protocol facts. Pages without a stated publication or update date are identified as such rather than assigned an estimated date.
The sources were checked on September 24, 2026. That check does not turn general documentation into proof of what happened in an individual exchange order: the saved order page, wallet history, transaction identifiers, and relevant blockchain data remain the evidence for the specific operation.
The Core Record to Keep
A useful exchange record has two layers. The first describes the service order; the second describes the blockchain transfers used to fund and settle that order. Keeping both layers matters because an exchange can involve separate incoming and outgoing transactions, potentially on different networks.
Order or Application Data
- Order ID: the service’s unique reference for the application.
- Creation date and time: include the time zone if it is displayed.
- Exchange direction: record the exact asset sent and the exact asset expected in return.
- Network for each side: save the network selected for the deposit and the network selected for delivery. Do not rely on the asset ticker alone.
- Expected amounts: preserve the amount to be sent, the estimated amount to be received, and any minimum or maximum figures actually displayed for that order.
- Terms shown at creation: keep the displayed rate type, fees, quote expiration, and other conditions if the interface provides them.
- Deposit details: save the complete deposit address and any required memo, tag, message, or payment identifier.
- Destination details: save the complete receiving address and associated memo or tag, if applicable.
- Status history: retain the final status and any intermediate status relevant to a delay, refund, manual review, or failed transaction.
- Communications: preserve support case numbers, relevant messages, and requested compliance documents or explanations. Store identity documents separately from routine transaction records and protect them according to their sensitivity.
Saving the exact network is particularly important. The same asset label may be used on more than one blockchain, while a transaction hash is interpreted within a particular network. For Ethereum transactions, official documentation lists fields such as sender, recipient, value, input data, nonce, and the transaction hash; inclusion in a block is a later lifecycle step. This supports recording both the hash and its network rather than treating a copied hash as a complete receipt. [1]
Blockchain Transaction Data
- Deposit transaction hash or TXID: the identifier of the transfer sent to the exchange address.
- Payout transaction hash or TXID: the identifier of the transfer from the service to the destination wallet, when supplied or visible.
- Blockchain or network: write it beside every transaction hash.
- Asset identifier: record the asset name and ticker; for a token, also retain the contract identifier when it is displayed and relevant.
- Sender and recipient addresses: save the full strings, not only abbreviated interface versions.
- Memo, tag, or payment ID: preserve it wherever the network or recipient requires one.
- Amount and fee: distinguish the amount transferred, the network fee, and the amount credited or received.
- Time and status: save the broadcast time, block time where available, and whether the transaction was pending, confirmed, finalized, failed, replaced, or refunded.
- Block reference: block number or height can provide an additional way to locate a confirmed transaction.
Bitcoin documentation explains that the serialized transaction is hashed to create its TXID and that a transaction may contain multiple inputs and outputs. An output is identified through the TXID together with its output index. Consequently, a TXID is a strong lookup key, but the relevant address, amount, output, network, and order context still help establish which part of the transaction relates to the exchange. [2]
Confirmation status should be saved as a changing state, not as a permanent property captured immediately after broadcast. Bitcoin documentation distinguishes an unconfirmed transaction from one included in a block, while Ethereum documentation describes progression from submission to block inclusion and later finality. [3]
Special Case: Monero Payment Proof
Privacy-focused networks can require additional proof data. Monero’s official guide states that publicly visible blockchain data does not reveal payment details in the same way as Bitcoin. To prove a Monero payment, the sender may need the transaction ID, recipient address, and transaction key; the wallet must also have retained the relevant transaction information. [4]
Therefore, when an outgoing XMR payment may need to be proved later, preserve the wallet’s payment proof or transaction key according to the wallet’s official procedure. Because that information can be used to reveal details of the particular payment, it should not be posted publicly or placed in an unprotected general-purpose note.
Claim Register
| Claim | Verification status | Primary source type and name | Publication or update date | Limitation | What could change the conclusion |
|---|---|---|---|---|---|
| A transaction hash should be stored with its network and transaction context, rather than as an isolated string. | Confirmed technical basis; the recordkeeping conclusion is a practical inference. | Official protocol documentation: Ethereum.org “Transactions” and Bitcoin Developer Reference “Transactions.” [1] | No publication or update date stated on the cited pages; checked September 24, 2026. | The documentation describes protocol data, not the fields shown by every exchange or wallet. | A network-specific identifier that unambiguously incorporates the chain, or a standardized multi-chain receipt adopted by the relevant systems. |
| Monero payment proof may require the transaction key in addition to the transaction ID and recipient address. | Confirmed, conditional on proving an outgoing Monero payment. | Official project user guide: Monero “How to prove payment.” [4] | No publication or update date stated on the page; checked September 24, 2026. | The procedure depends on wallet configuration and applies to Monero, not automatically to other assets. | Changes to Monero wallet proof procedures, transaction formats, or the wallet’s handling of transaction keys. |
| For U.S. federal tax records, relevant fields can include asset type, date and time, units, fair market value in U.S. dollars, and basis. | Confirmed for the stated U.S. federal context. | Tax authority guidance: IRS “Digital assets.” [5] | No page update date stated; checked September 24, 2026. | It does not establish requirements in other countries or determine an individual taxpayer’s treatment. | Changes to U.S. tax law, IRS regulations, forms, guidance, or the facts of the transaction. |
| Compliance information requirements cannot be treated as globally uniform. | Confirmed at the jurisdictional level; the exact requirement for an individual order remains conditional. | Intergovernmental regulatory update: FATF “Seventh Targeted Update on Implementation of the Standards on Virtual Assets/VASPs.” [6] | July 16, 2026. | FATF standards and implementation reports do not replace national law or an operator’s risk-based checks. | National implementation, the countries involved, transfer direction, counterparties, transaction risk indicators, and updated compliance rules. |
| Cryptocurrency payments are generally difficult to reverse, and some transaction information may remain publicly visible. | Confirmed as a general consumer-risk statement, subject to differences between networks. | Consumer regulator guidance: FTC “What To Know About Cryptocurrency and Scams.” [7] | May 2022. | Privacy characteristics and recovery mechanisms differ among networks, wallets, custodians, and legal systems. | A protocol-specific reversal mechanism, a cooperative recipient, a custodial intervention, or a legally compelled remedy. |
| There is one universal retention period for all personal cryptocurrency exchange records. | Unknown and not supported. | No single primary source cited here establishes a worldwide period. | Not applicable. | Retention duties depend on jurisdiction, tax status, business or personal use, limitation periods, and pending disputes. | A binding rule applicable to the user’s country and circumstances, or instructions from a qualified local professional. |
Why the Order Record and the Blockchain Record Are Both Necessary
The blockchain record answers a narrow technical question: what transaction was broadcast and what happened to it on that network? The order record answers a different question: why was the transfer made, what asset and network were requested in return, and how did the service process the application?
For example, a deposit TXID may prove that funds reached a particular address, but it does not by itself show the service’s order ID or the originally selected payout network. Conversely, a screenshot marked “completed” is weaker when it omits the payout transaction identifier. The two records corroborate each other.
A practical evidence package can be organized as one folder per order:
- An order receipt or saved page containing the order ID and selected direction.
- A text or structured-data file containing full addresses, networks, amounts, timestamps, and transaction hashes.
- A copy of any invoice, email, status notification, or support conversation connected to an exception.
- A tax or accounting entry containing the applicable valuation data and the source used for that valuation, if required.
- A later confirmation record showing the final on-chain status rather than only the initial pending state.
Screenshots are useful for preserving what an interface displayed, but they should supplement machine-readable text. Long addresses and hashes can be truncated visually, and copying them from an image introduces transcription risk. Exported wallet history, transaction details, and plain-text copies of identifiers are easier to compare character by character.
Accounting and Tax Context
Valuation data is separate from on-chain data. A blockchain can show units transferred but ordinarily does not establish the fiat value a particular authority expects for reporting. For a U.S. federal tax context, the IRS lists the asset type, transaction date and time, number of units, fair market value in U.S. dollars, and basis among the information needed for digital-asset calculations. [5]
Where valuation records are needed, retain the currency, timestamp, valuation method, and identifiable source used. This is a documentation step, not a prediction of the asset’s future price. Requirements outside the United States may use different valuation rules, transaction classifications, retention periods, and reporting forms.
Fees also need clear labels. A service fee shown in an order, a blockchain network fee, and a difference caused by an exchange-rate update are not necessarily the same item. Saving the interface’s actual breakdown prevents a later calculation from assigning an unsupported explanation to the difference between the sent and received amounts.
Data That Should Not Be Added to an Exchange File
Do not store a seed phrase, private key, wallet password, or authentication backup code beside the order records. A recovery phrase controls the wallet rather than documenting a transaction. Ethereum’s security guidance warns that anyone who obtains a recovery phrase or private key can access the corresponding accounts and that legitimate support should not request those secrets. [8]
If a support conversation asks for wallet secrets, remote device access, or an unexpected additional crypto payment, stop and verify the communication through the service’s known interface. Phishing pages can imitate an order-status or support page, so reopening a service through an unsolicited message creates a different risk from checking a transaction through a blockchain explorer. FTC guidance specifically warns against clicking unexpected links and describes impersonation as a common crypto-scam method. [7]
Practical Meaning for an Ordinary User
The minimum useful package is the order ID, exchange direction, exact networks, full deposit and destination details, both transaction hashes where available, amounts, fees as displayed, timestamps, and final status. Add valuation records when required for accounting or tax purposes, and preserve payment-proof material for networks where public transaction data is insufficient. This is general documentation guidance, not personal legal, tax, or investment advice.
Before creating a new order, check the currently available exchange directions, networks, and order requirements. Availability and verification conditions should be confirmed at that time because they can depend on the selected direction and the results of compliance checks. The link is a practical next step, not evidence for the claims above.
Risks and a Repeat-Check Procedure
- Wrong network or address: verify the full destination address, selected network, and required memo or tag before sending. Cryptocurrency transfers are generally difficult to reverse, and recovery may depend on the recipient’s cooperation. [7]
- Pending or replaced transaction: do not treat a broadcast notification as final settlement. Recheck the transaction on the correct network and record its later status.
- Public exposure: addresses, amounts, and transaction relationships may be visible on public blockchains. Keep the order-to-identity connection in protected storage rather than publishing the complete evidence package. [7]
- Phishing: obtain transaction data from the wallet, the known order page, or an independently opened explorer. Do not enter a seed phrase to “verify” or “release” an exchange.
- Volatility: if a fiat valuation is required, capture the relevant value and timestamp at the required point in the transaction. Reconstructing it later can produce a different result because market values change.
- Regulatory variation: compliance and reporting rules differ among countries, and FATF reporting continues to identify uneven implementation across jurisdictions. [6]
Dynamic data should be rechecked in a fixed order: first confirm that the order ID opens the intended application; then verify each transaction hash on the named network; compare the complete addresses, asset identifiers, amounts, and memo fields; record the current confirmation or finality status; and finally review the current tax, compliance, and retention rules applicable to the relevant jurisdiction. If the service record and blockchain data conflict, preserve both versions and the time at which each was observed rather than overwriting the earlier evidence.