Phantom Wallet Tax Reporting: How to Export Transaction History for Crypto Tax Software

A user holds assets across multiple blockchains—Solana, Ethereum, Polygon, Bitcoin—all managed through a single self-custody wallet. Over the course of a year, they execute dozens of trades, receive token airdrops, stake rewards, and send funds between addresses. When tax season arrives, they face a practical problem: tax authorities expect a complete record of acquisition dates, cost basis, disposal proceeds, and gain or loss calculations. The wallet shows balances and transaction hashes, but not the structured data that tax software requires. Extracting and organizing that information accurately determines whether their filing is defensible or incomplete.

Phantom Wallet, as a non-custodial application, does not provide transaction summaries, cost basis calculations, or pre-formatted tax reports. That is by design—the wallet’s function is to secure keys and broadcast transactions, not to act as an accounting system. Users therefore must either manually compile records or use specialized tools to bridge the gap between on-chain activity and tax software requirements. The process is not difficult, but it demands precision. A missed transaction, an incorrect date, or a misidentified asset type can propagate through a tax return and create problems months later.

Understanding what Phantom records and what it does not

Phantom maintains a local history of transactions broadcast from the wallet, including sends, receives, swaps, and interactions with smart contracts. This history is stored on the device and can be viewed within the application by selecting a specific blockchain network. However, the wallet records only information necessary for blockchain confirmation and balance verification. It does not calculate cost basis, track acquisition prices at the moment of purchase, associate dates with market values, or distinguish between different tax event categories.

The distinction matters because tax software needs structured metadata that blockchain transactions do not inherently provide. For example, a swap between Solana and USDC on the Phantom Wallet interface appears as a single transaction with an input token, output token, and transaction hash. Tax software needs the USD value of both the input and output at the moment of the swap, classified as a sale of the input asset and a purchase of the output asset. A token airdrop on the Solana blockchain appears as a received balance, but tax software requires the fair market value on the date received and identification as ordinary income. Phantom does not perform these calculations because it would require market price feeds, currency conversions, and assumptions about user intent.

This limitation is not unique to Phantom; it reflects a fundamental separation between wallet functions and accounting functions. Self-custody wallets prioritize security and user control over asset custody, which means they do not maintain the centralized databases that custodial services can use for reporting. Coinbase, Kraken, and other exchanges maintain complete trade histories and can export tax reports because they control the infrastructure and have every transaction in their own ledgers. Phantom, by contrast, must reconstruct records from blockchain explorers and user actions, neither of which automatically provides the structured data that tax software requires.

Users therefore need a strategy. The most reliable approach is to combine three sources: transaction history exported from Phantom, on-chain data from blockchain explorers, and records of acquisition prices from the moment of purchase or receipt. This three-part process reduces reliance on any single source and creates a more defensible record should questions arise during an audit.

Exporting transaction history from Phantom Wallet

Phantom does not offer a built-in “export to CSV” function that produces a formatted file ready for tax software. Instead, users can access transaction history through the wallet’s interface, manually record relevant details, or use third-party tools designed to read Phantom’s activity. The manual approach is tedious but transparent: opening the wallet, selecting each blockchain network in turn, and recording transaction hash, date, type, amounts, and counterparties into a spreadsheet. This method ensures that the user verifies each transaction and understands its classification, which can be valuable during tax preparation or if questions arise later.

A more practical workflow involves using tax software that integrates with blockchain explorers. Services such as Koinly, CryptoTrader.Tax, and ZenLedger can read wallet addresses and reconstruct transaction history from public blockchains. Users provide the wallet addresses associated with their Phantom instance—one address per network—and the service queries Etherscan, Solscan, PolygonScan, BlockCypher, or other explorers to retrieve all on-chain activity. This automated approach is faster and less error-prone than manual entry, and the resulting CSV or formatted report can be imported directly into tax software.

The critical step is ensuring that all wallet addresses are included. Phantom can generate multiple addresses, particularly through derived keypaths or account creation features. A user who has created several Phantom accounts or used address generation features must identify every address that received, held, or transferred assets during the tax year. Missing an address means missing transactions, which could result in an incomplete tax return. Users should therefore open Phantom, check each account and network for activity, and note the primary address associated with each. Some users maintain a simple spreadsheet listing address, blockchain, and time period of activity to serve as a master inventory.

Once addresses are identified, the user can provide them to the tax software service or manually search them on blockchain explorers. Solscan, for example, displays all transactions for a Solana address in chronological order with timestamps and token values. Etherscan does the same for Ethereum and its layer-two networks. Bitcoin, Litecoin, and other UTXO-based chains have their own explorers. The raw data is sufficient for tax software to begin categorizing transactions, but additional manual work is often required to distinguish between transfers (which may not be taxable events), swaps (which are sales), airdrops (which are ordinary income), and other categories.

Bridging the timestamp and price-basis gap

A transaction hash and timestamp prove that a transaction occurred on a blockchain, but they do not automatically establish the fair market value in the user’s reporting currency. A user acquired one unit of Token X on March 15 and sold it on November 20. The blockchain confirms both dates, but tax software needs the USD (or other applicable currency) value of that token on both dates. If the user purchased through an exchange, they may have a receipt. If they received the token as an airdrop or from another source, they must establish the fair market value on the date of receipt by checking historical price data.

Historical price data is available from multiple sources. CoinGecko and CoinMarketCap both provide free historical pricing APIs. TradingView, Yahoo Finance, and specialized cryptocurrency data providers also maintain archives. For assets that traded on centralized exchanges, the exchange’s historical pricing is often accurate. For illiquid or newly launched tokens, establishing fair market value can be more difficult and may require documentation of the actual price at which a transaction occurred, if the token had any trading activity at all.

The process becomes more complex with staking rewards, airdrops, and other non-market acquisition events. If a user staked Ethereum on Phantom and received rewards over several months, each reward is a separate taxable event requiring a timestamp and the fair market value of ETH at the moment received. If the wallet was involved in a token airdrop, the fair market value on the date the token became tradeable—not the date the claim was processed—is typically required. Users may need to use specialized tools or blockchain explorers to pinpoint the exact moment of receipt and match it to historical prices.

Tax software services often attempt to fill these gaps automatically by querying price data services and applying prices to transactions. However, automated pricing can fail for low-liquidity assets, tokens with limited trading history, or tokens traded on decentralized exchanges where pricing may be ambiguous. Users should therefore verify critical transactions—particularly large sales, acquisitions, or events that significantly affect taxable income—by manually checking prices on the date of the transaction. Services such as Phantom app integration with DeFi platforms means that many swaps will have a recorded on-chain price through the swap contract itself, but that price should be verified against market prices to ensure accuracy.

Categorizing transactions for tax purposes

Tax treatment of cryptocurrency transactions depends on classification. A transfer between two addresses owned by the same person is not a taxable event. A sale or swap results in a capital gain or loss. An airdrop or reward is ordinary income. Staking income is ordinary income. Donations are typically not deductible (under US tax law, cryptocurrency donations do not qualify for charitable deductions in the same way cash donations do). Each category has different reporting requirements and may affect tax liability in different ways.

Phantom’s transaction history does not automatically classify transactions into these categories. A swap appears as a single transaction, but the tax software must know that it represents a sale of one asset and a purchase of another. A received token must be classified as either a purchase, a transfer, or other income. A smart contract interaction might be a swap, a liquidity provision, a claim, or something else entirely. Users therefore need to review the transaction history and manually assign categories where the tax software cannot determine them with certainty.

The classification process is simplified if users maintain clear records at the time of transaction. When executing a swap through Phantom, noting the intent and the assets involved reduces confusion later. When receiving an airdrop or staking reward, recording the date and asset type ensures that the tax treatment can be applied correctly. A simple spreadsheet maintained throughout the year, with columns for date, transaction type, assets, amounts, and notes, can eliminate most classification ambiguity when tax season arrives. By the time data enters tax software, most categories should already be clear.

Some transactions require special handling. A transaction from Phantom that interacts with a lending protocol, for example, might represent a deposit (not immediately taxable), a withdrawal (potentially taxable if the asset appreciated while lent), or a liquidation (potentially taxable and may involve unexpected losses). Transactions involving bridging assets between blockchains may be treated as transfers or may have tax implications depending on the specific mechanics. Users should understand the substance of each transaction before classifying it and should consider consulting a tax professional if any transaction’s treatment is unclear.

Working with specialized tax software and CSV imports

Most cryptocurrency-specific tax software can import transaction data via CSV file, which is useful if data has been exported from Phantom, compiled manually, or retrieved from blockchain explorers. The CSV format varies by software, but typical columns include date, transaction type, asset, quantity, price per unit, counterparty, and transaction hash or exchange name. Users should review the documentation for their chosen tax software to understand the required format before attempting to import data.

The import process itself is usually straightforward: upload the file, verify that transactions were recognized, and allow the software to categorize and calculate gains or losses. However, errors or ambiguities in the source data can propagate through the import. A misformatted date, an incorrect decimal point, a missing transaction, or a misspelled token name can cause import errors or cause transactions to be dropped silently. After import, users should verify that the total number of transactions imported matches the total number of transactions they executed, spot-check a few transactions for accuracy, and review the software’s categorization before generating a tax report.

A common issue is duplicate transactions. If a user imports data from multiple sources—Phantom’s interface, a blockchain explorer, and tax software’s automatic address ingestion—the same transaction might appear twice. Tax software usually includes deduplication tools, but users should verify that duplicates have been removed before finalizing the report. Another issue is transactions that occurred outside Phantom but involve assets managed in Phantom; for example, a token purchase on a centralized exchange followed by a withdrawal to a Phantom address. The purchase and withdrawal are separate transactions, and both must be included in the tax record with correct dates and prices.

Users should also understand how their chosen tax software handles transactions with missing data. If a fair market value for a token on a particular date is unavailable, will the software flag the transaction or attempt to estimate? If a transaction type is ambiguous, will it be classified conservatively or aggressively? If a transaction hash cannot be verified, how does the software handle the discrepancy? These questions should be addressed before relying on the software’s output for tax filing.

Multi-chain complexity and reconciliation

Phantom’s support for multiple blockchains—Solana, Ethereum, Polygon, Bitcoin, and others—means that a user’s taxable activity is distributed across multiple ledgers. A single person might have received tokens on Solana, swapped them for Ethereum assets, bridged those assets to Polygon, and eventually sold on a centralized exchange. Each transaction is on a different blockchain, but they all belong to the same person and must be aggregated into a single tax return. This requires careful address tracking and reconciliation.

One practical approach is to maintain a master address list for the tax year, mapping each address to the blockchain, the Phantom account or seed phrase it derives from, and the time period during which it was active. If an address was associated with multiple networks or if the user created multiple addresses on the same network, this should be documented. When exporting data from blockchain explorers or tax software, the user can then cross-reference the addresses and verify that all relevant addresses have been included and that no addresses from other people have been accidentally included.

Reconciliation also involves verifying that the total holdings match at year-end. If Phantom shows a balance of 10 ETH at the end of the tax year, and the user has made net purchases of 3 ETH (accounting for all buys and sells), then they should have started the year with 7 ETH. If the numbers do not match, it indicates a missing transaction, a misrecorded transfer, or a misunderstanding of the asset’s history. These discrepancies should be resolved before finalizing a tax return. The blockchain itself is the source of truth; if the reconciliation does not match, it means the exported data is incomplete or incorrect.

Users should also be aware that bridging assets between blockchains—converting Ethereum to Polygon or Solana to Ethereum, for example—may involve taxable events depending on the method used. A bridge that converts an asset on one chain to a wrapped representation on another chain is typically not a taxable event, but a swap or liquidity pool interaction used to bridge assets might be. The specific treatment depends on the mechanics of the bridge and the tax jurisdiction. Users should understand the mechanics of each bridge they use and consult a tax professional if the treatment is unclear.

Documentation and audit readiness

Tax authorities do not require users to file cryptocurrency transactions in any particular format, but they expect that records be available, accurate, and consistent. If an audit occurs, the user must be able to demonstrate the source of each figure reported on their tax return. A complete record includes transaction hashes that can be verified on public blockchains, timestamps, asset values, and the basis for fair market value determinations. Users who maintain Phantom Wallet transaction history, blockchain explorer confirmations, and tax software reports are in a strong position to defend their filing.

The audit trail should flow backward from the tax return. A line item on the return referencing a particular asset or amount should be traceable to the tax software report that generated it. That report should reference specific transactions. Those transactions should be verifiable on blockchain explorers using transaction hashes. If this chain can be established, the tax return is defensible. If gaps exist—missing transactions, unexplained amounts, or discrepancies between sources—the audit position weakens significantly.

Users should therefore maintain documentation throughout the year rather than scrambling to reconstruct records at tax time. A simple practice is to save transaction confirmations, blockchain explorer screenshots, and tax software reports in a dated folder. If critical transactions involve off-chain information—such as the intended use of a withdrawal or the identity of a counterparty—noting this at the time of transaction prevents later disputes about substance and intent. For substantial transactions or anything that seems unusual, a brief note explaining the substance can be invaluable during an audit.

It is also worth noting that tax treatment of cryptocurrency continues to evolve. Regulations in the US, EU, and other jurisdictions may change, and prior-year returns might need adjustment if guidance changes. Users should therefore maintain records indefinitely (or at least for the statute of limitations in their jurisdiction) and be prepared to revise past returns if necessary. Professional tax advice becomes increasingly valuable as portfolio complexity increases or if transactions are substantial.

Common pitfalls and how to avoid them

A frequent mistake is treating all received assets as cost-free income without establishing fair market value. If a user receives an airdrop but does not record the value on the date received, they may understate income in the year of receipt and face audit adjustments later. Fair market value must be established for every taxable event, even if the amount seems trivial at the time. Services tracking Solana and other networks have made historical pricing more accessible, but users should verify prices for unusual or low-liquidity tokens rather than relying solely on automated pricing.

Another common error is missing transactions because they occurred on addresses the user forgot about. If a user created multiple Phantom accounts or recovered a wallet from an old seed phrase, transactions on those addresses might not be included in the tax return. Careful inventory of all addresses associated with the seed phrases used during the tax year prevents this problem. Users should also be aware that some interactions—such as approving a token for spending on a DeFi protocol—appear on-chain but are not themselves taxable events. Tax software should filter these out, but users should verify that approval transactions have not been incorrectly categorized as transfers or sales.

Incorrect decimal handling is another source of error. Cryptocurrency amounts are often expressed in different units—satoshis for Bitcoin, wei for Ethereum—and a misplaced decimal can produce wildly incorrect values. When importing data or transcribing transactions manually, careful attention to decimal places is essential. Most tax software includes validation to catch obvious errors, but users should spot-check calculations, particularly for large transactions.

Finally, users sometimes fail to account for cryptocurrency held outside Phantom. If assets were purchased on an exchange, transferred to Phantom, later transferred to hardware storage, or moved to other wallets, the complete history must be included in the tax return. The fact that Phantom does not show an asset’s entire history does not mean that history is irrelevant for taxes. Phantom is one link in a chain of custody that may span multiple platforms and several years. The complete chain is what matters for tax purposes.

Businesswire