The crypto tax problem in 2026 often starts with a false sense of completion. A taxpayer downloads an exchange export, receives a new digital-asset broker statement (Form 1099-DA), and sees a list of proceeds. Then the wallet history shows a bridge, a cross-chain movement of assets, a blockchain-based finance position, and staking rewards that never appeared in the broker statement.
Crypto tax software in 2026 needs to reconcile those sources before it presents a gain or loss. It should identify what happened, preserve the records that support the classification, calculate only from supported basis inputs, and stop when the history is incomplete.
For federal tax purposes, a digital asset is a digital representation of value recorded on a cryptographically secured distributed ledger or similar technology. The IRS treats digital assets as property, not as a separate tax universe. The IRS digital asset page includes cryptocurrency, stablecoins, and non-fungible tokens among its examples.
A wallet is the software or hardware-controlled account and address set used to hold or move digital assets. A self-custody wallet is one where the taxpayer controls the credentials needed to authorize transfers. An exchange is a platform that records trades or custody activity in its own account system. DeFi is shorthand for financial applications that use blockchain programs and on-chain transactions, meaning transactions recorded on a blockchain, rather than a traditional broker’s account ledger. Staking means committing digital assets to a proof-of-stake network, a validation system based on committed assets, or to a service that may distribute rewards.
In this series, Tangle Tax Agent means a proposed workflow from Tangle, the project behind this series, for collecting those records, classifying candidate events, and preparing a review packet. It is not a claim that a public Tangle product can decide the tax treatment of every DeFi transaction or file a return without human approval.
This is not tax advice. Digital asset tax treatment can depend on ownership, timing, valuation, accounting method, entity status, and facts that are absent from a blockchain transaction record.
“2026” matters because broker data now has a boundary
The year in the title matters because broker reporting is changing while self-custody records remain the taxpayer’s responsibility. The IRS’s 2026 Instructions for Form 1099-DA state that brokers must report gross proceeds for digital-asset sales after 2025. They require basis information for covered securities and allow voluntary basis reporting for noncovered securities, subject to the rules in those instructions.
For 2025 transactions, the IRS warned that most Form 1099-DA statements would not include basis. The IRS also says DeFi brokers and some foreign brokers are not required to file Form 1099-DA or furnish a statement covering the activity. See the IRS guidance for tax professionals on digital-asset reporting and the 2026 Form 1099-DA instructions for the current reporting boundary.
| Source | What it can tell the software | What remains open |
|---|---|---|
| Form 1099-DA | Broker-reported proceeds and, for some assets, basis or holding-period information | Whether other wallets, DeFi protocols, or foreign platforms were omitted |
| Exchange export | Trades, deposits, withdrawals, fees, and account identifiers | Whether a transfer reached another wallet or represented a disposition |
| Wallet history | On-chain movements, token quantities, timestamps, and transaction IDs | Who controlled the address and what the protocol action meant |
| DeFi interface or protocol data | Swaps, liquidity positions, lending, borrowing, and reward events | The tax classification of an unusual smart-contract interaction |
| Staking provider record | Reward quantity, time, fees, and custody or validator details | The applicable income and basis treatment for the taxpayer’s facts |
| Taxpayer answer | Address ownership, entity ownership, purpose, and missing history | Whether the answer is supported by a record or needs review |
Form 1099-DA is therefore one source in the file. It is not a universal ledger for every digital asset the taxpayer owned.
Reconstruct events before calculating lots
An event is a normalized description of what a transaction did, such as “asset sold,” “same-owner transfer,” “reward received,” or “classification unresolved.” Normalization means translating exchange rows and blockchain records into one consistent event shape while keeping the original data attached.
The workflow is:
collect exchange, wallet, protocol, and broker records
-> identify addresses, accounts, assets, and owners
-> match likely same-owner transfers
-> group acquisitions into tax lots
-> classify swaps, sales, rewards, and unresolved protocol actions
-> calculate supported proceeds and basis candidates
-> prepare Form 8949 and Schedule D workpapers
-> review exceptions before approval or filingAn illustrative event-normalization API might accept a source reference and return candidate events. This is a product-design example, not a public Tangle endpoint.
POST /digital-asset-events/normalize
Content-Type: application/json
{
"taxYear": 2025,
"sources": ["exchange.csv", "wallet-a.json", "wallet-b.json"],
"requireTransferReview": true
}A tax lot is one acquisition of an asset, together with its quantity, acquisition date, and basis. When a later sale uses part of several acquisitions, the software must show which lots supplied the disposed units and which method or instruction supported that choice.
Basis is the taxpayer’s tax investment in the asset. For a purchased asset it often starts with cost, but transfers, fees, rewards, gifts, and other events can change the analysis. The Form 8949 instructions describe basis as the property’s cost under the general property rules, while transfers, fees, and rewards can change the analysis.
Follow one lot through a wallet and a swap
Take Olivia, who used a U.S. exchange, a self-custody wallet, and a proof-of-stake network during one illustrative year. The sample numbers below are deliberately simplified. They show how software should label work, not how a taxpayer should report a real transaction.
| Sample event | Raw record | Normalized candidate | Evidence state |
|---|---|---|---|
| Sample January 8 | Olivia buys 1.0 ETH for $2,000 on an exchange | Acquisition of 1.0 ETH with a $2,000 candidate basis | Supported by exchange trade record |
| Sample February 2 | 0.5 ETH leaves the exchange and reaches Olivia’s wallet | Same-owner transfer of 0.5 ETH | Candidate until wallet ownership is confirmed |
| Sample March 4 | 0.5 ETH moves through a bridge to another network | Cross-network transfer or protocol event | Needs protocol and ownership review |
| Sample April 12 | Olivia receives 0.01 ETH as a staking reward | Reward receipt with a quantity and market-value timestamp | Needs income and valuation review |
| Sample May 20 | Olivia swaps 0.3 ETH for 900 USD Coin (USDC) | Digital-asset disposition and acquisition candidate | Basis and event classification required |
| June 30 | The exchange issues a Form 1099-DA for its broker activity | Broker statement linked to the exchange account | Does not cover self-custody or DeFi activity automatically |
In this sample, if the 0.3 ETH sold in May came entirely from the $2,000 acquisition and no fee or other adjustment applies, the simplified basis candidate would be:
sample 0.3 ETH share of the $2,000 lot = $600 candidate basis
$900 swap value - $600 candidate basis = $300 candidate gainThat $300 is not Olivia’s final tax result. The system still needs to confirm which lot supplied the ETH, value the received USDC under the applicable rules, account for transaction costs, and determine whether the bridge or staking records change the lot history.
The worked calculation is useful because it makes the missing inputs visible. An output that says “$300 gain” without the lot, event type, valuation, and source is less reviewable than an output that says “$300 candidate gain, pending these three checks.”
Treat transfer matching as a hypothesis
A transfer is a movement of an asset between accounts or addresses. It can be a same-owner movement, a movement between separate taxpayers or entities, or part of a protocol action that needs different analysis.
Software should propose a transfer match only when several signals agree.
| Match signal | Why it helps | Failure case |
|---|---|---|
| Same asset and quantity | The incoming and outgoing records may refer to the same units | A bridge or token conversion can change the asset identifier or quantity |
| Close timestamps | A short interval supports a movement hypothesis | A delayed withdrawal can arrive much later |
| Known source and destination addresses | Ownership metadata can connect the records | An address can be shared, delegated, or controlled by an entity |
| Matching transaction IDs or bridge records | Protocol metadata can explain a cross-network move | A bridge can create a new representation of the asset |
| No separate swap or fee event | The records look like movement rather than exchange | A wallet export may combine several actions in one row |
The system should retain both sides of a proposed match. If it erases the withdrawal from the sale table before a reviewer accepts the match, a bad match can disappear without a trace.
An unmatched withdrawal is not proof of a taxable sale. It is evidence that the software cannot yet prove where the asset went or who controlled it. That distinction is central to reliable crypto tax software.
Read the protocol event before assigning a tax label
DeFi activity can involve a swap, a liquidity-pool deposit, a withdrawal, a lending position, a borrowing event, a reward, an airdrop, or several of those actions in one transaction. A liquidity pool is a smart-contract pool that holds assets supplied by users so a protocol can enable trades or other activity. An airdrop is a distribution of digital assets to addresses, often according to protocol rules.
The software should show the protocol event before assigning a tax label.
| Protocol action | Records to retain | Question for review |
|---|---|---|
| Token swap | Transaction ID, token in, token out, quantities, prices, and fees | Was there a disposition, and which lots supplied the asset? |
| Liquidity-pool deposit | Pool token received, assets deposited, quantities, and contract address | Did the position exchange assets, and how should the pool receipt be tracked? |
| Liquidity-pool withdrawal | Pool token burned, assets returned, quantities, and rewards | Which earlier position and rewards does this close or change? |
| Lending or borrowing | Asset supplied, asset borrowed, interest, collateral, and repayment | Which movements are loans, returns, rewards, or dispositions under the relevant rules? |
| Airdrop or protocol reward | Quantity, block or timestamp, control, and market evidence | When did the taxpayer receive control, and what basis record follows? |
There is no safe universal label for every smart-contract interaction. The IRS says digital assets are property and that taxpayers must report related income, gains, or losses, but the presence of a blockchain transaction record does not settle the tax treatment of a complex protocol event. The IRS digital asset FAQ is a starting point for general federal treatment, not a substitute for analyzing an unusual DeFi position.
Give staking rewards their own evidence trail
Staking rewards are often missing from the exchange’s trading export because the reward is generated by a network, validator, or staking provider. The software should record the reward quantity, asset, timestamp, transaction ID or provider statement, market-value source, fee, and custody path.
The IRS lists rewards from staking or earn programs among digital asset income examples. A 2026 Tax Court memorandum concerning cryptocurrency staking rewards addresses a specific factual case. The 2025 IRS revenue procedure for certain staking trusts is limited to the trust safe harbor it describes and should not be generalized to every taxpayer.
That changing source environment is a reason to store a tax year and rule reference with each classification. The product should not hard-code a sentence such as “staking is always income on receipt” without checking the taxpayer type, the transaction facts, and the current authority.
The safer output is an event record such as:
{
"event": "staking-reward",
"asset": "ETH",
"quantity": 0.01,
"observedAt": "2025-04-12T14:03:00Z",
"marketValueUsd": 24,
"source": "validator-statement.pdf#page=1",
"state": "needs-review",
"question": "Confirm the applicable reward-income and basis treatment for this taxpayer."
}The needs-review state is an honest output when the record is complete enough to inspect but the tax conclusion is not automatic.
Reconcile Form 1099-DA with everything outside the broker
Form 1099-DA reports digital asset proceeds from broker transactions. The current IRS instructions distinguish covered securities, where basis reporting is required for the specified acquisition period and custody conditions, from noncovered securities, where basis reporting is not required and may be voluntary. The instructions also identify assets acquired before 2026 or transferred into a broker’s custody as examples of noncovered securities.
That means a taxpayer can receive a 1099-DA with proceeds and still need older exchange records, wallet history, and transfer evidence to reconstruct basis. The IRS’s 2026 Tax Tip says most 2025 statements would not include basis and that taxpayers still must report related activity whether or not they receive a 1099-DA.
For capital-asset sales and exchanges, the software should prepare a workpaper that connects the normalized event to Form 8949 and Schedule D. The current Form 8949 instructions specify separate short-term and long-term parts and identify digital-asset reporting boxes G through I and J through L. Those checkboxes classify the transactions on Form 8949. They do not replace the lot and source analysis that produced the proceeds and basis.
Use the exception list as the acceptance test
Before a taxpayer accepts a crypto result, the product should produce a packet with these artifacts.
| Artifact | What it proves | What it cannot prove |
|---|---|---|
| Account and wallet inventory | Which exchanges, wallets, and addresses were included | That every address belonging to the taxpayer was discovered |
| Transfer-match report | Which movements were proposed as same-owner transfers | That the ownership assertion is true without review |
| Taxable-event table | How each normalized event was classified and sourced | That a difficult DeFi event has a settled tax answer |
| Lot ledger | Which acquisitions support each disposition and how basis was calculated | That a missing acquisition history can be recovered from thin data |
| 1099-DA reconciliation | Which broker proceeds agree or disagree with internal records | That the broker statement covers self-custody or DeFi activity |
| Unknown-basis queue | Which disposed units lack supported acquisition history | The correct basis for a taxpayer who has no records |
| Form 8949 draft | How supported dispositions would flow into the return | Approval of the taxpayer’s final filing position |
| Correction log | What changed after a reviewer supplied a source or answer | That the correction itself was tax-appropriate |
This is the concrete role for Tangle Tax Agent in the proposed workflow. The agent can collect, normalize, calculate, and explain the queue. The taxpayer or advisor must still decide which facts are true and which tax treatment applies.
For the broader preparation model, read AI Tax Preparation For Complex Returns. For the approval boundary, read Automated Tax Filing With Review Control. For the founder context that connects crypto to entities, equity, and foreign records, read Complex Tax Situations Software For Founders.
Keep failed classifications for the next reviewer
The software should mark the file as incomplete when an address is not attributable to a person or entity. It should preserve an unknown basis when the acquisition record is missing rather than assigning the current market price as a guess.
It should detect duplicate imports when the same swap appears in an exchange export and a blockchain transaction index. It should retain the raw transaction when a token migration or bridge changes the asset identity.
It should flag a Form 1099-DA mismatch when broker proceeds disagree with the internal event ledger. The taxpayer may have a legitimate explanation, such as an account transfer or statement correction, but the explanation belongs in the review record.
It should also retain the failed classification. When a reviewer changes “unknown protocol event” to “candidate swap,” the old state and reason should remain in the correction log.
These controls make a later advisor handoff possible. They also stop an attractive total from hiding the missing records that produced it.
A ledger cannot decide ownership or tax treatment
An on-chain transaction is evidence that a blockchain recorded an event. It is not, by itself, proof of who owned the address, why the transaction occurred, or how federal and state law treats it.
A broker statement is evidence of what the broker reported. It is not proof that every wallet and DeFi account was included.
A cost-basis number is the result of selected records, methods, and assumptions. It is not reliable when the system cannot show the acquisition lots and adjustments behind it.
For an AI system, the useful standard is inspectability. The system should be able to say what it knows, what it inferred, what it could not match, and what needs a human decision.
Choose the exception list over the headline gain
Choose crypto tax software in 2026 only when it reconciles Form 1099-DA with exchanges and wallets, records DeFi and staking events separately, preserves unknown basis, and produces a reviewable Form 8949 workpaper. For a small number of broker-only trades with complete statements, a simpler product may be enough. For self-custody, DeFi, staking, bridges, or missing history, reject any product that presents a final number without the exception list behind it. For the broader review workflow around complex returns, see AI accountant software for complex tax returns.
What should crypto tax software handle in 2026?
It should handle broker statements, exchange exports, self-custody wallets, DeFi protocol events, staking rewards, transfer matching, lot-level basis, Form 1099-DA reconciliation, and Form 8949 workpapers. It should also show unresolved transactions instead of silently dropping them.
Is a Form 1099-DA enough for crypto taxes?
Usually not for an active user. Form 1099-DA covers broker transactions under its reporting rules, while DeFi brokers and self-custody activity may require separate records and basis reconstruction.
Are crypto wallet transfers taxable?
The software should not label every wallet movement as a sale. It should match likely same-owner transfers, preserve the evidence, and send unmatched or ownership-uncertain movements for review.
How should staking rewards appear in the file?
They should appear as separate events with quantity, timestamp, valuation source, custody details, and a review state. The applicable income and basis treatment should be tied to current authority and the taxpayer’s facts.
What should I inspect before accepting the result?
Inspect the wallet inventory, transfer matches, unknown-basis list, high-impact DeFi and staking events, 1099-DA reconciliation, lot ledger, Form 8949 draft, and correction log.