Ethereum lawsuit research can involve wallet activity, exchange account entries, token movements, and communications about a particular service. Those records answer different questions. A transaction may help establish what a network recorded, while a statement or receipt helps explain how that activity relates to an account and a person.
Begin with the specific event or proceeding you are investigating. Holding ETH or an Ethereum token alone does not establish eligibility for a lawsuit or settlement. Blockchain data alone cannot establish legal ownership, eligibility, or loss. The Ethereum class action research guide introduces the wider research process; this article focuses on making the records understandable.
Create an inventory of accounts, networks, and assets
List the services and wallets you used during the period you are reviewing. Give each a private label, such as “Exchange A” or “Wallet B,” and record where you found its history. Keep account identity documents in a separate private section so they remain connected to the research without appearing in every working spreadsheet.
Record the exact network displayed in each source. Do not merge records just because their addresses look alike or their assets share a familiar symbol. Preserve the asset name, symbol, and contract address when available. If the source does not identify the network, make that an open question.
Build a short scope note describing the service, approximate dates, and activity you need to explain. Keep legal research about a particular proceeding in its own section, using the class action research overview to organize the questions that transaction records cannot answer.
Read the transaction and its receipt together
Ethereum transaction fields include the sending address, destination, and a value field for native ETH. In a raw JSON-RPC response, value is a hexadecimal quantity denominated in wei; an explorer may display a converted ETH amount. Preserve the original value and its unit, and document any conversion. The destination can be a contract, and the value field does not summarize every token movement associated with an interaction. Copy the record accurately before assigning a business meaning to it.
The Ethereum.org reference for transaction receipts describes fields including the transaction hash, block number, gas used, generated logs, and execution status. For modern receipts, status distinguishes success from failure. Receipt data helps explain a transaction's execution; it does not establish that every expectation described by a website or customer was satisfied.
Preserve the transaction hash and the receipt together. Add a plain-language note such as “receipt reports successful execution” or “receipt reports failure.” Avoid replacing that narrow observation with “purchase completed” unless account or application records support the description.
Give token activity its own rows
ERC-20 token contracts define separate transfer and approval events. An approval concerns permission to spend tokens; it should not automatically be recorded as a purchase or transfer of the approved amount. Keep the event label and contract identifier beside your interpretation so another reader can check how you classified it.
When an explorer presents several token events under one transaction, use separate detail rows tied to the same transaction hash. Preserve the displayed token quantity and its unit. Do not collapse different tokens into one quantity column that can accidentally be added together.
For an unexplained entry, record the displayed label, full contract address, and reason it remains uncertain. A recognizable name, logo, or symbol is not enough for you to decide that the entry represents the asset you intended to use. Look for an independent connection in your receipt or account history before grouping it with other records.
Keep fees separate from transferred value
Copy the actual fee information reported by the transaction record or receipt into a fee section. Preserve its units. Where available, retain gas used and effective gas price as supporting fields. A gas limit or maximum fee setting describes a limit and should not be substituted for the amount actually charged.
If an exchange or application lists an additional charge, keep that charge under the source's own description. Do not assume that a platform withdrawal fee and a network execution fee are the same entry. Similarly, do not add both merely because both documents mention a fee; first determine what each amount describes.
A failed interaction deserves a record too. Preserve its reported status and any reported fee, then explain the result in a note. Leave questions about recoverability or a legal loss calculation for the requirements of the particular matter being reviewed.
Reconcile wallet evidence with offchain history
Download trade exports, deposit histories, withdrawal histories, monthly statements, and purchase confirmations from accounts you used. Save support messages that explain a delay, reversal, account restriction, or corrected entry. Keep the date and source attached to each message.
An exchange trade can be reflected in the exchange's own ledger without producing a separate public transaction for your trade. Preserve its order identifier even if no transaction hash exists. Conversely, a public transaction involving an exchange address does not by itself identify which customer account should receive credit.
Match records using several fields together: platform reference, network, transaction hash, addresses, asset, amount, and approximate timing. Describe the evidence for each match. If two entries share an amount but lack stronger identifiers, call the match tentative rather than quietly merging the rows.
Build a timeline that preserves original timestamps
Choose UTC for your working timeline and retain a separate column containing each timestamp exactly as supplied. Record the source timezone and the event represented, such as a submitted request, an exchange posting, or a block timestamp. Mark missing timezone information as unresolved.
Document the date filters used for every export. Check whether the final date includes the whole day, whether the account has separate history tabs, and whether there are pagination limits. Collect an overlapping range when needed, then mark duplicates in the working file while keeping the original exports intact.
Preserve a source copy and an analysis copy
Leave original CSV files unchanged. Use a second copy for conversions, categories, and reconciliation notes. Import hashes and addresses as text, retain decimal precision, and identify any rounding used in the readable summary. Keep receipts with the source documents so every important ledger row points back to material that supports it.
Add an exception log for gaps such as a missing receipt, an unexplained token, or an uncertain network. Assign each gap a short reference and record what you checked. If you request a corrected export, preserve the request and the response alongside the original file. When new information changes your interpretation, date the change and explain why. This makes the research easier to resume and helps another person understand which conclusions are supported and which still depend on missing context.
Explain a complex interaction without overstating it
Illustrative example: A person preparing records finds one transaction hash with a small ETH value, two token events, and a reported execution fee. An application receipt describes the interaction as an exchange of Token A for Token B. The working ledger has one transaction header, two asset detail rows, and a separate fee field.
The reviewer can then compare the application receipt with the reported token activity. If the quantities differ, the note names the difference and the source that needs clarification. It does not force the figures to agree or treat the sum of all displayed amounts as the person's loss.
The same approach helps with transfers between wallets a person used. Preserve both sides and document the relationship. Avoid treating a movement as an additional purchase merely because it appears in another wallet's incoming history.
Share a focused file and retain the uncertainties
Public addresses become more revealing when combined with names and account documents. Prepare a limited review copy and preserve an intact private master. Document any redactions and keep the supporting originals available for an appropriate verified request. This research workflow requires no seed phrase, private key, wallet connection, signed message, or payment.
Review completeness with the claim research document checklist. If your history includes other assets, the Bitcoin transaction record guide and Solana transaction history guide explain how to adapt the ledger to their records.
Conclusion: connect every interpretation to its source
A useful Ethereum research file preserves network details, original exports, transaction receipts, and account context. Its explanations distinguish observed fields from inferred relationships and unresolved questions. That clarity makes the file easier to review while leaving ownership, eligibility, and legal loss to the evidence and rules relevant to the particular proceeding.
