What you can build with the CryptoTaxEdge API and MCP

July 15, 2026 · CryptoTaxEdge Team

CryptoTaxEdge turns one on-chain transaction hash into two things in a single API call: a verified decode of what happened, and a US tax treatment with verdict, confidence, reasoning, and review routing.

Consumer tax apps label transactions for DIY filers. Raw decode APIs return categories you still have to interpret. This layer returns the decode and the tax verdict together, as an API and over MCP, so platforms and CPA firms do not have to rebuild the classifier.

The short answer

To classify a crypto transaction for US tax, you first decode the on-chain actions accurately, then assign a treatment: disposal, income, non-taxable, expense, or needs review. CryptoTaxEdge does both from a transaction hash in one API or MCP call, and returns the verdict, its confidence, the reasoning, the defensible alternative where the law is contested, and a review flag when it is not sure.

CryptoTaxEdge does not calculate gains, compute holding periods, or file tax forms. It classifies the tax treatment of on-chain events so platforms and CPA firms can route them into their own workflow.

The data already exists across the stack: ledgers have the legs, wallets have the movements, trackers have the history. Two hard problems still sit between that data and a tax classification a preparer can review. The first is reading the transaction correctly at all. Bundled operations, proxy contracts, and protocol wrappers routinely make a loan look like a swap, a bridge look like a sale, an internal transfer look like income. Off-the-shelf labels go blank or go wrong on exactly the high-dollar, multi-leg transactions where the exposure sits.

There is a standard answer to the first problem: pull classifications from a decode API and route them into the firm's own taxability stance. It is half an answer. A stance applied to a bad read is still a bad call, and the classifications you route are only as good as a decode you cannot verify. A decode API returns a label you cannot check. This layer returns the verdict with its reasoning shown, so the read itself is auditable before your stance ever touches it.

The second problem is the one nobody owns even when the read is right: the verdict. A label is not a tax treatment. The thing an accountant signs their name to is a policy-aware call on whether an on-chain event is a disposal, income, or non-taxable, why, what the defensible alternative is, and whether the answer is certain enough to stand behind at all. No tool in the stack reliably commits to it.

CryptoTaxEdge returns both in one call: the on-chain decode and the tax verdict. The decode is not a model guess. It is backed by 13,000+ verified protocol rules across 80+ chains, deterministic guards that outrank anything a model proposes. The verdict carries its confidence, its reasoning, the defensible alternative where the law is contested, and a review flag instead of a forced guess. And where a treatment is genuinely contestable, grey-area defaults are configurable to your firm's stance, so the routing you wanted still happens, on top of a read the engine stands behind.

On-chain decode and tax treatment, one call. It ships as an API and over MCP, so you do not have to rebuild a tax classifier inside your own product.

What teams can build with it

Every product below is built on the same call and gets both halves of it, the decode and the verdict. What differs is what you do with the verdict and where you send the ones it is unsure about.

Crypto tax platforms. Run a second-look review before a client export leaves the building. Send the transactions you have already labeled, compare the layer's verdict against yours, and surface the disagreements: the rows where your export said non-taxable and the layer says review this one. Grey-area defaults follow your house policy, so what surfaces is a read problem, not policy noise. A preparer resolves it before filing, not inside an amended return.

Crypto subledgers and digital-asset general ledgers. Stamp each journal line with its tax treatment the moment it lands, along with a plain-English reason you can drop straight into the memo field. The tax character of every entry is set at the source, instead of being reconstructed under deadline at year-end.

Firm workflow tools. Turn a list of hashes into a workpaper that hides the hundreds of clean disposals and puts only the handful that need a judgment call in front of staff, each with the reasoning and the defensible alternative printed next to it. The same engine drives a month-end close reconciliation that flags the deltas before the period locks.

Wallets and portfolio trackers. Show a tax-treatment history on a transaction feed, a likely taxable disposal here, a flagged-for-review there, as informational context, without pretending to file anything for the user. Uncertainty shows up as uncertainty, which is what keeps it honest.

Corporate treasury and close tools. Catch the events that carry a tax consequence, a disposal here, an income receipt there, and raise them to whoever owns the close while there is still time to handle them, instead of finding them in a year-end scramble.

Broker and reporting-prep pipelines. Feed the tax character into 1099-DA-adjacent reporting as an input signal. The layer classifies; your pipeline decides what to do with the classification. It does not file the form, and it does not claim to.

Where it fits

Wherever it shows up, the integration is the same three steps.

1. Ingest. You already have the transaction: your own indexer, a wallet connection, or a hash someone entered.
2. Classify. You send it to the layer and get back a treatment, a confidence score, and either a clean verdict or a flag that says a human should look.
3. Branch. Confident, clean verdicts flow straight into your books or your export. The flagged and grey-area ones get routed to a review queue before anything posts.

The layer does not own your ledger, your chart of accounts, your close workflow, or your accountant UX. It owns exactly one decision, and hands it back with its reasoning shown.

What one call returns

Once you want to wire it in, here is the contract. Send a transaction hash. Get back a verdict with its reasoning attached:

// POST https://app.cryptotaxedge.com/v1/classify
// Authorization: Bearer YOUR_API_KEY
{
  "hash": "0x2807…83c2",
  "chain": "ethereum"
}

And the response:

{
  "api_version": "v1",
  "hash": "0x2807…83c2",
  "chain": "ethereum",
  "category": "swap",
  "treatment": "disposal",
  "taxable": true,
  "confidence": 77,
  "needs_review": false,
  "ledger_action": "Trade",
  "protocol": null,
  "description": "Token swap; a taxable disposition under IRC 1001.",
  "review_note": null,
  "grey_area": null,
  "assets": {
    "sent":     [ { "symbol": "stETH", "amount": "0.002297", "decimals": 18, "action": "transferred", "to":   "0x89c6…f818" } ],
    "received": [ { "symbol": "USDC",  "amount": "3.723749", "decimals": 6,  "action": "received",    "from": "0x1231…4eae" } ],
    "gas": null
  }
}

The fields you build against:

• category is the canonical transaction type (swap, transfer, wrap, reward, liquid_staking_mint, and a vocabulary that grows additively).
• treatment is a closed set of five values you can switch on exhaustively: disposal, income, non_taxable, expense, needs_review.
• taxable is true, false, or null. A null never travels alone. It always arrives with needs_review: true and means undetermined, not "probably fine".
• confidence is 0 to 100. It measures how strongly independent sources agree on the transaction type, not a probability that the answer is correct; when they disagree, the result routes to needs_review.
• needs_review is the honest exit, and the contract form of the guarantee above: when it is true, the layer deferred to a human rather than force a verdict.
• description is the plain-English reasoning, ready to drop into a journal-entry memo.

Here is how that closed set lands on the transaction types a crypto practice sees most. The treatment is the engine's default; the ones marked grey area are firm-configurable, because that is where the law is genuinely contested.

When more than one treatment is genuinely defensible, the response carries a grey_area block instead of a silent guess:

"grey_area": {
  "note": "LP contribution/withdrawal: no LP-specific IRS guidance; general property/realization principle governs.",
  "alternate": { "treatment": "disposal", "taxable": true, "label": "Disposition view (LP entry/exit as a crypto-to-crypto disposal)" }
}

note is the basis: why the position is contestable. alternate is the road not taken: the other defensible treatment, named explicitly, so a reviewer can see both sides on one screen.

What's live today

The classification API and the MCP interface are live behind an API key, same engine behind both. The Classification Explorer is live too: a browser surface where you can enter a hash and read the same verdict, reasoning, and review flag a machine would get. That is the layer you can call today.

The use cases above are integration shapes the contract supports, not customer announcements.

MCP or REST, one engine

There is one classification engine and two ways to reach it. Platforms and pipelines that already move data programmatically use the REST API and switch on the response fields. The second door is MCP, the Model Context Protocol: the standard that lets AI agents call external tools mid-conversation.

Connect the CryptoTaxEdge MCP server to Claude Desktop or any MCP-capable agent, and classification becomes a tool the agent can reach for. An accountant asks about a batch of transactions in plain language; the agent calls the layer and hands back the treatment, the confidence, and a flag on the ones a human should look at. Nobody in that exchange reads a schema or touches an endpoint.

Agents describe transactions well and commit to tax positions badly: a language model will produce a confident answer whether or not one is warranted. MCP puts a real engine behind the conversation instead. The verdict the agent relays carries the same closed treatment set, the same grey-area position, and the same refusal to stamp an uncertain transaction as non-taxable that the API enforces. If you are building an accountant-facing agent, this is a direct way to give it a tax classification with the reasoning attached.

It is the same engine and the same answer, reached through a different surface.

Get a key

Developer access is free to start. Create a key in the dashboard, read the API and MCP contract, and send your first hash. If you want a human view first, the Classification Explorer lets you enter a transaction and read the full verdict, reasoning, confidence, and review flag in the browser before you write a line of integration code.

The engine behind all of it is the same layer: 13,000+ verified rules across 80+ chains. Verified is the load-bearing word: every rule was checked against live transactions before it was allowed to serve. For supported chains and retrievable transactions, what comes back is a treatment, an honest deferral, or an explicit error instead of a silent guess.