Bitcoin class action research becomes easier when you can explain what happened to your assets using records that another person can follow. Begin with the particular business, product, or event you are investigating. Owning bitcoin alone does not establish a claim, and blockchain data alone cannot establish legal ownership, eligibility, or a compensable loss.
This guide describes a practical way to organize transaction records without drawing those conclusions. The goal is a traceable account of purchases, transfers, sales, and unresolved questions. The Bitcoin class action research guide provides the broader research context; the steps below focus on preparing the underlying documents.
Define the question before collecting everything
Write a short scope note at the front of your folder. Identify the account or service involved, the event you want to understand, and the approximate period. Use neutral language such as “reconcile withdrawals from Account A during March” rather than a conclusion about misconduct. List what you already know and what remains uncertain.
If you have identified a specific proceeding, preserve the documents that describe it and record where each came from. Keep any stated period separate from your collection period. Collecting a wider range can help explain opening balances and later movements, but it does not expand anyone's eligibility. Use the class action research overview when organizing information about the proceeding itself.
Give the folder a short descriptive name and add a dated index. A simple index can identify each document, its source, the dates it covers, and the question it helps answer.
Pair exchange history with public transaction records
Start with records from accounts you used: trade histories, deposit and withdrawal exports, monthly statements, order confirmations, and support correspondence. Keep account identifiers and the name shown on the statement in a private master file. These materials provide context that a public transaction page cannot supply by itself.
A purchase or sale recorded within an exchange account may be an internal ledger entry, with no separate blockchain transaction for that individual trade. Record the exchange's order or transaction reference even when its blockchain identifier field is blank. Do not invent a hash or assume an absent hash means the trade did not happen.
For withdrawals and deposits, preserve both the platform receipt and any public transaction identifier it provides. Record the selected network exactly as shown. If a service labels an asset “BTC,” verify how that label relates to the network used before combining it with Bitcoin network records.
Read Bitcoin amounts without counting change as another payment
The Bitcoin Developer Guide's explanation of transactions describes inputs that spend earlier outputs and new outputs that receive amounts. A transaction can have multiple outputs, including change returned to the spender. A transaction identifier, commonly called a TXID, identifies the transaction; an output index identifies a particular output within it.
This structure matters when interpreting a withdrawal. The entire transaction's output total need not equal the amount credited to your account. Preserve the specific output that matches your receipt, when you can establish that match, and leave other outputs unassigned. Avoid labeling an unfamiliar output as another payment you made simply because it appears on the same transaction page.
Record the network fee displayed for the transaction separately from any withdrawal or service charge shown by the exchange. Do not allocate the entire network fee to yourself without supporting records. Keep the original units beside every amount, and explain any conversion in a separate calculation column.
Make dates and export boundaries explicit
Use a consistent timeline, preferably UTC, while retaining each source's original timestamp and timezone. Add separate columns for the original value and your normalized value. If a timezone is missing, write “timezone unconfirmed” instead of assigning one because it makes the rows line up.
Label the event attached to each time: order execution, withdrawal request, platform completion, or the block time shown by an explorer. These describe different observations. They should not silently replace one another in your timeline.
Check date filters before downloading. Note the chosen start and end dates, whether the export includes the whole final day, and any page or row limits. Request an overlapping period when necessary, then identify duplicates in the working copy. Preserve the original exports so someone can reconstruct why a boundary transaction was included or excluded.
Preserve the CSV before making a working ledger
Save the original CSV exactly as downloaded. Create a separate copy for sorting, formulas, notes, and category labels. Keep accompanying PDF statements and email receipts in their original available formats. A screenshot can show what you saw, but it should supplement a downloadable record when both are available.
Use columns that make comparisons possible
- Source: account label, original filename, and source row or order reference.
- Timing: original timestamp, timezone, normalized UTC time, and event type.
- Amounts: asset, quantity, currency, fee amount, and the fee's stated description.
- Public record: network, complete TXID, relevant address, and output index if applicable.
- Assessment: proposed match, supporting document, uncertainty, and the next question.
Import identifiers as text so a spreadsheet does not shorten or reinterpret them. Preserve full precision in the source fields. If you round amounts for a readable summary, make that choice visible and retain the unrounded values elsewhere.
Track corrections and unresolved items
Maintain an exception log alongside the ledger. For each unresolved entry, record the source already checked, the information missing, and the next practical step. That step might be locating an older receipt or requesting a fuller account export. Add the date and outcome of each check so later work does not start from the same unanswered question.
Keep corrections visible. If a later statement reverses an earlier entry, preserve both and describe the relationship. If your own classification changes, note the previous label, the new label, and the document that prompted the change. This gives a reviewer a way to follow the explanation without relying on your memory.
Before calculating summary totals, define which entries belong in each category. Keep purchases, sales, transfers, and fees distinct. Review unresolved rows separately so they do not disappear into a confident-looking total that depends on assumptions you have not checked.
Reconcile one movement before expanding the ledger
Illustrative example: An exchange export lists a withdrawal of 0.020 BTC and a separately labeled service fee. A withdrawal receipt supplies a TXID and destination address. The public transaction shows several outputs, one of which matches that address. The wallet history shows an incoming amount at the same destination.
Your task is to compare the documented amounts and identifiers, then write a short explanation of the match. Do not assume whether the export's withdrawal amount includes the service fee; check the export headings and receipt. Keep the exchange row, public transaction, and wallet entry as linked records of the same movement rather than summing them as three purchases or three losses.
If the destination was another wallet you used, record that explanation and its supporting material. If you cannot establish whose address it was, label the relationship unresolved. A neat spreadsheet should make the uncertainty easier to see.
Protect context and document the gaps
A public address is still sensitive when paired with your name and account history. Share only the material needed for a verified purpose, and keep a record of what you shared. Use redacted working copies where appropriate while preserving an intact private original. Review exports for unrelated account details before sending them anywhere.
This organization process requires no seed phrase, private key, wallet connection, signed message, or payment. Public identifiers and records already available from your accounts are the relevant starting materials. If a field is missing, record the missing field and the source you checked instead of trying to manufacture proof.
Use the claim research document checklist to review the folder. For other networks, compare the guide to Ethereum wallet and token records and the guide to Solana transaction histories. Their different record structures call for different matching steps.
Conclusion: make the history reviewable
A useful Bitcoin research file connects each summary statement to a preserved source, keeps dates and units explicit, and names its unresolved questions. Separate observed transactions from your interpretation of them. That approach gives a reviewer material they can examine without treating an address, a balance, or a transfer total as a legal determination.
