Solflare Wallet Forensics: Extracting Your Full Transaction History for Legal Disputes and Scam Recovery

A user discovers that SOL tokens have moved from their Solflare wallet to an address they did not authorize, or they have sent funds to what appeared to be a legitimate dApp but turned out to be a phishing site. The immediate question is not recovery—on an immutable blockchain, reversals are rare—but evidence. Law enforcement, financial advisors, or civil litigation may require proof of the transaction, the timing, the destination, and the chain of events leading up to the loss. A browser-based wallet like Solflare stores transaction history locally and provides access to the underlying Solana blockchain through RPC queries, but extracting that information for formal documentation requires method and precision.

The difference between knowing a transaction happened and proving it to a third party is the difference between a transaction hash and a complete forensic record. Solflare itself does not retain server-side records of user activity, which is a privacy feature but also means that if a browser is wiped, the local history is gone. The wallet can export transaction data, but the export must be cross-verified against on-chain evidence, timestamped correctly, and presented in a format that satisfies the requirements of the investigating authority or legal process. This article walks through the practical steps for gathering, documenting, and preserving that evidence within Solflare and at the Solana blockchain level.

Understanding Solflare’s local storage and blockchain separation

Solflare is a non-custodial wallet, meaning the application does not hold private keys on a server or maintain a persistent record of which accounts belong to which user. Transaction history visible in the wallet is downloaded from the Solana blockchain and stored locally in the browser’s storage, typically using encrypted local storage mechanisms. If the browser cache is cleared or the device is wiped, that local history vanishes, but the transactions themselves remain permanently recorded on the Solana blockchain and are queryable through any RPC node.

This separation creates both a challenge and an opportunity for evidence gathering. The challenge is that relying solely on Solflare’s display means depending on one interface’s record. The opportunity is that the complete transaction history is independently verifiable and immutable. A transaction on Solana cannot be deleted, modified, or hidden once finalized. The wallet shows a subset of that data in human-readable form; the blockchain stores the authoritative record. For legal or investigative purposes, both sources should be examined and cross-referenced.

When gathering evidence of a scam or unauthorized transaction, start by exporting what Solflare displays locally, then verify each transaction against on-chain data using a public block explorer or private RPC node. This two-layer approach prevents reliance on a single source and ensures that the evidence withstands technical scrutiny. If the wallet has been reinstalled or the device wiped since the incident, the local history will be lost, but the blockchain queries will recover the complete record.

The specific RPC endpoint used also matters for forensic purposes. Solflare allows custom RPC node configuration, which means a user can direct queries to a specific node operated by the Solana Foundation, a third-party provider, or a self-hosted instance. For evidence that may be challenged, using a widely trusted and archived node is preferable to a commercial service that might go offline or change its records. Genesysgo’s archival node, the official Solana mainnet nodes, or a user’s own locally synchronized node all qualify.

Extracting and documenting transaction history within Solflare

The first step is to access the transaction history within the Solflare wallet interface itself. Open the wallet, navigate to the account in question, and display the complete transaction list. Solflare allows filtering by token type and date range, which is useful for focusing on the relevant period. Most wallets display transactions in reverse chronological order, with the most recent at the top. For evidence purposes, export or screenshot this list in chronological forward order to establish a clear narrative timeline.

Document the following details for each transaction in question: the timestamp displayed by Solflare (noting that this is derived from the blockchain timestamp, which is the authoritative record), the transaction type (send, receive, swap, stake, or instruction), the amount of SOL or tokens transferred, the sender and recipient addresses, and any transaction hash or signature identifier. Solflare displays the transaction hash or signature, which is the unique identifier for that transaction on the blockchain. This is the most critical piece of information because it allows verification against independent sources and proof that the transaction definitively occurred.

Export this information into a document or spreadsheet that preserves the original data without editorializing. Include columns for timestamp, transaction hash, sender, recipient, amount, token, and notes about the transaction’s purpose as known to the user. If the wallet has been reinstalled or the device wiped, this local export will not be available, but the transaction hashes can be recovered from Solana blockchain explorers. For each transaction hash, use a public explorer such as Solscan to retrieve and verify the on-chain data independently.

Critical note: Do not edit or alter the exported data, even if timestamps appear inconsistent or amounts seem wrong. Record exactly what Solflare displays and what the blockchain confirms separately. Discrepancies between local display and on-chain records should be noted as separate findings, not reconciled by adjusting one or the other. If Solflare shows a transaction that does not appear on-chain after several confirmations, that is evidence of a display error and should be flagged for investigation.

Verifying transactions through RPC queries and block explorers

Once the transaction hashes are documented, query the Solana blockchain directly to retrieve the full transaction details. The most accessible method is to use a public block explorer such as Solscan, Anchor, or SolanaFM. Enter each transaction hash into the explorer’s search field, and the tool will display the complete transaction record, including sender, recipient, amounts, fee, slot number, timestamp, and transaction status.

For higher assurance or when dealing with large transactions, consider querying an RPC endpoint programmatically using tools such as curl or a language like Python. The Solana JSON-RPC API provides a getTransaction method that returns the complete parsed transaction, including the program involved, instruction data, and any token transfers. This can be queried from a public RPC endpoint or a user’s own node. The advantage of direct RPC queries is that they bypass the block explorer’s display layer and access the raw blockchain data, which may be important if the explorer is itself compromised or unavailable.

Example query using curl to retrieve a transaction from a public RPC endpoint: curl https://api.mainnet-beta.solana.com -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"getTransaction","params":["<transaction_hash>","json"]}'. The response will include the complete transaction structure, including all accounts affected, token balances before and after, and the exact instruction executed. For evidence documentation, save the full JSON response alongside the user-friendly summary from the block explorer.

Timestamp verification is critical because it establishes when the transaction occurred and can corroborate or contradict claims about fraud, authorization delays, or market conditions at the time. Solana blockchain timestamps are Unix epoch values in seconds, stored in the block header. A block explorer or RPC query will display this as a human-readable timestamp, but for formal documentation, include both the raw Unix timestamp and the converted local time (noting the timezone used for conversion). If the wallet display shows a different time than the blockchain record, investigate whether the difference is due to timezone conversion, network synchronization delay, or a display error.

Reconstructing the transaction path and identifying counterparties

Once individual transactions are verified, construct a timeline that shows how funds moved through accounts and addresses. If the user sent SOL to address A, which then forwarded it to address B, and finally to address C, document each step separately with timestamps and transaction hashes. This chain of custody is critical for understanding how funds were diverted and may help identify where the money ultimately ended up.

For addresses that appear suspicious, label them consistently in your documentation and track all transactions involving them. Use on-chain analysis tools such as Solana Compass or Hyperspace to identify whether an address has received funds from multiple victims or has behavioral patterns consistent with a known scam or money laundering operation. Do not rely on a single tool’s classification; cross-check multiple sources and document the methodology used to identify the suspicious address.

If the transaction involved a token swap or interaction with a dApp, the Solflare display may not show all intermediate steps. For example, a swap through a DEX such as Marinade, Orca, or Raydium involves multiple transactions: approval of token spending, the swap instruction itself, and potentially token transfers between intermediate accounts. Query each component transaction separately using the transaction hash and document the full sequence. This prevents the appearance of missing or inconsistent token amounts if only one part of the swap is reviewed.

When documenting the counterparty or recipient address, note whether it is labeled in Solflare, on a block explorer, or known through external research. If the address belongs to a known exchange, marketplace, or validator, document that association with a source. Avoid making assumptions about addresses without evidence. An address associated with a scam operation may have a legitimate explanation; conversely, a new or seemingly unrelated address may belong to a money laundering intermediary. The forensic record should preserve what is known separately from what is inferred.

Offline transaction signing and private key verification for authenticity

If the question is whether a transaction was actually authorized by the account holder or whether it was forged, examining the transaction’s cryptographic signature provides independent verification. A Solana transaction is signed with the private key of the account that authorized it. Solflare supports offline transaction signing through hardware wallets such as Ledger, which means a transaction could be signed without the private key ever touching the internet-connected device. For users with Ledger integration, this can be verified by checking whether the transaction was signed via the Ledger device at the time and whether the Ledger’s transaction logs show confirmation or rejection of that specific instruction.

If the user claims they did not authorize a transaction, the forensic question becomes: Could the private key have been compromised? If the wallet was backed up in a text file, email, cloud storage, or given to anyone else, an unauthorized transaction may have been signed by someone with access to the key. If the wallet was created within Solflare without a hardware wallet backup, and the user claims no phishing or malware, the transaction itself proves that someone with access to the private key executed an instruction on the blockchain. That someone may be the authorized key holder or an attacker who stole the key.

Solflare’s phishing protection can help determine whether the transaction was initiated from a known malicious site. The wallet warns users when connecting to suspicious dApps, but warnings can be ignored or circumvented through social engineering. If a user initiated a transaction through a browser without Solflare’s phishing warning, it suggests the site may not have been flagged as malicious, or the user accessed Solflare directly without going through the dApp connection flow. Document how the transaction was initiated: through Solflare’s built-in UI, through a connected dApp, through a hardware wallet signing device, or through another method.

For particularly high-stakes evidence gathering, preserve the entire browser state at the time of the incident if possible. Screenshots of the Solflare interface, the dApp that was accessed, the browser URL, and any error messages can corroborate the forensic timeline. If the device is suspected of having malware, preserve a disk image or backup before conducting further investigation, as additional queries may inadvertently alter logs or leave traces of investigative activity.

Preparing evidence for law enforcement and legal proceedings

Law enforcement, financial institutions, and courts require evidence in specific formats with clear chain of custody and minimal interpretation. When preparing a forensic report for these purposes, include the following elements: a chronological narrative of the incident, a detailed transaction list with transaction hashes and blockchain verification, screenshots of Solflare and block explorer displays, and a separate analysis section explaining the significance of each transaction.

The narrative should state facts without speculation. For example: “On 2024-01-15 at 14:32 UTC, a transaction was initiated from account [public_key] transferring 10 SOL to address [recipient]. The transaction hash is [hash]. This account is associated with [known service or suspicious behavior], based on [source].” The second part of the narrative should explain what the account holder claims happened and what evidence contradicts or supports that claim. If the claim is that the account was compromised, the evidence should address when the compromise likely occurred, what access an attacker would have needed, and what the user did to prevent it.

Include raw data exports from Solflare and RPC queries in an appendix, with annotations explaining how each piece relates to the incident. For block explorer screenshots, include the URL and timestamp of when the screenshot was taken, as blockchain explorers can be forked or compromised and a record of exactly which version was consulted is important. When presenting evidence to download solflare wallet extension support or other parties, explain where the data came from and how it was obtained, but avoid suggesting that the wallet itself was the authoritative source for historical reconstructions conducted after the device was wiped.

Different jurisdictions and organizations have different requirements for digital evidence. Some may require notarization or third-party verification of the transaction data. Others may accept a simple declaration under penalty of perjury. Consult with legal counsel before submitting evidence to understand what format and authentication is required. An exchange or payment processor may have its own standard format for evidence submissions; use their template if available. If no template exists, follow the format above and clearly separate what is observable on the blockchain from what is interpretation or claim.

Preserving evidence and preventing further loss

Once evidence is gathered, preserve it in multiple formats and locations. Export transaction data to CSV or PDF, save block explorer screenshots as images or PDFs with metadata, and document the URLs and RPC endpoints used for verification. Store copies offline in encrypted form, on encrypted external drives, or with a lawyer or trusted third party. Do not rely on cloud services alone, as those can be hacked or accounts can be compromised.

If the wallet is still active and funds remain in it, consider whether to transfer the remaining balance to a new wallet created on a secure device with a new seed phrase. This prevents further loss if the original device or browser is compromised. Document the transfer transaction and the reason for it in the forensic record. If moving the funds, do not assume this absolves the original account or wallet; document why the move was necessary and what security measures led to the decision.

For ongoing prevention, update the browser and operating system, scan for malware using a dedicated antivirus scan from an external device, and audit all browser extensions for suspicious additions. If a hardware wallet was used and was not compromised, create new hardware-backed accounts and migrate funds gradually. If the compromise was at the software level—a malicious browser extension, malware, or phishing—a new browser profile with only essential extensions may be appropriate before resuming normal activity.

In some cases, the evidence gathered may not lead to recovery but can support a claim in civil court against a payment processor, exchange, or service that failed to prevent fraud. Documenting the complete chain of events and the evidence preserved at each step strengthens such claims. The more thorough the evidence collection at the outset, the more credible the forensic record becomes if it is later needed for litigation or regulatory investigation.

Leveraging batch transactions and RPC data for complex incident analysis

Some scams involve multiple coordinated transactions that appear separate but form a unified attack. A user might receive a seemingly legitimate instruction to sign a batch of transactions, unaware that one of them transfers funds to an attacker. Solflare’s batch transaction support allows multiple instructions in a single transaction, which can obscure the full scope of what is being authorized. When reconstructing such incidents, query the full transaction object, not just the summary display.

A single transaction hash can contain dozens of instructions. A block explorer may only display the most visible transfers, hiding token approvals or internal contract calls. For thorough forensic analysis, parse the full transaction JSON to identify all instructions and all accounts affected. Tools such as Solana’s CLI or Python libraries such as solders can help parse this data programmatically. If the user is uncertain what a batched transaction contained, this analysis can reveal whether malicious instructions were bundled with legitimate ones.

Comparing the RPC data with what Solflare displayed at the time of signing can also reveal whether the wallet’s preview was incomplete or misleading. If a user claims they were not shown a particular token transfer during transaction signing, the RPC data can confirm whether that instruction was present in the transaction or whether Solflare’s preview interface omitted it. This information can be valuable in determining whether the user was negligent or genuinely deceived.

For sophisticated investigation, cross-reference transaction data with on-chain program state. For example, if the transaction claims to have authorized a token transfer, verify that the token account’s authority was actually updated by querying the token account’s state before and after the transaction. If the RPC data shows an instruction that should have changed program state but the state was not updated, it suggests the transaction failed at some point. Block explorers typically indicate transaction status, but raw RPC queries can provide more granular information about instruction success or failure, which is important for understanding the full impact of an attack.