Is a token migration or contract swap taxable?

It depends on what the holder ended up with, and there is no IRS ruling written for token migrations. The general rules apply: IRS Notice 2014-21 treats virtual currency as property, and Treas. Reg. §1.1001-1(a) recognizes gain or loss when property is exchanged for other property differing materially in kind or in extent. So the question is factual. If a project moves the same asset to a new contract (same project, one-for-one, same economic rights, nothing else received), one defensible position, and the one the house token_migration default reflects, is that there is no disposition and basis carries. If the holder burns one token and receives a materially different one (a different issuer or project, a different ratio, different rights, or extra consideration), the facts point toward a disposition of the old token and an acquisition of the new one. When the receipt does not settle which it is, the honest answer is review. CryptoTaxEdge classifies the hash (category, treatment, confidence, review flag). It does not decide the firm's position.

By Kevin Stursberg, founder, CryptoTaxEdge · Published October 6, 2026 · Updated October 6, 2026

What existing IRS guidance does and does not cover

Covered by general rules. Notice 2014-21 makes virtual currency property and applies general property-transaction principles. Section 1001 and Treas. Reg. §1.1001-1(a) supply the realization test. Treas. Reg. §1.1001-7(b)(1)(i), the digital-asset computation rule added by T.D. 10000, applies the same test: digital assets disposed of for other property differing materially in kind or in extent produce an amount realized. The 2026 Form 1099-DA instructions repeat the phrase. None of these names a migration.

Adjacent, but narrow.

• Rev. Rul. 2019-24 holds that a hard fork with no new units received produces no gross income, and that new units received in an airdrop following a hard fork, with dominion and control, are ordinary income. That fits a chain split where the holder keeps the legacy token and also receives a new one. It does not fit a migration where the old token is surrendered for the new one. Airdrop detail lives on Are crypto airdrops taxable?.
• IRS FAQ Q30 says a soft fork, a protocol change that does not create a new cryptocurrency, produces no income because the holder is in the same position as before. That is the IRS's framing for an in-place protocol upgrade. It is not a ruling on moving to a new contract.

Read those two as analogies a firm may weigh, not as authority that settles a migration.

Grey area: both positions

Position A (same asset, re-papered). The project deploys a new contract and offers a one-for-one conversion. The new token represents the same project, the same supply, and the same economic rights; the old contract is deprecated; the holder receives nothing else. On these facts, one defensible position, and the one the house token_migration default reflects, is that the holder exchanged nothing that differs materially in kind or extent. There is no disposition; basis carries to the new units. This mirrors the house token_migration treatment.

Position B (exchange of one property for another). Any surrender of one token for a token issued by a different contract is an exchange of property, and the firm should test it under §1.1001-1(a) on the facts rather than assume continuity. Where the new token changes the ratio, the issuer or governing entity, the supply, the rights (staking yield, governance, redemption), or comes with cash or extra tokens, the facts point toward a disposition of the old token at fair market value and a new acquisition. For a long-held, appreciated token, that can be a large gain even though the holder did nothing but follow the project's upgrade instructions.

Unsettled edges:

• Degree. Some migrations change only a ticker and contract address. Others merge projects or redenominate supply. There is no published bright line between re-papering and a new asset.
• Elective vs forced. A migration the old contract enforces (balances move automatically) can look different from one the holder chooses to opt into, especially if the old token keeps trading.
• Proposed wash-sale language. S. 5616 (ADAPT Act; introduced 2026-09-30, referred to the Senate Committee on Finance, status Introduced) Sec. 7 would treat a tokenized or bridged digital asset as substantially identical to the stock, security, or traded digital asset it is economically equivalent to. The H.R. 10357 substitute (ordered to be reported in the nature of a substitute, 38-5, on 2026-09-16; not passed by the House; not enacted) names a tokenized or wrapped digital asset. The two bills define bridged (S. 5616) and wrapped (H.R. 10357) the same way, as a token redeemable on demand, one for one, for a digital asset recorded on a different ledger. They define tokenized differently. A same-chain v1 to v2 migration is not a cross-ledger token under either definition, and neither bill names migrations. These texts address wash-sale loss disallowance; they do not decide whether a migration is a disposition, and they are not law. See Does the wash-sale rule apply to crypto in 2026?.

Classification framing: what the hash can and cannot show

The ledger shows mechanics. It shows the old token leaving (sent to a migration contract or burned), the new token arriving, the ratio, and any other assets in or out. It does not show the project's legal structure or whether the rights attached to the new token match the old one.

Signals that support a same-asset reading:

• A one-for-one ratio, with no other consideration in or out.
• A migration contract published by the same project, with the old contract deprecated.
• The same supply and the same economic rights on the new token.

Signals that point toward a disposition and acquisition:

• A different ratio, a different project or issuer, or a merged token.
• Extra tokens, NFTs, or cash received alongside the new token.
• The swap ran through a market (a DEX pool or aggregator) rather than a migration contract. That is a crypto-to-crypto swap, whatever the project calls it.

Related shapes that are not migrations: moving the same asset across chains is a bridge; a one-to-one wrap of the same underlying is a wrap; converting bridged USDC.e to native USDC has its own page. We do not restate them here.

How CryptoTaxEdge fits

Classification is a hash in, a record out. POST https://app.cryptotaxedge.com/v1/classify with { "chain", "hash" }. One category, one treatment from the closed enum (disposal, income, non_taxable, expense, needs_review), confidence 0 to 100 as a routing signal, needs_review: true and taxable: null when a treatment cannot be honestly asserted. Confidence is not an accuracy percentage.

For a migration hash, the record reports what the engine can honestly assert. If it emits token_migration, the house treatment is non_taxable with basis carrying, and that applies only because the category was emitted on facts that fit. If the hash shows a different asset received, it is typically served as swap (house treatment disposal); the engine does not decide whether that asset differs materially in kind or extent. If the facts do not settle the shape, it serves needs_review with taxable: null. We do not borrow another record's category, and we do not invent one for a project we have not seen. The house treatment is our published default; it is not an IRS ruling, and the firm's documented position controls. token_migration is not a grey-area category in Standard v1.1.1, so the record carries no grey_area block and no firm election; a firm that takes Position B applies it outside the record.

Worked example

Same asset, new contract. A project announces a v1 to v2 contract upgrade. The client sends 10,000 TKN-v1 to the project's migration contract, which burns them and mints 10,000 TKN-v2 to the same wallet. Same project, same supply, nothing else received, v1 deprecated. If the engine emits token_migration, the record serves non_taxable, and basis in the 10,000 units carries to v2. The firm documents why it treats the facts as Position A.

Burn and receive something different. Two projects merge. The client burns 10,000 OLD and receives 2,500 NEW (a different ratio, a new governance structure) plus a governance NFT. If the engine serves swap, that is a disposal of OLD measured at the fair market value of what was received, and an acquisition of NEW and the NFT. If the record serves needs_review, the firm decides between Position A and Position B on the merger documents. The OLD tokens were bought for $800 and NEW is worth $6,000 at receipt, so the position matters.

Unclear. A one-for-one migration where the new token adds staking yield and is issued by a newly formed foundation. The receipt alone does not show whether that is the same asset. The honest serve is needs_review with taxable: null. The firm reviews the project's documents and takes a position.

These examples are illustrative, not advice.

What CryptoTaxEdge does not do on this page

• We do not decide whether a new token differs materially in kind or extent from the old one.
• We do not treat the house token_migration default as an IRS position, or apply it when the engine did not emit it.
• We do not compute basis, holding period, gain, or loss on a migration.
• We do not apply proposed wash-sale rules to migrated, bridged, or tokenized assets.
• We do not connect to wallets or take custody. Hash in; category, treatment, confidence, and review flag out.

Classify a transaction at https://cryptotaxedge.com/explorer?src=answers. Enter a hash; ten a day, no signup.

Frequently asked questions

Accounting firm with crypto clients? See the Firm plan.

This is informational only, not tax advice; verify with a qualified tax professional before filing.