An accountant receives a tax return package from a client who holds cryptocurrency in a browser wallet. The client has made trades, received staking rewards, and moved funds between multiple addresses over the previous year. When asked for transaction history, the client provides a text file with blockchain transaction hashes and approximate dates, but no clear cost basis, no records of exchange rates at the time of acquisition, and no unified ledger connecting wallet addresses to specific holdings or disposal events. The accountant’s standard software expects custodial records from Coinbase or Kraken—a CSV with transaction timestamps, amounts, and USD equivalents. A non-custodial wallet generates no such document. The user must reconstruct it manually, and the reconstruction process is where tax reporting breaks down.

This friction is not a minor inconvenience. Tax authorities in multiple jurisdictions require precise cost basis, gain or loss calculation, and documentation of the economic substance of each transaction. A non-custodial wallet empowers the user to hold private keys and remain in full control of assets, but it transfers the responsibility for recordkeeping entirely to the individual. No exchange, vault provider, or custodian maintains an auditable transaction history. The accountant and client must bridge that gap using blockchain data, manual entry, and educated guesses about intent. For many preparers, the operational burden becomes unsustainable, leading them to decline clients with complex non-custodial holdings or to charge significantly higher fees. Understanding why this friction exists, where it concentrates, and what strategies can reduce it without compromising security forms the foundation of any serious approach to cryptocurrency tax planning.

The custodial versus non-custodial record-keeping divide

When a client holds funds on a regulated exchange, that exchange is a third party responsible for maintaining transaction records. Coinbase, Kraken, FTX (before its failure), and similar platforms generate downloadable reports that show every buy, sell, transfer, and fee. These records include precise timestamps, amounts in both cryptocurrency and USD, transaction identifiers, and often preliminary tax classification. An accountant can download a CSV, import it into tax software, and reconcile the data with the client’s bank deposits or other evidence of actual money movement. The exchange becomes a quasi-custodian of the record, even if regulatory custody requirements are technically narrow.

A non-custodial wallet, by definition, does not maintain such records. The wallet software—whether Alby, Ambire, Exodus, or another client—stores the user’s private keys locally and broadcasts transactions to the blockchain, but it does not generate a custodian-style report. The client sees balances and transaction history within their own wallet interface, but that history is reconstructed from blockchain queries and may include gaps, missing labels, or data loss if the device crashes or the wallet is reinstalled. No third party has certified or stored a copy. The blockchain itself is immutable and public, but reading it requires skill with block explorers, APIs, or specialized tax reporting software that attempts to infer intent from on-chain patterns.

For simple cases—a user who bought Bitcoin on an exchange, transferred it to a non-custodial wallet, and held it without trading—the gap is manageable. The cost basis is established by the exchange record, the holding period is clear, and the disposal event occurs only when the user sells. For complex cases involving DeFi, staking, airdrops, yield farming, or repeated small trades, the non-custodial wallet becomes an opaque black box to tax software. Each transaction must be interpreted: Was this a trade (taxable event)? A transfer to a different address the user owns (not a taxable event)? A received airdrop (income at fair market value)? A fee paid to a service (deductible expense)? Without custodial documentation, the accountant often has no reliable way to distinguish these cases and must ask the client to reconstruct intent from memory or wallet notes.

Why browser wallets make documentation harder, not easier

Browser wallets such as Alby, Ambire, or Coinbase Wallet offer genuine advantages for day-to-day asset management: they reduce the need for a separate device, integrate with decentralized applications, and allow quick access to holdings. They do not, however, solve the recordkeeping problem inherent in all non-custodial wallets. In fact, they may make it worse because browser-based access encourages frequent small transactions—swaps, approvals, staking deposits—that are trivial to execute but expensive to document retroactively.

A user who makes fifteen small trades through a decentralized exchange using a browser wallet may have each trade recorded on the blockchain but no unified ledger showing the economic context. The wallet interface might display the final balance, but cost-basis tracking requires knowing the acquisition price, the date, and the quantity for every single transaction. Browser wallets typically do not maintain detailed historical pricing data. They also do not assign tax lots—a critical concept where an accountant needs to know which specific units of an asset were disposed of and at what historical cost. Without this information, a user might default to FIFO (first-in, first-out) treatment, but that may not match the client’s actual intent or the tax rule in their jurisdiction.

Browser wallet education often emphasizes private key control and security, which are real benefits. However, users are sometimes encouraged to treat the wallet as sufficient for financial management when it is actually only sufficient for transaction execution. The security of a non-custodial wallet does not transfer to the security of the records kept outside it. A recovered private key is useless if the user cannot prove their cost basis or document the economic substance of past transactions. Tax authorities care less about whether keys were properly secured than whether gains and losses were accurately reported and documented.

The cost-basis and fair-value-on-receipt puzzle

Cost basis—the price at which an asset was acquired—is essential for calculating capital gains tax. For exchange-purchased assets, cost basis is the amount spent including fees. For received assets (airdrops, forks, staking rewards), cost basis is the fair market value at the moment of receipt. A non-custodial wallet does not record fair market values. It only records transactions. An accountant working with a client who received 10 tokens via airdrop from a non-custodial wallet must determine the fair market value of those 10 tokens on the date of receipt. If the token had no liquid market at that moment, or if the client did not record the date, the determination becomes speculative.

Staking rewards present a related problem. Many users hold assets in non-custodial wallets and earn staking rewards without using a service. The rewards appear in the wallet, often in small amounts, and the user might not realize that each reward constitutes taxable income at fair market value at the moment of receipt. A browser wallet does not generate a staking income report. The user must either manually record each reward (impractical for frequent rewards) or request documentation from any pool operator involved, if one exists. For solo staking, no third-party record exists at all.

The timing issue compounds the problem. Tax rules in most jurisdictions require documentation of fair market value in the local currency at specific moments in time. The moment a non-custodial wallet receives a transaction, the user’s wallet software queries a blockchain explorer or API to display a balance, but it does not record the historical USD (or other) price at that exact moment. The accountant must later attempt to find historical price data from exchanges—work that is tedious, subject to data quality issues, and inherently approximate.

Software gaps and the manual reconciliation burden

Tax accounting software such as TurboTax, TaxAct, or professional tools like CCH Axcess expects custodial records or structured data files. When a client says, “I held assets in a non-custodial wallet,” the software does not know what to do. Some dedicated cryptocurrency tax platforms (Koinly, CryptoTrader, Zenledger) have attempted to bridge this gap by offering blockchain import tools. These systems can read public addresses and construct a transaction history from the blockchain. They are helpful but far from complete: they cannot distinguish between addresses the user owns and addresses that are exchanges or other services, they struggle with transaction intent (was this a sale or a transfer?), and they often require manual review and correction of every transaction.

The user experience becomes a three-step process. First, the client exports or provides their transaction history—which may come from the wallet, a block explorer dump, or a dedicated tax tool. Second, the accountant imports or manually enters the data into their accounting software, attempting to categorize each transaction. Third, the accountant asks the client to verify and clarify borderline cases. This loop can repeat multiple times if data is missing or contradictory. For a client with significant non-custodial activity, the accountant’s fee for tax preparation often rises substantially—not because the cryptocurrency itself is unusual, but because the recordkeeping burden is higher.

The risk of error is also higher. A transaction that appears to be a transfer between addresses might actually be a sale if one address belonged to a different party. A transaction with no associated swap might be a staking deposit, earning subsequent rewards that the accountant fails to identify. Manual entry creates opportunities for typos or misclassification. A client might have multiple wallets and accidentally omit transactions from one of them. The accountant, lacking access to the blockchain themselves (or lacking the expertise to verify blockchain data), must trust the client’s initial data and hope nothing material is missed.

Regulatory and liability exposure for preparers

Tax preparers are accountable to clients and to tax authorities for the accuracy of filed returns. If a client held significant non-custodial assets and the accountant failed to identify and report all income, the preparer bears some professional liability. The client may face penalties and interest, and the preparer’s malpractice insurance and reputation could be damaged. Given the difficulty of verifying non-custodial transactions, some accountants simply decline to work with clients whose holdings are primarily non-custodial. Others ask clients to move assets to custodial platforms (exchanges) temporarily during the year to generate reports, which undermines one of the core reasons to use a non-custodial wallet in the first place.

The broader issue is that professional tax preparers operate under standards of care and diligence that were developed for traditional financial assets. Real estate transactions, securities accounts, and business income typically involve third-party records. Tax software is built to ingest and reconcile these records. A non-custodial wallet requires the preparer to adopt entirely different verification procedures. Many preparers are not equipped to do so, lack confidence in their ability to audit blockchain data, and perceive high risk in any unclear or incomplete documentation. Absent a clear regulatory framework for how accountants should handle non-custodial assets, that caution is understandable but it also creates a barrier to professional tax preparation for anyone with significant non-custodial holdings.

Practical strategies to reduce friction without compromising security

Clients can reduce the documentation burden by adopting a few disciplined practices. The first is to maintain a personal transaction log as assets are acquired or disposed of. When purchasing Bitcoin on an exchange and transferring it to a non-custodial wallet, the user should record the date, amount, price, and fee at the time of transfer. When receiving an airdrop or staking reward, they should screenshot the amount and look up the fair market value of that token on that date. This sounds burdensome, but a spreadsheet created in real time is far easier to maintain than retroactive reconstruction.

The second is to use a dedicated cryptocurrency accounting tool that supports blockchain imports. Tools like Koinly or CryptoTrader can read a public wallet address and attempt to construct a transaction history. Users should review the output carefully—the automatic categorization will be wrong for some transactions—but the tool provides a starting point that is better than a blank slate. The user (or accountant) can then correct misclassifications and add manual entries for gaps. This is still work, but it is work done once rather than repeated between client and accountant.

The third is to minimize the use of bridge transactions and complex DeFi interactions if the user has the option. Swapping assets through a DEX (decentralized exchange) is a taxable event that generates a trading gain or loss. Each swap must be documented. Staking or yield farming also generates income. If possible, keeping most activity on regulated exchange accounts and using non-custodial wallets only for cold storage reduces the tax recordkeeping surface. This is a trade-off—it sacrifices some security and privacy benefits of non-custodial holdings—but it makes tax compliance materially easier.

The fourth is to work with an accountant who has experience with cryptocurrency before the year ends, not after. Many accountants will accommodate non-custodial holdings if given clear guidance at the outset. A client who explains in January that they have holdings in several non-custodial browser wallets and will need additional time to document transactions gives the accountant an opportunity to set realistic fees and timelines. A client who arrives in March with an incomplete data set and asks for a quick return creates confusion and reduces accuracy.

The broader ecosystem challenge

The ultimate resolution to this problem requires either a shift in how users manage non-custodial assets or an evolution in how tax systems handle them. The former—users adopting better recordkeeping and accounting tools—is within reach today. Resources like the official Safety-First Browser Wallet Guides provide education on safe wallet operation and asset management, but they typically do not address tax documentation. Accountants and tax software vendors might benefit from investing in better blockchain data imports, automated categorization tools, and clearer workflows for non-custodial reconciliation. None of these exist at scale yet.

The latter—regulatory clarity on what constitutes adequate documentation for non-custodial holdings—is a longer-term process. Some tax authorities (such as the IRS in the United States) have issued guidance that crypto transactions are taxable events and records must be maintained, but the guidance does not address the practical question of how a taxpayer should document transactions from a non-custodial wallet without a custodian’s help. Until that clarity emerges, accountants will continue to treat non-custodial asset management with caution, and the friction will persist. Users who understand this friction and plan accordingly—documenting transactions in real time, using accounting tools, and communicating with their preparers early—can make the system work despite its limitations. Those who treat a non-custodial wallet as requiring no additional recordkeeping discipline will face serious problems at tax time.