Solflare Wallet: Tax Reporting and Transaction Export for Accountants

A cryptocurrency investor holding SOL, staking rewards, and several SPL tokens across the Solana ecosystem faces a practical problem at tax season: how to extract accurate transaction history and cost basis data from their wallet without manually recording hundreds of entries. The Solflare wallet, a non-custodial application built exclusively for Solana, stores private keys locally and does not maintain centralized transaction logs. Users therefore cannot simply download a pre-formatted tax report from a company server. Instead, they must understand what data the wallet contains, how to export it reliably, and which formats accountants and tax software will actually accept.

The distinction matters because incomplete or poorly formatted transaction records create audit risk and can lead to underpayment penalties or, conversely, overpayment of taxes through conservative assumptions. A Solflare wallet user who stakes SOL, receives airdropped tokens, swaps assets on Marinade or Orca, and holds NFTs is generating taxable events across multiple transaction types. Each event has specific tax treatment: staking rewards are ordinary income at the time of receipt, swap transactions are capital gains or losses, airdrops depend on whether they qualify as income, and NFT sales must be matched to cost basis. The wallet interface shows balances and transaction history, but exporting that data in a format that accounting software understands requires both technical knowledge and awareness of what information is actually available.

Understanding what data Solflare wallet stores and exports

The Solflare wallet maintains a complete transaction history on the user’s device because it connects directly to Solana blockchain validators and RPC endpoints. When a user sends SOL, swaps tokens, receives a staking reward, or sells an NFT, the transaction appears in the wallet’s history with a signature, timestamp, and amount. Because the wallet is non-custodial, it does not send this data to Solflare’s servers for archival. Instead, the history is reconstructed by querying the blockchain each time the wallet is opened, relying on the selected RPC node to provide historical data.

That architecture has important implications for tax data export. A user cannot export “everything the company knows” because there is no company database. Instead, the wallet can reconstruct transaction history from the blockchain if the RPC endpoint maintains sufficient historical records, and the user can export what the wallet displays. Most current RPC providers maintain recent transaction history reliably, but guarantees vary. An RPC service that has purged old data will show incomplete history in the Solflare wallet, and the user’s exported data will reflect that gap.

The wallet’s export function typically generates a CSV file containing transaction signatures, dates, types, amounts, and associated tokens or NFTs. The format includes basic fields such as timestamp, from address, to address, amount, and transaction type, but it may not automatically include USD values at the time of the transaction, which is critical for calculating cost basis and capital gains. Similarly, airdrops and certain types of program interactions may not be clearly labeled as separate taxable events.

Users should verify the completeness of exported data before submitting it to an accountant. A practical check is to compare the wallet’s displayed balance of each token with the opening balance implied by the export plus all received transactions minus all spent transactions. If the numbers diverge, either the wallet missed some transactions due to RPC limitations or the export function skipped certain transaction types. A gap of that kind should trigger a manual review or a second export using a different RPC endpoint.

Identifying taxable events in the Solana ecosystem

A single transaction in the Solflare wallet may generate multiple taxable events, and not all events appear as obvious transactions. Consider a user who stakes SOL through Marinade Finance, which uses a liquid staking token called mSOL. The initial swap of SOL for mSOL is a capital transaction (sell SOL, acquire mSOL at cost). Each epoch, Marinade automatically increases the user’s mSOL balance through rebasing. That increase is ordinary income at fair market value on the date of receipt. When the user unstakes mSOL back to SOL, another capital transaction occurs.

A Solflare wallet export will show the initial SOL-to-mSOL transaction clearly, but the rebasing reward may appear as a balance change with no corresponding transaction signature, or it may be visible only by examining the transaction details. The unstaking transaction will be recorded, but the transaction history alone will not identify this as a three-event sequence: a capital sale, an income receipt, and another capital sale. An accountant reviewing the raw Solflare wallet data must understand the economic substance of each DeFi interaction to categorize them correctly.

Swaps on decentralized exchanges such as Orca or Raydium create immediate capital gains or losses. If a user swaps SOL for USDC, the transaction records the SOL sent, USDC received, and any fees. The gain or loss is calculated as (USDC value in USD at the time minus SOL value in USD at the time). The Solflare wallet export shows amounts but not USD prices, so the accountant or the user must look up the exchange rate for each token on the transaction’s date. Batch operations create additional complexity: a swap on Orca might atomically execute multiple intermediate steps to convert from one token to another, and the wallet export must clearly identify which leg is the actual transfer and which legs are routing.

NFT transactions present yet another challenge. When a user buys an NFT on Magic Eden or Tensor using SOL, the transaction shows SOL spent and the NFT received, but the cost basis is recorded only if the wallet or a separate service tracks it. When the NFT is sold, the capital gain or loss is the sale price minus the original cost. If the cost basis is missing from the export, the accountant cannot calculate the gain correctly. Many NFT traders maintain separate spreadsheets for this reason: they record the purchase price, acquisition date, and sale date manually because the wallet export alone does not preserve all necessary information.

Exporting data from Solflare wallet for tax software

The most common export path is to use the Solflare wallet’s built-in CSV export feature, which generates a file containing transaction data that can be imported into accounting or tax software such as CoinTracker, Koinly, or TaxBit. The process typically involves opening the wallet, navigating to the transaction history or portfolio section, and selecting an export option. The resulting CSV file should contain columns for date, transaction type, amount, token or NFT, and transaction signature or ID.

Before submitting the export to an accountant or importing it into tax software, users should inspect the file in a spreadsheet application to verify completeness. Check that the date range covers the entire tax year, that transaction counts match what the wallet displays, and that all token symbols are spelled correctly and consistently. If the Solflare wallet export appears incomplete, the user can try exporting again after forcing a refresh of blockchain data, or they can use a secondary tool such as Helius or Solscan to manually reconstruct missing transactions.

Third-party tax software platforms often accept Solflare wallet exports directly, but compatibility varies. Software designed for Ethereum or Bitcoin may not understand Solana-specific transaction types, such as token minting or NFT compression. Before choosing a tax accounting tool, verify that it supports the Solana ecosystem and can parse the specific token and NFT formats used by the user. Some platforms require additional manual data entry for non-standard transactions, which increases the risk of error.

A practical workflow is to export from the Solflare wallet, import the CSV into a staging spreadsheet, add a column for USD value at transaction date (either looked up manually or from an API service), and then import the enriched file into tax software. This intermediate step catches formatting errors and ensures that cost basis calculations are grounded in actual market data rather than estimates or wrong prices. Many accountants prefer to receive enriched CSV files rather than raw wallet exports because they reduce ambiguity.

Handling staking rewards and other income events

Staking SOL directly through the Solflare wallet generates regular income in the form of new SOL tokens. The amount depends on the validator’s fee, the total amount staked on the network, and when the user’s stake first became active. Each time a new epoch begins, staking rewards are deposited as separate SOL transactions in the wallet. From a tax perspective, each reward is ordinary income taxed at the fair market value of SOL on the date received, not the date claimed or unstaked.

The Solflare wallet correctly records staking rewards as distinct transactions, but the user must ensure that every reward is included in the export. Some validators or staking protocols introduce delays or automatic restaking that can obscure reward transactions. If a user enables auto-compound or restaking through a protocol like Marinade, the reward structure changes: instead of receiving raw SOL, the user receives mSOL, which is a different asset with its own cost basis and tax treatment.

Airdrops, such as the historical Cope airdrop or other Solana ecosystem distributions, are treated as ordinary income at fair market value on the date received. Many airdropped tokens land in the Solflare wallet as incoming transactions, and they should appear in the export. However, if an airdrop was claimed through a separate interface (a website or a separate claim transaction), it may not automatically appear in the wallet unless the transaction is broadcast to the Solana blockchain. The user should verify that all expected airdrops are present in the export.

Unclaimed rewards or airdrops that the user never claims do not create a tax liability. However, the moment a token or reward is claimed and transferred to the wallet, it becomes a taxable event. This means a user who claims an airdrop in year two but it was dated in year one should report it on the year-two tax return, not year one, because that is when the income was actually received into their possession.

Multi-wallet and cross-platform reconciliation

Many Solana users hold assets across multiple Solflare wallet instances, on different devices, or through different seed phrases. If a user has a main Solflare wallet on their phone, another on a Chrome extension, and a hardware wallet connected through Solflare on a computer, they may accidentally export data from only one instance. The tax export must cover all wallets that the user owns or controls during the tax year, not merely the most active one.

A comprehensive approach is to list all Solana addresses and wallets the user controlled during the tax year, export transaction history from each one separately using the Solflare wallet or through Solscan, combine the exports into one master file, and remove duplicates by transaction signature. This is essential if the user migrated funds between wallets, used multiple addresses for different purposes (such as one for staking and another for trading), or rotated through different seed phrases.

If the user also holds SOL or SPL tokens on other wallets such as Phantom or Magic Eden, those holdings and transactions must be exported separately and combined with the Solflare wallet data. A single comprehensive CSV file that includes all transactions from all addresses associated with the user will give the accountant a complete picture and reduce the risk of double-counting or missed income events.

Working with accountants who understand Solana and web3 wallet complexity

Not all accountants are familiar with the Solana ecosystem or with the specific transaction types that occur in a Solflare wallet. Before submitting data, clarify with your accountant whether they have experience with non-custodial wallets, decentralized finance, staking, and NFTs. An accountant who is accustomed to traditional stock trading may not immediately understand the difference between a token swap (capital gain) and a staking reward (ordinary income), or they may misclassify Solflare wallet transactions because they are unfamiliar with Solana-specific mechanics.

If your accountant lacks web3 experience, consider providing them with a narrative document explaining key transactions: “On [date], I staked X SOL and received Y mSOL in exchange, which is a capital sale. Each epoch, my mSOL balance increases by Z units as rebasing rewards, which is ordinary income. On [date], I unstaked by exchanging Y mSOL for X+R SOL,” where R is the accumulated rewards. This narrative helps the accountant understand the substance of each transaction type and correctly categorize it for tax purposes.

A solflare wallet export is a starting point, not a complete tax document. The user or their accountant must verify that all transactions are included, that tax treatment is correct, and that cost basis data is complete. If the wallet export does not include USD values, fees, or token acquisition details, those must be researched and added before the data is submitted to tax authorities. The responsibility for accuracy ultimately rests with the taxpayer, even if a wallet or accounting software was used to generate the initial export.

Software and tools that complement Solflare wallet exports

Several third-party platforms can enhance or cross-verify a Solflare wallet export. Helius is a Solana-specific RPC and indexing service that maintains deep transaction history and can provide detailed data for addresses. Solscan is a public block explorer that allows users to view transaction history and export it in various formats. Magic Eden and Tensor, the leading Solana NFT marketplaces, each offer transaction export features for NFT sales and purchases. For token prices on specific dates, services such as CoinGecko or Messari maintain historical price data by date and token.

A practical multi-step verification is to export from the Solflare wallet, compare the transaction count and token balances with Solscan, and then manually spot-check a few transactions by looking them up on the block explorer to confirm amounts and dates are correct. If the Solflare wallet export is missing transactions, use Solscan or Helius to retrieve them manually. If USD values are needed, use CoinGecko’s price history API or a similar service to look up the exchange rate for each token on the transaction date.

For NFT transactions, specialized NFT accounting tools such as NFT Loss or GemCase can help match purchases to sales and calculate gains and losses correctly. These tools typically integrate with block explorers and can import transaction data automatically, though manual verification is still recommended. The goal is to build a comprehensive, cross-verified dataset that an accountant can rely on and audit authorities can accept if questions arise.

Common mistakes and how to avoid them

One of the most frequent errors is assuming that the Solflare wallet export includes all transactions automatically. Users who export once and submit that file without checking for completeness often miss transactions that occurred before the export was performed or that were generated by interactions outside the wallet interface. Always export at the end of the tax year (or after the year has ended), verify that the date range covers the entire period, and compare the export against known activity.

Another mistake is treating staking rewards or rebasing tokens as capital gains. If a user receives a staking reward, it is ordinary income, not a capital gain. If the user later sells that reward (e.g., by converting the staking token back to SOL), then the second event is a capital gain or loss. Conflating the two creates incorrect tax liability. Review the Solflare wallet export line by line with a clear understanding of what each transaction type represents.

A third error is ignoring airdrops or claiming that unclaimed tokens have no tax impact. An airdrop becomes a taxable event the moment it lands in the wallet and is available to the user, not when it is sold. If a user received an airdrop but never claimed it or transferred it, they should not report a loss when the airdrop expires; instead, they should report ordinary income on the date the airdrop was distributed, as if they had received it even if they chose not to act on it.

Finally, users often lose cost basis information for NFTs because the Solflare wallet does not store purchase prices. Always maintain a parallel spreadsheet or document recording the purchase date, purchase price in SOL or USD, the NFT name or token ID, and the date sold, along with the sale price. This record is easier to maintain than to reconstruct after the fact, and it provides a clear audit trail if tax authorities question the reported gains.