A clear Solana transaction history connects network activity with the records that explain why a person used a particular service. It can help you research a purchase, withdrawal, token interaction, or account problem without treating every visible movement as a separate financial event.
Start by identifying the specific business, product, or proceeding you are researching. Owning SOL or a token on Solana does not establish a claim. Blockchain data alone cannot establish legal ownership, eligibility, or a legal loss amount. The Solana class action research guide provides the wider context; the following process focuses on organizing the facts you can document.
Write a scope note and list your sources
Describe the question in one or two sentences. For example, you might want to reconcile withdrawals from a particular account during a stated month. Include the approximate dates, account labels, services involved, and documents already available. Avoid putting an assumed explanation into the question itself.
Create a source list covering wallet histories, exchange exports, receipts, monthly statements, and relevant correspondence. Record the exact network shown by each source. Keep mainnet records separate from test environments and from any other network on which a similarly named asset appears.
If a particular proceeding is part of the research, preserve its identifying documents alongside the scope note. Keep any stated transaction period separate from the period you collect to understand surrounding events. The class action research overview can help you organize the proceeding's identity and the questions that remain open.
Use the transaction signature as a reference
Solana's official transaction lookup documentation describes looking up a confirmed transaction by its signature. The returned record can include a slot, block time, and transaction metadata. Its examples show fee, error, instruction, and balance information. Block time or metadata can be unavailable, so a missing field should remain visibly missing.
Save the full signature exactly as shown, together with the network and the source you used to view it. A shortened signature in a screenshot can be useful visually, but preserve the complete identifier in a text field as well. Add the date you retrieved the record.
Record the status displayed at that time. If a lookup does not return the transaction, document the network checked, identifier used, retrieval time, and message shown. A failed lookup alone is not enough to explain what happened to the underlying account entry.
Keep one transaction connected to its component activity
A Solana transaction can contain multiple instructions. The network processes those instructions together; an instruction failure causes the transaction's state changes to revert, while a processed failed transaction can still incur a fee. This is why the transaction's result belongs beside the activity you are describing.
Use one main row for the signature and separate detail rows for relevant asset movements or instructions. Give each detail row the same parent reference. This arrangement lets you explain a complex interaction without presenting every displayed instruction as an independent purchase.
Use cautious descriptions for unfamiliar activity. Write “record displays this program or instruction label” when that is all you know. A friendly label in an explorer may help navigation, but your notes should still retain the underlying identifier and the document that connects it to the service you used.
Identify tokens beyond their display names
Solana token records distinguish the token mint from the token account that holds a balance for a mint and an owner. Preserve the mint identifier and relevant token account information when available. These technical fields describe onchain relationships; they do not decide who has legal ownership or a claim.
In the working ledger, give each asset a name, symbol, mint identifier where applicable, and quantity unit. Keep SOL amounts separate from other token quantities. Do not group entries solely because their symbols match, and do not assign an unfamiliar token a value just because a page displays one.
If an asset appears differently across an application receipt and a public record, save both descriptions and write down the discrepancy. A useful next question is which source establishes the relationship between them. Leave the classification unresolved until supporting material makes the connection clear.
Bring exchange records and receipts into the same timeline
Collect deposit and withdrawal histories, completed trade exports, account statements, and service receipts. Save original confirmation messages that provide a platform reference or transaction signature. Keep correspondence about missing credits, restrictions, or corrections with the relevant account history.
An exchange can record a trade internally without creating a separate public transaction for that customer's trade. Retain the platform's reference even if no signature is supplied. Public activity associated with a service address also does not, by itself, identify the customer account to which the service assigned a balance.
Match records using the strongest available combination of identifiers, network, asset, quantity, and time. Record why you believe two entries describe the same event. If only the amount and approximate date agree, mark the match tentative. This helps a reviewer separate a supported reconciliation from a plausible guess.
Record fees and balance changes separately
Copy the reported network fee with its unit into a dedicated field. If a service receipt lists a withdrawal charge, commission, or another adjustment, preserve that description and amount separately. Do not assume the wallet's total balance change is entirely a fee or entirely an asset transfer.
When you cannot explain a balance difference, keep the before and after values with the transaction details and flag the difference for review. Avoid creating a balancing entry labeled “loss” merely to make the ledger total agree. That would replace a missing explanation with a conclusion.
Keep any later fiat conversion in a separate calculation section. Identify the source, timestamp, currency, and method used for that conversion. A working estimate of value should remain clearly distinguished from an amount documented in an account statement or required by a specific proceeding.
Preserve dates and untouched exports
Build the working timeline in UTC while retaining the original timestamp and timezone from each source. Label what each date represents: a request, account posting, or network record. If the source omits the timezone or time, mark it unconfirmed rather than supplying an apparently precise replacement.
Check the collection boundary
Write down the start and end filters for each download. Check for separate activity tabs, export row limits, and incomplete final days. Overlapping exports can help inspect a boundary, but identify duplicates in the analysis copy. Do not delete entries from the original downloaded file.
Preserve original CSV files before opening them for edits. Import signatures, addresses, and mint identifiers as text. Keep decimal precision and add conversions or labels in new columns. Each important row should point to a source filename and a receipt, reference, or source row where possible.
Keep an export inventory with the requested period, download date, filenames, and observed gaps. If a later export corrects an earlier entry, retain both versions and document the difference. An empty history page should be described as the result of that particular search, with its filters, rather than treated as proof that the account had no activity.
Use an example to check for double counting
Illustrative example: An exchange withdrawal receipt lists a SOL quantity, a service charge, and a signature. A public record shows the referenced transaction, while a wallet history lists the incoming amount. Later, the person moves some SOL to another wallet they use.
The exchange receipt, public transaction, and incoming wallet entry are three sources about one withdrawal. Link them instead of adding them as three acquisitions. Record the later transfer separately and document the relationship between the two wallets. If that relationship is unverified, keep it as an open question rather than assuming either a sale or continued ownership.
Conclusion: preserve context alongside the chain record
Protect the private connection between public addresses and your identity. Share a focused review copy and keep an intact original. This process requires no seed phrase, private key, wallet connection, signed message, or payment. Record uncertainties and missing documents as carefully as the transactions you can match.
Use the claim research document checklist for a final completeness review. For related histories, consult the Bitcoin record organization guide and Ethereum wallet evidence guide. A clear file preserves the source of each observation and gives a reviewer a reliable basis for further questions.
