Reference

Canonical classification examples

Fifty-three 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 daily: if the engine's answer for any capture drifts, the site build fails rather than publishing a stale claim.

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

The pack

Captures 01 to 17 taken 2026-08-12, with three re-captured 2026-08-18; captures 18 to 53 taken 2026-08-21; captures 29 and 34 re-captured 2026-09-01 after the daily replay caught both drifting to a review deferral (the annotations below say why); capture 09 re-captured 2026-09-01 with its verdict unchanged (the note under the flagged-treatment rows says why). All 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 nine 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, or where the evidence did not corroborate a verdict strongly enough to serve it.

• 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.
• 22-needs_review.json: Morpho Blue. The evidence pointed at a collateral supply but corroborated it at only 45 percent. Asserting non-taxable on weak evidence could hide a taxable disposal or income event, so the row routes to review instead.
• 29-needs_review.json: Sky Savings Rate (sUSDS). Re-captured 2026-09-01. The 2026-08-21 capture of this transaction served liquid_staking_mint at confidence 50 with the treatment already review-flagged. A cached evidence anchor then expired on schedule, and the fresh run corroborated the same candidate read at 48 percent, under the serving line, so the engine now defers the whole row and states the candidate verdict and the reason in the response. The daily replay caught the change and we published what the engine returns today rather than keeping the stronger older capture. That is the honesty contract working.
• 32-wrap.json: Lido. A wstETH wrap. Captured in August at 22 percent and routed to review; on 2026-09-03 the founder ruled the wstETH wrap and unwrap a non-taxable form change of the same staked claim (F2), and the example now serves that verdict deterministically.
• 34-needs_review.json: Renzo RestakeManager (EigenLayer). Same event as capture 29, re-captured the same day: originally served liquid_staking_mint at confidence 52, review-flagged; the fresh run corroborates the same read at 48 percent, under the serving line, so the row now routes to review with the candidate verdict named in the response. Both rows moved because the evidence weakened, not because the engine changed, and the replay guard exists to surface exactly that.
• 51-needs_review.json: GMX V2. A multicall that wraps ETH and posts WETH into GMX V2's OrderVault as perpetual futures margin. The candidate read is a non-taxable collateral posting, but an undecoded event log leaves the user-level flow uncorroborated, so the engine defers rather than asserting it.
• 52-needs_review.json: GMX V2. A second GMX V2 margin flow corroborated at only 48 percent, routed to review for the same reason.

Eight further rows identify the category 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. Unverified one-way transfers route to review in both directions: an unflagged outgoing send would leave no trace of a possible disposal at all, and an unverified receipt can be income, a gift, or a self-transfer, which the engine holds no ownership evidence to tell apart. 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. Among the newer captures, 26, 27, and 28 are vault deposits and withdrawals booked non-taxable in form but flagged because vault-share tax character depends on the specific vault and on how the position was acquired; and 46-transfer.json is a cross-chain send through a burn-and-mint bridge to a recipient the engine cannot verify as the taxpayer's own wallet, the same one-way-send rule as captures 01 and 02. (Captures 29 and 34, which sat in this group until 2026-09-01, now defer on the category itself; their entries are in the list above.) Capture 09 was re-captured on 2026-09-01 after one replay run, minutes after an engine deploy, served this transaction as income at confidence 77 with no review flag: that run did not re-derive the token legs the review check depends on, so the older cached verdict went out unflagged. The fresh capture, and every run since, returns the review-routed verdict at 70 again; that is what is published, and the only change in the file is punctuation in the response text. The replay guard exists to catch exactly that kind of one-run divergence, and this note is the record of it. 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. An illustrative named sample of the same wire contract is at /examples/sample. To reproduce any row live, enter its transaction hash in the Classification Explorer.