{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://cryptotaxedge.com/standard/cte-classification-standard-v1.json",
  "title": "CryptoTaxEdge Classification Standard",
  "description": "Machine-readable form of the CryptoTaxEdge Classification Standard v1.1: the canonical category set, the closed five-treatment US tax enum, grey-area doctrine, confidence and review semantics, evidence standards, and the wire contract. As a JSON Schema this document validates a conforming classification record by reference to the published record schema (cte-classification-v1). The normative standard content is carried under x-cte-standard; the human-readable specification is https://cryptotaxedge.com/standard/. This standard defines what a classification record means, not how any engine detects a category on-chain; detection logic and serve parameters are out of scope. The category vocabulary tracks the vocabulary the reference implementation actually emits on the wire, and conformance is measured against that published wire contract rather than against any internal representation.",
  "$comment": "License: CC BY 4.0 (attribution to CryptoTaxEdge required). 'CryptoTaxEdge Classification Standard' and 'CTE Standard' are trademarks of Stursberg LLC dba Crypto Tax Edge; a third-party tool may claim it implements the Standard only if it implements the canonical wire contract as published. Not tax advice: IRC section references are general framing under US federal income tax principles.",
  "$ref": "https://cryptotaxedge.com/schema/cte-classification-v1.json",
  "x-cte-standard": {
    "name": "The CryptoTaxEdge Classification Standard",
    "version": "1.1.1",
    "published": "2026-08-12",
    "updated": "2026-08-20",
    "specification_url": "https://cryptotaxedge.com/standard/",
    "version_history": [
      {
        "version": "1.1.1",
        "url": "https://cryptotaxedge.com/standard/cte-classification-standard-v1.json",
        "status": "current"
      },
      {
        "version": "1.0.0",
        "url": "https://cryptotaxedge.com/standard/cte-classification-standard-v1.0.0.json",
        "status": "superseded"
      }
    ],
    "wire_schema": {
      "$ref": "https://cryptotaxedge.com/schema/cte-classification-v1.json",
      "wire_format": "cte-classification-v1",
      "documentation": "https://cryptotaxedge.com/schema/",
      "note": "A conforming record is a JSON object validating against the referenced record schema. The record schema is the single source of field shapes; this document does not restate them."
    },
    "treatments": {
      "closed": true,
      "note": "The complete treatment set. Consumers may branch exhaustive logic on treatment; needs_review means no treatment is asserted.",
      "values": [
        {
          "value": "disposal",
          "meaning": "A disposition of property.",
          "us_framing": "IRC section 1001",
          "taxable": true
        },
        {
          "value": "income",
          "meaning": "Value received; ordinary income at receipt.",
          "us_framing": "IRC section 61",
          "taxable": true
        },
        {
          "value": "non_taxable",
          "meaning": "A positive finding that no recognition event occurred.",
          "us_framing": "No recognition event",
          "taxable": false
        },
        {
          "value": "expense",
          "meaning": "A fee or cost paid. This is a statement about what the outflow is for, not a finding that a recognition event occurred.",
          "us_framing": "Fee or cost; not a recognition event on its own",
          "taxable": false,
          "erratum": "v1.0.0 published this value as taxable: true. That was a documentation error. The reference implementation has always emitted taxable: false for the expense treatment, so no conforming record has ever carried expense with taxable: true. Corrected in the v1.0.1 erratum; see the errata array.",
          "known_gap": "Neither this Standard nor the reference implementation books the IRC section 1001 disposition of the fee asset when a fee is paid in appreciated crypto. The fee leg is carried as display-only data on the record and no disposal is recognized against it. This is a gap in both documents, not a divergence between them. See known_implementation_gaps GAP-6."
        },
        {
          "value": "needs_review",
          "meaning": "No treatment is asserted; the record is routed to a human reviewer.",
          "us_framing": "Deferred to a reviewer",
          "taxable": null
        }
      ]
    },
    "categories": {
      "closed_at_version": false,
      "enumerated_at_version": true,
      "note": "The canonical category vocabulary of v1.1, enumerated at this version. The vocabulary grows additively across versions, 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. The values below are the vocabulary the reference implementation emits on the wire.",
      "treatment_precedence": "house_treatment is the treatment 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 regardless of its category. A category with house_treatment null is one for which this Standard does not fix a treatment; see the note on each such value.",
      "values": [
        {
          "category": "swap",
          "house_treatment": "disposal",
          "grey_area": false,
          "us_framing": "IRC section 1001",
          "definition": "Exchanging one asset for another, a disposition of the asset sold."
        },
        {
          "category": "liquidity_add",
          "house_treatment": "disposal",
          "grey_area": true,
          "alternate_treatment": "non_taxable",
          "alternate_view": "Continuity of position: the deposit is a non-recognition contribution rather than a disposition.",
          "us_framing": "IRC section 1001",
          "definition": "Assets deposited into a liquidity pool. House default treats the add as a disposition; the continuity alternative is exposed and configurable per firm."
        },
        {
          "category": "liquidity_remove",
          "house_treatment": "disposal",
          "grey_area": true,
          "alternate_treatment": "non_taxable",
          "alternate_view": "Continuity of position: the withdrawal unwinds the position rather than disposing of it.",
          "us_framing": "IRC section 1001",
          "definition": "Assets withdrawn from a liquidity pool. House default treats the remove as a disposition; the continuity alternative is exposed and configurable per firm."
        },
        {
          "category": "nft_mint",
          "house_treatment": "disposal",
          "grey_area": false,
          "us_framing": "IRC section 1001",
          "definition": "Paying to mint an NFT. House default treats the mint as a disposition of the asset paid.",
          "note": "There is no separate category for an NFT sale. A secondary-market NFT disposal is represented as swap, so the collectibles question under IRC section 408(m) is not distinguishable from the category alone. See known_implementation_gaps GAP-7."
        },
        {
          "category": "liquidation",
          "house_treatment": "disposal",
          "grey_area": true,
          "alternate_treatment": null,
          "alternate_view": null,
          "grey_basis": "Perspective-dependent: confirm whether the taxpayer is the liquidated party or the liquidator.",
          "us_framing": "IRC section 1001",
          "definition": "Collateral seized and sold to close an undercollateralized position. House default treats the liquidated party as disposing of the collateral.",
          "note": "The grey block on this category carries the basis for the split but does not name an alternate position, because the alternative depends on which side of the liquidation the taxpayer is on. This category is not firm-configurable."
        },
        {
          "category": "reward",
          "house_treatment": "income",
          "grey_area": false,
          "us_framing": "Rev. Rul. 2023-14; IRC section 61",
          "definition": "Staking or protocol reward received. House default is ordinary income at fair market value when the taxpayer gains dominion and control."
        },
        {
          "category": "airdrop",
          "house_treatment": "income",
          "grey_area": false,
          "us_framing": "IRC section 61",
          "definition": "Unsolicited token distribution received into the taxpayer's control. House default is ordinary income at receipt. Unsolicited transfers identified as spam or address poisoning are represented under the spam category instead and are not treated as income."
        },
        {
          "category": "vesting",
          "house_treatment": "income",
          "grey_area": false,
          "us_framing": "IRC section 83; IRC section 61",
          "definition": "A token unlock or vesting claim received. House default is ordinary income at fair market value on receipt. Timing turns on when the property substantially vests, and a locked stream may vest ratably rather than in full at the claim."
        },
        {
          "category": "income_receipt",
          "house_treatment": "income",
          "grey_area": false,
          "us_framing": "IRC section 61",
          "definition": "Value received that is ordinary income and does not fit a more specific income category."
        },
        {
          "category": "rebase_reward",
          "house_treatment": "income",
          "grey_area": true,
          "alternate_treatment": "non_taxable",
          "alternate_view": "Deferral view: no income is recognized until the reward is sold.",
          "grey_basis": "Rev. Rul. 2023-14 treats staking rewards as ordinary income at receipt; a minority position defers recognition until disposal.",
          "us_framing": "Rev. Rul. 2023-14; IRC section 61",
          "definition": "Reward accruing through a rebasing or value-accruing wrapper token, where the recognition timing is genuinely contested. House default is income at receipt; the deferral alternative is exposed and configurable per firm."
        },
        {
          "category": "fee_collection",
          "house_treatment": "income",
          "grey_area": false,
          "us_framing": "IRC section 61",
          "definition": "Earned liquidity-pool or protocol fees collected by the taxpayer."
        },
        {
          "category": "perp_close",
          "house_treatment": "income",
          "grey_area": false,
          "us_framing": "IRC section 61",
          "definition": "Realized profit or loss on closing a perpetual futures position. House default is ordinary income or loss."
        },
        {
          "category": "perp_funding",
          "house_treatment": "income",
          "grey_area": false,
          "us_framing": "IRC section 61",
          "definition": "Perpetual futures funding received. House default is ordinary income."
        },
        {
          "category": "fee_payment",
          "house_treatment": "expense",
          "grey_area": false,
          "us_framing": "Fee or cost; not a recognition event on its own",
          "definition": "Network or protocol fee paid.",
          "note": "The reference implementation also represents token approvals and reverted or failed transactions under this category, because the only economic outflow in those transactions is the fee. They are distinguished from an ordinary fee only in the record's review_note prose, not by the category field. See known_implementation_gaps GAP-5. The fee-asset disposition gap described on the expense treatment applies to every record in this category."
        },
        {
          "category": "transfer",
          "house_treatment": "non_taxable",
          "grey_area": false,
          "us_framing": "No recognition event",
          "definition": "Movement of the taxpayer's own assets between wallets under the same beneficial ownership.",
          "note": "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 whose counterparty is not verified as the taxpayer's own wallet is served under this category as non_taxable with the disposition caveat carried in the record's description prose and, in the current implementation, without a review flag. Consumers must not read this category as evidence that a counterparty was verified. See known_implementation_gaps GAP-1."
        },
        {
          "category": "borrow",
          "house_treatment": "non_taxable",
          "grey_area": false,
          "us_framing": "No recognition event",
          "definition": "Loan principal received against collateral; no change in beneficial ownership."
        },
        {
          "category": "repay",
          "house_treatment": "non_taxable",
          "grey_area": false,
          "us_framing": "No recognition event",
          "definition": "Loan principal repaid; no change in beneficial ownership."
        },
        {
          "category": "wrap",
          "house_treatment": "non_taxable",
          "grey_area": true,
          "alternate_treatment": "disposal",
          "alternate_view": "Disposition view: the wrap is an exchange of one asset for another.",
          "us_framing": "IRC section 1001",
          "definition": "One-to-one wrap of an asset. House default is non-taxable with basis carried; the disposition view is exposed and configurable per firm."
        },
        {
          "category": "unwrap",
          "house_treatment": "non_taxable",
          "grey_area": true,
          "alternate_treatment": "disposal",
          "alternate_view": "Disposition view: the unwrap is an exchange of one asset for another.",
          "us_framing": "IRC section 1001",
          "definition": "One-to-one unwrap of an asset. House default is non-taxable with basis carried; the disposition view is exposed and configurable per firm."
        },
        {
          "category": "liquid_staking_mint",
          "house_treatment": "non_taxable",
          "grey_area": true,
          "alternate_treatment": "disposal",
          "alternate_view": "Disposition view: the receipt-token mint is an exchange of the deposited asset for a different asset.",
          "us_framing": "IRC section 1001",
          "definition": "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 per firm.",
          "note": "The grey-area doctrine and firm configurability described here are met on the mint side only. The reference implementation does not represent a liquid-staking redeem under this category and does not honor a firm's election on the redeem side. See known_implementation_gaps GAP-2."
        },
        {
          "category": "collateral_supply",
          "house_treatment": "non_taxable",
          "grey_area": false,
          "us_framing": "No recognition event",
          "definition": "Assets supplied as collateral or deposited into a lending protocol, typically against a receipt token; no change in beneficial ownership.",
          "note": "The reference implementation asserts this as a settled non-taxable treatment and does not expose an alternate position or a firm election, even though the receipt-token structure resembles liquid_staking_mint, which does expose both. See known_implementation_gaps GAP-4."
        },
        {
          "category": "collateral_withdraw",
          "house_treatment": "non_taxable",
          "grey_area": false,
          "us_framing": "No recognition event",
          "definition": "Collateral or a lending-protocol deposit reclaimed; no change in beneficial ownership.",
          "note": "The reference implementation also emits this category for a liquid-staking redeem, where the applicable analysis is the liquid_staking_mint doctrine rather than a settled non-taxable withdrawal. See known_implementation_gaps GAP-2."
        },
        {
          "category": "staking",
          "house_treatment": "non_taxable",
          "grey_area": false,
          "us_framing": "No recognition event",
          "definition": "Principal staked in the same asset with no receipt token issued; no change in beneficial ownership."
        },
        {
          "category": "restaking_deposit",
          "house_treatment": "non_taxable",
          "grey_area": false,
          "us_framing": "No recognition event",
          "definition": "Deposit into a restaking protocol. House default is a conservative non-taxable deposit; the reference implementation does not currently expose an alternate position or a firm election on this category."
        },
        {
          "category": "token_migration",
          "house_treatment": "non_taxable",
          "grey_area": false,
          "us_framing": "No recognition event",
          "definition": "The same asset moved to a new contract in a protocol migration; basis carries."
        },
        {
          "category": "spam",
          "house_treatment": "non_taxable",
          "grey_area": false,
          "us_framing": "No recognition event",
          "definition": "An unsolicited transfer identified as spam or address poisoning. Excluded from the books rather than treated as an income event.",
          "note": "The implementation carries spam as its own internal bucket and clamps it to the non_taxable treatment on the wire so that a consumer branching exhaustively on treatment never sees an out-of-enum value."
        },
        {
          "category": "bridge_transfer",
          "house_treatment": null,
          "grey_area": false,
          "definition": "Cross-chain movement of the taxpayer's own assets. A bridge that swaps into a different asset en route is a disposition of the source asset and is represented as swap.",
          "note": "This Standard does not fix a house treatment for this category. v1.0.0 published bridge as a settled non_taxable, which overstated the contract: the reference implementation derives no treatment for this category at serve time, so the treatment travels from the stored record and is not determined by the category. Consumers must read the treatment field and must not assume non_taxable from the category. See known_implementation_gaps GAP-3."
        },
        {
          "category": "deposit",
          "house_treatment": null,
          "grey_area": false,
          "definition": "A generic custody deposit that was not resolved to a more specific category.",
          "note": "This Standard does not fix a house treatment for this category. The reference implementation derives no treatment for it at serve time; the treatment travels from the stored record. See known_implementation_gaps GAP-3."
        },
        {
          "category": "withdrawal",
          "house_treatment": null,
          "grey_area": false,
          "definition": "A generic custody withdrawal that was not resolved to a more specific category.",
          "note": "This Standard does not fix a house treatment for this category. The reference implementation derives no treatment for it at serve time; the treatment travels from the stored record. See known_implementation_gaps GAP-3."
        },
        {
          "category": "unclassified",
          "house_treatment": "needs_review",
          "grey_area": false,
          "us_framing": "Deferred to a reviewer",
          "definition": "The transaction shape was not resolved to a category the implementation is willing to assert. Served with treatment needs_review and taxable null."
        },
        {
          "category": "needs_review",
          "house_treatment": "needs_review",
          "grey_area": false,
          "us_framing": "Deferred to a reviewer",
          "definition": "A terminal deferral: the implementation declines to assert a treatment and routes the record to a human. Served with treatment needs_review and taxable null."
        }
      ],
      "retired_aliases": {
        "note": "These four names were published in the v1.0.0 category vocabulary. The reference implementation cannot emit any of them; each was a documentation error rather than a category that was removed. They are retained here so citations against v1.0.0 remain resolvable, and they map to the names actually emitted. A conforming implementation must not emit a retired alias.",
        "values": [
          {
            "retired": "collateral",
            "emitted_instead": [
              "collateral_supply",
              "collateral_withdraw"
            ],
            "reason": "The single name was published for what the implementation represents as two directional categories."
          },
          {
            "retired": "stake",
            "emitted_instead": [
              "staking"
            ],
            "reason": "stake is an accepted input spelling, never an emitted value."
          },
          {
            "retired": "unstake",
            "emitted_instead": [
              "collateral_withdraw"
            ],
            "reason": "The word maps to a differently named category on the wire. A consumer keying on unstake never matches a record. This is the sharpest of the four errors published in v1.0.0."
          },
          {
            "retired": "bridge",
            "emitted_instead": [
              "bridge_transfer"
            ],
            "reason": "bridge is an accepted input spelling, never an emitted value."
          }
        ]
      }
    },
    "grey_area_doctrine": {
      "requirements": [
        "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 in 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."
      ],
      "grey_area_categories_v1_1": [
        "liquidity_add",
        "liquidity_remove",
        "wrap",
        "unwrap",
        "liquid_staking_mint",
        "liquidation",
        "rebase_reward"
      ],
      "firm_configurable_categories_v1_1": [
        "liquidity_add",
        "liquidity_remove",
        "wrap",
        "unwrap",
        "liquid_staking_mint",
        "rebase_reward"
      ],
      "note": "The standard describes positions and their basis; it does not assert a filing position for any taxpayer. 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. v1.0.0 stated that the liquid_staking_mint doctrine applies symmetrically to the redeem side. That claim is withdrawn: it is not true of the reference implementation, which represents a redeem under a different category, does not attach the liquid-staking grey block to it, and does not honor a firm's liquid-staking election on it. See known_implementation_gaps GAP-2."
    },
    "confidence_semantics": {
      "range": {
        "type": "integer",
        "minimum": 0,
        "maximum": 100
      },
      "meaning": "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.",
      "role": "A routing signal gating one decision: whether the record is served as a treatment or routed to a human. It is not a probability that the treatment is correct and must not be presented as one.",
      "note": "How any implementation computes the score, and the thresholds at which it routes, are serve parameters and are out of scope for this standard."
    },
    "review_contract": {
      "invariant": "treatment needs_review, the needs_review flag being true, and taxable being null are one state and always travel together. needs_review is both a treatment value and a boolean field, and they never disagree.",
      "rule": "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; consumers must never coerce null to false. A review-flagged record belongs in a review queue, never in the books.",
      "invariants": [
        "taxable is null if and only if taxability is not asserted",
        "taxable: null implies needs_review: true",
        "treatment: needs_review implies needs_review: true",
        "needs_review: true implies treatment: needs_review and taxable: null, whatever the record's category",
        "deferring is a designed behavior of a conforming implementation, not a failure state"
      ]
    },
    "evidence_standards": [
      "Receipt-derived legs: per-leg asset movements derive from the transaction receipt and its logs, 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.",
      "Replayed examples: published example records are verbatim captures of real output, replayable against the live implementation, honest deferrals included."
    ],
    "known_implementation_gaps": {
      "note": "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.",
      "values": [
        {
          "id": "GAP-1",
          "affects": [
            "transfer"
          ],
          "gap": "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.",
          "consumer_guidance": "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."
        },
        {
          "id": "GAP-2",
          "affects": [
            "liquid_staking_mint",
            "collateral_withdraw"
          ],
          "gap": "A liquid-staking redeem is served under the collateral_withdraw category. 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. The grey-area doctrine's configurability requirement is therefore met on the mint side only.",
          "consumer_guidance": "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 and note that a token bought on market and redeemed above basis is a disposition."
        },
        {
          "id": "GAP-3",
          "affects": [
            "bridge_transfer",
            "deposit",
            "withdrawal"
          ],
          "gap": "The reference 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.",
          "consumer_guidance": "Read the treatment field. Never infer a treatment from these category names."
        },
        {
          "id": "GAP-4",
          "affects": [
            "collateral_supply"
          ],
          "gap": "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 it is visible in the published example set.",
          "consumer_guidance": "Treat the absence of a grey block on collateral_supply as an implementation limit rather than as a finding that the position is settled."
        },
        {
          "id": "GAP-5",
          "affects": [
            "fee_payment"
          ],
          "gap": "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.",
          "consumer_guidance": "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."
        },
        {
          "id": "GAP-6",
          "affects": [
            "fee_payment",
            "expense"
          ],
          "gap": "Paying a fee in appreciated crypto is a disposition of the fee asset under IRC section 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 shared gap in both documents rather than a divergence between them, and closing it requires per-transaction fee basis lots in the implementation.",
          "consumer_guidance": "If your books require gain or loss on the fee asset, compute it outside these records."
        },
        {
          "id": "GAP-7",
          "affects": [
            "nft_mint",
            "swap"
          ],
          "gap": "There is no nft_sale category. A secondary-market NFT disposal is represented as swap, so the collectibles question under IRC section 408(m) cannot be answered from the category field.",
          "consumer_guidance": "Identify NFT disposals from the asset legs rather than from the category."
        },
        {
          "id": "GAP-8",
          "affects": [
            "fee_payment",
            "expense"
          ],
          "gap": "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.",
          "consumer_guidance": "Where the engagement's fee policy needs the amount, compute it from the transaction receipt (gasUsed times effectiveGasPrice) via any public RPC; the record's hash and chain identify the receipt."
        }
      ]
    },
    "versioning": {
      "scheme": "semver",
      "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 is recorded in the errata array, never folded silently into a minor release.",
      "note": "Every change is logged in the changelog array. Superseded versions remain published at their own versioned URLs so citations stay stable; see version_history."
    },
    "errata": [
      {
        "version": "1.0.1",
        "date": "2026-08-12",
        "field": "treatments.values[expense].taxable",
        "published_value": true,
        "corrected_value": false,
        "reason": "The published value was factually wrong about the reference implementation. The engine has always emitted taxable: false for the expense 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. Under this document's own versioning rule a change to the meaning of an existing field value is major, so the correction is published as an explicit erratum rather than folded silently into a minor release.",
        "scope": "Documentation only. No implementation change was required or made.",
        "related_gap": "GAP-6"
      },
      {
        "version": "1.1.1",
        "date": "2026-08-20",
        "field": "known_implementation_gaps.values[GAP-5].gap",
        "published_value": "distinguishable from an ordinary fee only in the record's review_note prose",
        "corrected_value": "distinguishable from an ordinary fee only in the record's description prose; review_note is null on non-review records",
        "reason": "The published statement was factually wrong about the reference implementation when published: the wire contract populates review_note only on review-routed records, and approval and failed-transaction records serve confidently, so their review_note has always been null on the wire. The distinguishing prose has always traveled in description. Verified against the live wire on fresh records 2026-08-20.",
        "scope": "Documentation only. No implementation change was required or made.",
        "related_gap": "GAP-5"
      }
    ],
    "conformance": {
      "criteria": [
        "Emits records that validate against the cte-classification-v1 record schema.",
        "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 for the legs and amounts it reports."
      ],
      "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 requires, the difference is published in known_implementation_gaps rather than resolved by wording.",
      "reference_implementation": {
        "name": "CryptoTaxEdge API",
        "endpoint": "POST https://app.cryptotaxedge.com/v1/classify",
        "documentation": "https://dashboard.cryptotaxedge.com/api",
        "openapi": "https://dashboard.cryptotaxedge.com/api/openapi.json",
        "conformance_status": "Conforms to the vocabulary and review contract of v1.1. The grey-area doctrine's configurability requirement is not met on the categories named in known_implementation_gaps GAP-2 and GAP-4."
      },
      "note": "Any tool may implement this standard."
    },
    "license": {
      "type": "CC BY 4.0",
      "url": "https://creativecommons.org/licenses/by/4.0/",
      "terms": "The specification text and this JSON document are published under Creative Commons Attribution 4.0 International; attribution to CryptoTaxEdge is required. The license covers the text, not the marks.",
      "trademarks": "'CryptoTaxEdge Classification Standard' and 'CTE Standard' are trademarks of Stursberg LLC dba Crypto Tax Edge. 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; only CryptoTaxEdge may describe an implementation as official or certified. The license permits redistribution of this text with attribution; what the marks reserve is the naming, so 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 must be namespaced with an x- prefix and are not part of the Standard unless ratified. The canonical URL and semver stewardship remain with CryptoTaxEdge.",
      "disclaimer": "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."
    },
    "changelog": [
      {
        "version": "1.1.1",
        "date": "2026-08-20",
        "summary": "Gap-section accuracy release: GAP-1 updated to the live review-routing behavior, GAP-5 erratum (description, not review_note), GAP-8 added (no fee quantum).",
        "changes": [
          "Updates GAP-1 to record an implementation change made 2026-08-12 and deployed after 1.1.0 published: an unverified one-way transfer is review-routed in both directions (treatment needs_review, taxable null) with the identification kept in category. The vocabulary half of the gap stands.",
          "Erratum: GAP-5 said the approval and failed-transaction distinction rides in review_note; it rides in description, and review_note is null on non-review records. See the errata array.",
          "Adds GAP-8: fee_payment records carry no fee quantum (assets.gas null on freshly classified EVM records)."
        ]
      },
      {
        "version": "1.1.0",
        "date": "2026-08-12",
        "summary": "Reconciles the published vocabulary with the vocabulary the reference implementation actually emits, and publishes the differences that remain.",
        "changes": [
          "Adds the 18 categories the reference implementation emits that v1.0.0 omitted: 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, and withdrawal. The v1.0.0 vocabulary named 17 categories against 31 emitted, and 6 of the 17 published example records carried a category outside it.",
          "Reclassifies collateral, stake, unstake, and bridge as retired aliases. The reference implementation cannot emit any of the four; each was a documentation error rather than a removed category. They are retained with a mapping to the emitted names so citations against v1.0.0 stay resolvable. unstake is the sharpest case: the word maps to collateral_withdraw on the wire, so a consumer keying on unstake never matched a record.",
          "Carries the v1.0.1 erratum on the expense treatment: taxable is false, not true. See the errata array.",
          "Withdraws the claim that the liquid_staking_mint doctrine applies symmetrically to the redeem side. It is not true of the reference implementation and is now published as GAP-2.",
          "Removes the fixed non_taxable house treatment from bridge and publishes bridge_transfer, deposit, and withdrawal with no house treatment, because the implementation derives none at serve time and the treatment travels from the stored record. This is GAP-3.",
          "Adds liquidation and rebase_reward to the grey-area category list, which the implementation already treats as grey, and separates the grey list from the narrower list of firm-configurable categories.",
          "Rewrites 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, which contradicted this document's own statement that serve parameters are out of scope.",
          "Softens closed_at_version to enumerated_at_version, resolving a contradiction with the record schema, which documents category as an open vocabulary that consumers must tolerate unknown values from.",
          "Adds a known_implementation_gaps section covering seven points where the reference implementation does not deliver what a reader would reasonably expect, including unverified-counterparty sends served as non-taxable transfers without a review flag, the lending versus liquid-staking grey asymmetry, the collapse of approvals and reverted transactions into fee_payment, the unbooked disposition of the fee asset, and the absence of an NFT sale category.",
          "States that conformance is measured against the published wire contract, and that this standard's vocabulary is maintained to match what the reference implementation emits.",
          "Adds the treatment precedence rule: review routing overrides a category's house treatment on the wire.",
          "States the needs_review invariant once at the top of the review contract, since needs_review is both a treatment value and a boolean field.",
          "Adds the citations the implementation already carries: Rev. Rul. 2023-14 on reward and rebase_reward, IRC section 83 on vesting.",
          "Adds the CC BY adaptation remedy to the trademark terms: an adaptation must indicate that it is modified and must not use the marks.",
          "Publishes the frozen v1.0.0 snapshot at its own versioned URL with an erratum notice, per the versioning policy's promise that superseded versions stay resolvable."
        ]
      },
      {
        "version": "1.0.1",
        "date": "2026-08-12",
        "summary": "Erratum.",
        "changes": [
          "Corrects treatments.values[expense].taxable from true to false. The published value never matched any record the reference implementation emitted. Documentation only; no implementation change was required or made. See the errata array."
        ]
      },
      {
        "version": "1.0.0",
        "date": "2026-08-12",
        "changes": [
          "Initial release: formalizes the public CryptoTaxEdge taxonomy as a versioned, citable, machine-readable standard.",
          "Defines the closed five-treatment enum with US-law framing.",
          "Defines the v1.0 category set with house-default treatments and grey-area flags.",
          "Defines the grey-area doctrine, confidence semantics, review contract, evidence standards, and conformance criteria.",
          "Adopts cte-classification-v1 as the wire contract by reference."
        ]
      }
    ]
  }
}