← Blog

2026-08-03

Why "generic transfer" is the most common line in a DeFi tax export

Export a year of on-chain activity from any mainstream crypto tax tool and the transactions from Uniswap, Aave, or Compound usually come back labeled correctly: swap, deposit, borrow, repay. The transactions from a newer or smaller protocol — a niche Curve pool, a Convex vault, an Aerodrome LP position, a bridge route through Across — come back as a "transfer." No category, no counterparty, no indication of what actually happened on-chain.

That's not a bug in those tools. It's a coverage gap. Every mainstream tax product ships a hand-built parser per protocol, and there are far more DeFi protocols than any one vendor has engineering time to cover. The long tail keeps growing faster than the parser list does, and the newest protocols — the ones early users are actually in — are always the last to get support, if they ever do.

The result lands on two different people:

• Tax software vendors, who'd rather ship broader coverage than build and maintain a bespoke parser for every protocol that launches.
• DeFi users, who end up relabeling their own "transfer" rows by hand every tax season, reverse-engineering what a transaction actually did from a block explorer.

That's the specific gap this API targets: take a raw on-chain transaction from one of these long-tail protocols and return a labeled category — swap, LP add, LP remove, reward claim, bridge fill — with the on-chain reasoning attached, so it can be imported instead of hand-corrected.

One line we're careful about: this is classification, not tax advice. The output is "this transaction is a Curve LP deposit," never a cost basis, a tax position, or a "you owe $X" statement. That distinction is deliberate, not incidental — it's what lets this stay a data layer that tax software and power users can build on, rather than a product that competes with the tax judgment those tools already provide.