Reference

Canonical classification examples

Seventeen verbatim request/response captures from the live CryptoTaxEdge engine: real transactions, independently sourced, saved exactly as the API returned them. Each file is stamped with its capture date and policy version, and the whole pack is replayed against the live engine nightly: if the engine's answer for any capture drifts, the site build fails rather than publishing a stale claim.

The composition: fourteen identified classifications spanning transfers, swaps, wrapping, liquid staking, reward claims, liquidity add/remove, lending collateral, and bridging (four of those carry a review flag on the treatment with the reason stated in the response), plus three annotated deferrals where the engine declines to guess.

The pack

Captured 2026-08-12, with three examples re-captured 2026-08-18, under policy version us-default-2026-08. Every row links to the raw JSON, which validates against the published cte-classification-v1 schema. Wire values are documented in the classification taxonomy and enumerated in the Classification Standard v1.1. Confidence is a corroboration signal, not an accuracy percentage: it reflects how well the available evidence agreed on the classification, and it gates one decision, whether the record is served as a treatment or routed to a human. Scores are not comparable across transactions and are not a probability that the treatment is correct.

Why the engine defers

The three captures whose category is needs_review are not failures to compute; they are cases where asserting a treatment would require information the transaction hash alone cannot provide.

• 15-needs_review.json: AlloXCheck. Unverified, unlabeled contract with no decodable asset legs. Asserting any treatment would be a guess, so the engine defers.
• 16-needs_review.json: Uniswap V4. The swap's beneficiary is an unverified smart contract, not the transaction sender. Until the client confirms they own that contract, disposal attribution is genuinely ambiguous.
• 17-needs_review.json: ERC-4337 EntryPoint v0.7. Account-abstraction bundle: the tx sender is the bundler, not the taxpayer, so per-user classification requires the smart-account wallet address.

Four further rows identify the category confidently but flag the treatment for review, with the reason stated in the response itself. 01-transfer.json and 02-transfer.json are one-way sends whose recipient could not be verified as the taxpayer's own wallet. From a hash alone the engine holds no evidence about who the recipient is, so booking either as a non-taxable self-transfer would silently drop a possible IRC §1001 disposal (a payment, a sale, or a gift) out of the books. The house non-taxable default still covers unverified incoming transfers, where a wrong call at least leaves an asset in the books carrying a basis question that a later disposal forces someone to answer; an unflagged outgoing send leaves no trace at all, so that direction goes to a human instead. Confirming that the recipient is the client's own wallet is what settles the treatment. 09-reward.json and 11-liquidity_remove.json flag for different reasons: a reward claim where the income amount needs confirming, and a liquidity withdrawal whose harvest component should be split from principal before booking. The remove defers because of that withdraw-and-harvest income-split check (a possible reward leg received alongside the pool principal), not because the exit policy differs: the principal's exit follows the same house disposal default as the add. Flagged, not guessed.

What to do with these

Use them as fixtures for an integration before you mint a key, as ground truth for what the classification API actually returns (including the shape of a deferral), or as a check against the OpenAPI 3.1 spec. To reproduce any row live, enter its transaction hash in the Classification Explorer.