Home › Classification Standard

Standard

The CryptoTaxEdge Classification Standard v1.1

Version 1.1.1 · Published 2026-08-12 · Updated 2026-08-20 · Machine-readable form: cte-classification-standard-v1.json

A versioned, citable standard for classifying on-chain transactions into US tax treatments: the canonical category set, the closed five-treatment enum, the grey-area doctrine, confidence and review semantics, evidence standards, and the wire contract a conforming record carries. It formalizes the public CryptoTaxEdge taxonomy so that any tool, paper, or workflow can cite and implement it against a stable, versioned reference.

Scope: this is the schema, not the rules. The standard defines what a classification record means: the vocabulary, the treatment semantics, and the honesty contract. It does not define how any engine detects a category on-chain. Detection logic, protocol rules, and serve parameters are implementation concerns and are out of scope.

The vocabulary tracks the implementation. The category set below is the set of values the reference implementation actually emits on the wire. Conformance is measured against that published wire contract, not against any internal representation. Where the reference implementation falls short of what this standard asks of a conforming tool, the difference is published in section 6 rather than settled by wording.

Contents

The treatment enum
The category set and house defaults
Grey-area doctrine
Confidence semantics and the review contract
Evidence standards
Known implementation gaps
The wire contract
Versioning policy and changelog
Conformance
License and conformance claims

1. The treatment enum

A conforming record maps each classified transaction to exactly one of five treatments. The enum is closed: these five values are the complete set, and consumers may safely branch exhaustive logic on this field.

disposalincomenon_taxableexpenseneeds_review

Treatment	Meaning	US framing
`disposal`	A disposition of property.	IRC §1001
`income`	Value received; ordinary income at receipt.	IRC §61
`non_taxable`	A positive finding that no recognition event occurred.	No recognition event
`expense`	A fee or cost paid, carrying `taxable: false`. A statement about what the outflow is for, not a finding that a recognition event occurred.	Fee or cost; not a recognition event on its own
`needs_review`	No treatment is asserted; the record is routed to a human and `taxable` is returned as `null`.	Deferred to a reviewer

IRC section references are general framing under US federal income tax principles, not tax advice.

Erratum v1.0.1: expense carries taxable: false. Version 1.0.0 of this document published expense with taxable: true. That was a documentation error. The reference implementation has always emitted taxable: false for this treatment on every path that produces it, so no conforming record has ever carried expense with taxable: true and no conforming consumer can have relied on the published value. Because this document's own versioning rule makes a bare change to the meaning of a field value a major change, the correction is published as an explicit erratum rather than folded silently into a minor release.

A gap this correction does not close. Paying a fee in appreciated crypto is a disposition of the fee asset under IRC §1001. Neither this standard nor the reference implementation books that disposition: the fee leg is carried as display-only data on the record. This is a gap in both, not a disagreement between them, and closing it requires per-transaction fee basis lots in the implementation. See GAP-6.

2. The category set and house defaults

A category names the transaction shape; each category carries a house-default treatment. The tokens below are the vocabulary enumerated at v1.1, and they are the values the reference implementation emits on the wire. The vocabulary grows additively across versions (see versioning), so consumers must tolerate values not listed here and must not branch exhaustive logic on category; the treatment enum is the closed branching surface. This matches the record schema, which documents category as an open vocabulary.

Treatment precedence. The house treatment is what a category maps to when a record is served with a treatment asserted. Review routing overrides it: any record the implementation routes to a human is served with treatment: needs_review and taxable: null whatever its category. Three categories carry no house treatment at all, marked not fixed below; for those, read the treatment field and never infer from the name.

Category	House treatment	Definition
`swap`	disposal	Exchanging one asset for another, a disposition of the asset sold. IRC §1001.
`liquidity_add` / `liquidity_remove` grey area	disposal	Assets deposited into or withdrawn from a liquidity pool. House default treats add and remove as dispositions; the continuity-of-position alternative is exposed and configurable.
`nft_mint`	disposal	Paying to mint an NFT; the house treats the mint as a disposition of the asset paid. There is no separate NFT sale category: a secondary-market disposal is represented as `swap`, so the collectibles question under IRC §408(m) is not answerable from the category alone (GAP-7).
`liquidation` grey area	disposal	Collateral seized and sold to close an undercollateralized position. House default treats the liquidated party as disposing of the collateral. The grey block carries the basis (confirm whether the taxpayer is the liquidated party or the liquidator) but names no alternate position, so this category is not firm-configurable.
`reward`	income	Staking or protocol reward received. Ordinary income at fair market value when the taxpayer gains dominion and control (Rev. Rul. 2023-14; IRC §61).
`airdrop`	income	Unsolicited token distribution received into the taxpayer's control; ordinary income at receipt. Unsolicited transfers identified as spam or address poisoning are represented under `spam` instead and are not treated as income.
`vesting`	income	A token unlock or vesting claim received; ordinary income at fair market value on receipt. Timing turns on when the property substantially vests (IRC §83), and a locked stream may vest ratably rather than in full at the claim.
`income_receipt`	income	Value received that is ordinary income and does not fit a more specific income category.
`rebase_reward` grey area	income	Reward accruing through a rebasing or value-accruing wrapper token, where recognition timing is genuinely contested. House default is income at receipt (Rev. Rul. 2023-14); the deferral view is exposed as the alternative and configurable.
`fee_collection`	income	Earned liquidity-pool or protocol fees collected by the taxpayer.
`perp_close` / `perp_funding`	income	Realized profit or loss on closing a perpetual futures position, and perpetual futures funding received. House default is ordinary income or loss.
`fee_payment`	expense	Network or protocol fee paid; `taxable: false`. Token approvals and reverted or failed transactions are also represented here, because the only economic outflow is the fee; they are distinguished only in `review_note` prose, not by the category field (GAP-5). The unbooked fee-asset disposition applies to every record in this category (GAP-6).
`transfer`	non_taxable	Movement of the taxpayer's own assets between wallets under the same beneficial ownership. This standard has no category for a send to a third party as payment, gift, or donation, and the reference implementation cannot emit one; a one-way send to an unverified counterparty is identified here and, since 2026-08-12, routed to review with `treatment: needs_review` (GAP-1). Do not read this category as evidence that a counterparty was verified.
`borrow` / `repay`	non_taxable	Loan principal received against collateral, and loan principal repaid; no change in beneficial ownership.
`wrap` / `unwrap` grey area	non_taxable	One-to-one wrap or unwrap of an asset. House default is non-taxable with basis carried; the disposition view is exposed and configurable.
`liquid_staking_mint` grey area	non_taxable	Receipt-token mint on a liquid staking deposit. House default treats the mint like a wrap of the deposited asset, so basis carries; the disposition view is exposed as the alternative and configurable. The doctrine and the firm election are honored on the mint side only (GAP-2).
`collateral_supply`	non_taxable	Assets supplied as collateral or deposited into a lending protocol, typically against a receipt token; no change in beneficial ownership. The implementation asserts this as settled and exposes no alternate position, unlike `liquid_staking_mint` (GAP-4).
`collateral_withdraw`	non_taxable	Collateral or a lending-protocol deposit reclaimed; no change in beneficial ownership. A liquid-staking redeem is also served here, where the applicable analysis is the `liquid_staking_mint` doctrine rather than a settled withdrawal (GAP-2).
`staking` / `restaking_deposit`	non_taxable	Principal staked in the same asset with no receipt token issued, and deposits into a restaking protocol. Conservative non-taxable default; no alternate position or firm election is exposed on these categories.
`token_migration`	non_taxable	The same asset moved to a new contract in a protocol migration; basis carries.
`spam`	non_taxable	An unsolicited transfer identified as spam or address poisoning. Excluded from the books rather than treated as an income event. Carried internally as its own bucket and clamped to `non_taxable` on the wire so a consumer branching exhaustively on treatment never sees an out-of-enum value.
`bridge_transfer` / `deposit` / `withdrawal`	not fixed	Cross-chain movement of the taxpayer's own assets, and generic custody deposits and withdrawals not resolved to a more specific category. This standard fixes no house treatment for these three. v1.0.0 published `bridge` as a settled `non_taxable`, which overstated the contract: the implementation derives no treatment for them at serve time, so the treatment travels from the stored record. Read the `treatment` field (GAP-3). A bridge that swaps into a different asset en route is a disposition of the source asset and is represented as `swap`.
`unclassified` / `needs_review`	needs_review	The shape was not resolved to a category the implementation is willing to assert, or the record is a terminal deferral. Served with `treatment: needs_review` and `taxable: null`.

Retired aliases

Four names published in the v1.0.0 category vocabulary are not values the reference implementation can emit. Each was a documentation error rather than a category that was later removed. They are retained here so citations against v1.0.0 stay resolvable, mapped to the names actually emitted. A conforming implementation must not emit a retired alias.

Retired name	Emitted instead	Why
`collateral`	`collateral_supply`, `collateral_withdraw`	One name was published for what the implementation represents as two directional categories.
`stake`	`staking`	An accepted input spelling, never an emitted value.
`unstake`	`collateral_withdraw`	The word maps to a differently named category on the wire, so a consumer keying on `unstake` never matched a record. The sharpest of the four.
`bridge`	`bridge_transfer`	An accepted input spelling, never an emitted value.

3. Grey-area doctrine

Some treatments are genuinely contested under current US guidance. For those categories the standard requires three things of a conforming implementation:

A documented house default. The implementation states which position it returns by default and the basis for it.
An exposed alternative. The defensible position not taken is carried on the record itself (the grey_area field), so a reviewer can see it and switch to it without re-deriving the analysis.
Firm-level configurability. A firm can set its own standard for each grey-area category before classifying, and the implementation honors that election consistently.

The standard describes positions and their basis; it does not assert a filing position for any taxpayer. In v1.1 the grey-area categories are liquidity_add, liquidity_remove, wrap, unwrap, liquid_staking_mint, liquidation, and rebase_reward.

Not every grey category is firm-configurable. liquidation carries a documented basis but no named alternate position, because the alternative depends on which side of the liquidation the taxpayer is on. The firm-configurable categories are liquidity_add, liquidity_remove, wrap, unwrap, liquid_staking_mint, and rebase_reward.

Withdrawn in v1.1: the liquid-staking symmetry claim. Version 1.0.0 stated that the liquid_staking_mint doctrine applies symmetrically to the redeem side. That claim is withdrawn because it is not true of the reference implementation, which represents a liquid-staking redeem under a different category, attaches a generic grey flag rather than the liquid-staking grey block with its named disposition alternative, and does not honor a firm's liquid-staking election on it. The configurability requirement above is therefore met on the mint side only. This is an implementation gap, published as GAP-2 rather than closed by rewording, and adding a redeem category to this document would not close it.

4. Confidence semantics and the review contract

Every conforming record carries an integer confidence from 0 to 100. The standard fixes what the number means, not how any implementation computes it:

Confidence is a corroboration signal, not an accuracy percentage. It reflects how well the available evidence agreed on this classification, and it gates exactly one decision: whether the record is served as a treatment or routed to a human. Scores are not comparable across transactions and must never be presented as a probability that the treatment is correct.
How the score is computed is out of scope. The arithmetic behind the number, and the thresholds at which an implementation routes to review, are serve parameters and are not part of this standard or of the public contract.

The review contract: route, never guess. When an implementation cannot honestly assert a treatment, it returns needs_review: true with taxable: null. A null taxable always travels with needs_review: true, and consumers must never coerce null to false. A review-flagged record belongs in a review queue, never in the books. Deferring is a designed behavior of a conforming implementation, not a failure state.

The invariant, stated once. needs_review is both a treatment value and a boolean field, and the two never disagree: treatment: needs_review, the needs_review flag being true, and taxable being null are one state and always travel together, whatever the record's category.

5. Evidence standards

A conforming classification is grounded in verifiable on-chain evidence:

Receipt-derived legs. The per-leg asset movements on a record (assets.sent, assets.received) derive from the transaction receipt and its logs, the on-chain ground truth, not from heuristics over unverified metadata.
Exact amounts. Token amounts are decimal strings carried with their decimals, computed with integer arithmetic. Floating-point parsing of amounts is non-conforming for accounting use: 18-decimal token amounts overflow double-precision floats.
Replayed examples. Published example records for a conforming implementation are verbatim captures of real output, replayable against the live implementation, honest deferrals included. The CryptoTaxEdge reference set is at /examples/canonical/.

6. Known implementation gaps

These are points where the reference implementation does not yet deliver what a reader of this standard would reasonably expect. They are published rather than papered over: a standard that describes an implementation it does not have is worse than one that names the difference. Most are implementation changes rather than wording changes, so this document resolves none of them by rewording; where a gap statement itself proved wrong about the implementation (GAP-5), it is corrected as an erratum. They are listed here so that a consumer can work around them deliberately.

Gap	What the implementation does	What a consumer should do
GAP-1 `transfer`	Since 2026-08-12 the reference implementation routes a one-way transfer whose counterparty is not verified as the taxpayer's own wallet to review, in both directions: the record keeps `category: transfer` as the identification and serves `treatment: needs_review` with `taxable: null`, with the ownership question stated in `description`. Verified self-transfers keep the quiet `non_taxable` verdict. Version 1.1.0 of this document described the earlier behavior, a `non_taxable` serve with no review flag; that serve was retired by an implementation change made 2026-08-12 and deployed after 1.1.0 published, and records classified before the change may still serve the earlier shape from cache. The gap that remains is the vocabulary: there is no `payment`, `gift`, or `donation` category on the wire, so the record defers rather than distinguishing them.	Do not treat the `transfer` category as evidence of verified same-owner movement; the category identifies the shape, not the ownership. Branch on `treatment` and `needs_review`, which this standard invites: a freshly classified unverified transfer arrives as `needs_review` with `taxable: null`. Reconcile counterparties against a known-wallet list to settle the treatment, and read `description` for the ownership question on any transfer record.
GAP-2 `liquid_staking_mint`, `collateral_withdraw`	A liquid-staking redeem is served under `collateral_withdraw`. It carries a generic grey flag rather than the liquid-staking grey block with its named disposition alternative, and a firm's liquid-staking election is not honored on it, because that election is keyed to the mint category.	Do not assume a `collateral_withdraw` record is a settled non-taxable withdrawal. Where the asset withdrawn is a liquid-staking token, apply the `liquid_staking_mint` analysis: a token bought on market and redeemed above basis is a disposition.
GAP-3 `bridge_transfer`, `deposit`, `withdrawal`	The implementation derives no treatment for these three categories at serve time, so the served treatment travels from the stored record rather than from the category. This standard therefore fixes no house treatment for them. v1.0.0 published `bridge` as a settled `non_taxable`, which the implementation does not guarantee.	Read the `treatment` field. Never infer a treatment from these category names.
GAP-4 `collateral_supply`	A lending-protocol deposit against a receipt token is asserted as settled non-taxable with no exposed alternative and no firm election, while a liquid-staking deposit against a receipt token, an arguably similar structure, exposes both. The asymmetry is in the implementation and is visible in the published example set.	Treat the absence of a grey block on `collateral_supply` as an implementation limit rather than as a finding that the position is settled.
GAP-5 `fee_payment`	Token approvals and reverted or failed transactions are represented under `fee_payment` and are distinguishable from an ordinary fee only in the record's `description` prose (on approvals, `protocol` also names the approval where it resolves). `review_note` is null on these records: the wire populates `review_note` only on review-routed records, and these serve confidently. Version 1.1.0 said the distinction rides in `review_note`; that statement was wrong about the implementation when published and is corrected as erratum v1.1.1. There is no `approval` or `failed` category on the wire.	Do not expect an approval or a failed transaction to arrive under its own category name, and do not look for the distinction in `review_note`. If the distinction matters to your workflow, read `description`.
GAP-6 `fee_payment`, `expense`	Paying a fee in appreciated crypto is a disposition of the fee asset under IRC §1001. Neither this standard nor the reference implementation books that disposition; the fee leg is carried as display-only data. This is a shared gap in both documents rather than a divergence between them, and closing it requires per-transaction fee basis lots.	If your books require gain or loss on the fee asset, compute it outside these records.
GAP-7 `nft_mint`, `swap`	There is no `nft_sale` category. A secondary-market NFT disposal is represented as `swap`, so the collectibles question under IRC §408(m) cannot be answered from the category field.	Identify NFT disposals from the asset legs rather than from the category.
GAP-8 `fee_payment`, `expense`	A `fee_payment` record classifies a fee event it does not quantify: on freshly classified EVM records `assets.gas` is null and, on approval-shaped records, `sent` and `received` are empty, so the record carries no fee amount. The gas quantum was previously populated by an upstream source that has been removed; populating it from the transaction receipt is an open implementation item. Distinct from GAP-6, which covers not booking the fee asset's disposition even where the amount is known.	Where the engagement's fee policy needs the amount, compute it from the transaction receipt (gasUsed × effectiveGasPrice) via any public RPC; the record's `hash` and `chain` identify the receipt.

7. The wire contract

A conforming record is a JSON object validating against the published record schema, cte-classification-v1 (documented at /schema/). The normative field semantics:

Field	Type	Semantics
`api_version`	string	Wire format version; `"v1"` for this standard.
`category`	string	Canonical event type from the category set. Additive vocabulary across versions: display it, never branch exhaustive logic on it.
`treatment`	string	One of the five enum values. Closed; safe for exhaustive branching. `needs_review` means no treatment is asserted.
`taxable`	boolean or null	`true` = taxable event; `false` = positive non-taxable finding; `null` = taxability not asserted. `null` always travels with `needs_review: true`.
`confidence`	integer 0 to 100	Corroboration and routing signal per section 4. Not an accuracy percentage.
`needs_review`	boolean	The honesty contract: `true` = the implementation defers to a human instead of guessing. Route to a review queue, never to the books.
`grey_area`	object or null	Present only on genuinely two-sided treatments: carries the basis for the split and the alternate position not taken. `null` when the treatment is settled.
`ledger_action`	string or null	Suggested ledger label for tax-platform import (for example `Trade`, `Reward`).
`assets`	object or null	Receipt-derived per-leg movements (`sent`, `received`, `gas`) with decimal-string amounts per section 5.

Identification and provenance fields (hash, chain, protocol, description, review_note, batch id and error) are defined in the record schema. A batch item with error set is not a classification and never a result to book.

8. Versioning policy and changelog

The standard is versioned with semantic versioning; the current version is 1.1.1.

Major. Any change to the treatment enum, to the meaning of an existing field, or any other change that could break a consumer branching on documented semantics.
Minor. Additive changes: new categories, new optional fields, new documented grey-area positions.
Patch. Clarifications and corrections that change no semantics.
Erratum. A correction to a published statement that was factually wrong about the reference implementation at the time it was published, where no conforming record could have carried the published value. An erratum is issued as a patch and recorded in the errata array, never folded silently into a minor release.

Every change is logged in the changelog array of the machine-readable standard. Superseded versions remain published at their own versioned URLs so citations stay stable: v1.0.0 is frozen at cte-classification-standard-v1.0.0.json, carrying an erratum notice listing its known errors.

What changed in v1.1.1 (2026-08-20)

Updated GAP-1 to record an implementation change made 2026-08-12 and deployed after 1.1.0 published: an unverified one-way transfer is now review-routed in both directions (treatment: needs_review, taxable: null), with the identification kept in category. The vocabulary half of the gap (no payment, gift, or donation category) stands.
Erratum v1.1.1 on GAP-5: the approval and failed-transaction distinction rides in description, not review_note; review_note is null on non-review records. The published statement was wrong about the implementation when published. Recorded in the errata array.
Added GAP-8: fee_payment records carry no fee quantum (assets.gas null on freshly classified EVM records).

What changed in v1.1

v1.1 reconciles the published vocabulary with the vocabulary the reference implementation actually emits, and publishes the differences that remain. v1.0.0 named 17 categories against 31 emitted: 18 emitted categories were missing, four published names could not be emitted at all, and 6 of the 17 published example records carried a category outside the document's own vocabulary. Under v1.0.0's own conformance criteria, the reference implementation did not conform to the standard that referenced it.

Added the 18 missing categories: bridge_transfer, collateral_supply, collateral_withdraw, deposit, fee_collection, income_receipt, liquidation, needs_review, nft_mint, perp_close, perp_funding, rebase_reward, restaking_deposit, spam, staking, token_migration, unclassified, withdrawal.
Reclassified four names as retired aliases: collateral, stake, unstake, bridge. None was emittable.
Carried the v1.0.1 erratum on the expense treatment: taxable is false, not true.
Withdrew the liquid-staking symmetry claim and published the redeem behavior as GAP-2.
Removed the fixed non_taxable treatment from bridges, and published bridge_transfer, deposit, and withdrawal with no house treatment, because the implementation derives none at serve time (GAP-3).
Added liquidation and rebase_reward to the grey-area list, which the implementation already treats as grey, and separated the grey list from the narrower firm-configurable list.
Rewrote confidence semantics to meaning and routing behavior only. The v1.0.0 text described how the score is computed and referred to counts of corroborating evidence sources, contradicting this document's own statement that serve parameters are out of scope.
Softened the closed-vocabulary claim to enumerated-at-version, resolving a contradiction with the record schema, which documents category as an open vocabulary.
Added section 6, seven published implementation gaps, and stated that conformance is measured against the published wire contract.
Added the treatment precedence rule, stated the needs_review invariant once, added the citations the implementation already carries (Rev. Rul. 2023-14, IRC §83), and added the CC BY adaptation remedy to the trademark terms.

9. Conformance

Any tool may implement this standard. An implementation conforms to v1.0 if it:

emits records that validate against cte-classification-v1;
uses the treatment enum of this standard with the semantics defined here, and draws category values from the vocabulary enumerated here, extending it only additively;
honors the review contract: taxable: null if and only if needs_review: true, and no silently guessed treatments;
implements the grey-area doctrine for the categories it marks grey: documented house default, exposed alternate, firm-level configurability;
meets the evidence standards of section 5 for the legs and amounts it reports.

What conformance is measured against. Conformance is measured against the published wire contract, meaning the records an implementation actually emits from its documented endpoint. Internal representations, cache contents, and normalization tables are not the contract and are not evaluated. The category vocabulary in this document is maintained to match the vocabulary the reference implementation emits; where the reference implementation falls short of what this standard asks, the difference is published in section 6 rather than resolved by wording.

The reference implementation is the CryptoTaxEdge API (POST /v1/classify, documented at dashboard.cryptotaxedge.com/api, OpenAPI spec openapi.json). It conforms to the vocabulary and the review contract of v1.1; the grey-area doctrine's configurability requirement is not met on the categories named in GAP-2 and GAP-4. The machine-readable form of this standard is cte-classification-standard-v1.json, published under the license in section 10.

10. License and conformance claims

The specification text on this page and the machine-readable JSON are published under Creative Commons Attribution 4.0 International (CC BY 4.0): free to implement, copy, adapt, and cite, with attribution to CryptoTaxEdge required. The license covers the text, not the marks.

The Standard and the 2026 H1 labelled benchmark corpus are archived with a DOI: https://doi.org/10.5281/zenodo.21911546.

"CryptoTaxEdge Classification Standard" and "CTE Standard" are trademarks of Stursberg LLC dba Crypto Tax Edge.

Conformance claims. A third-party tool may state that it implements the CryptoTaxEdge Classification Standard v1.1 only if it implements the canonical wire contract as published, meeting the criteria in section 9.
Official and certified. Only CryptoTaxEdge may describe an implementation as official or certified. The license lets anyone redistribute this text with attribution. What the marks reserve is the naming: a modified, extended, or independently maintained document may not be presented as the Standard or as a version of it. An adaptation must indicate that it is modified and must not use the marks.
Extensions. Third-party extensions must be namespaced with an x- prefix. Extensions are not part of the Standard unless ratified into a published version, and a record relying on unratified extensions must not be described as conforming.
Stewardship. The canonical URL (cryptotaxedge.com/standard/) and the semantic versioning of the Standard are stewarded by CryptoTaxEdge alone. Versions published anywhere else are not the Standard.

Not tax advice. CryptoTaxEdge is software, not a licensed tax advisor. This standard and the treatments it defines are informational only. Verify results and consult a qualified tax professional before filing. IRC section references are provided as general framing.