Tax software guesses
at your perps.
We recompute them.

Paste a Hyperliquid address. Basisproof rebuilds the record fill by fill — trades, funding, signed fees — then closes an independent account-value identity on it. Where the venue's own numbers disagree, that disagreement is printed, not hidden.

free while in testing · full corrected reports at the 2027 filing season · not tax advice

builder-dex aware · full history, not the last 30h · axis-2 identity verified
basisproof · tax checkverified
0x7fda…17d1last 90 days
realized PnL+$412.9k · 18,204 fills · full history
funding net+$38.1k · 41,880 events
fees net−$9.4k · rebates included
axis 1 · vs venue curve+$0.2k ≈ Δ unrealized PnL
axis 2 · account identityΔAV − flows = PnL · closed $0.4
two independent axes agree — the record holdsMODEL

illustrative output · run the live check on /tax

how it works

Three steps. Every number re-derivable.

01

Paste the address

Any Hyperliquid trading address. The data is public on-chain — no keys, no sign-up, nothing uploaded.

02

We rebuild the record

Every fill's realized PnL, every funding event, fees net of rebates — summed over your window, from the venue's own API.

03

We reconcile it

Our sums are checked against the venue's official sampled curve. The residual is printed with its likely causes — that gap is where tax reports go wrong.

funding settles hourly — a single open position can generate 8,760 taxable events a year · coarse summaries miss them

full methodology

coverage

If it happened on the venue, it is in the arithmetic.

The difficulty isn't volume — it's that each account type exercises a different venue semantic, and every one of them has a silent failure mode in a naive importer.

main-perp scalpers

High-frequency accounts

100k+ fills per window is normal — one account we verified ran 1.36M fills in a quarter. The venue API retains ~30h of fills, so the record is rebuilt from a chain indexer and reconciled cell-identical where the two overlap.

builder-dex traders

HIP-3 venue accounts

xyz, flx, vntl, km and friends now carry over half of perp volume — with their own margin pools and per-dex send flows. Tools that enumerate the main book miss this universe entirely; we classify per dex.

multi-wallet users

Sub-accounts & linked wallets

subAccountTransfer, internalTransfer and send rows move value between your own addresses. Read naively they look like income or loss twice; classified correctly they net out of the identity.

spot ↔ perp movers

Mixed-activity accounts

accountClassTransfer shifts value across the perp boundary; spotTransfer does not touch perp account value at all. Getting that single semantic wrong was our own biggest identity bug — it is why the second axis exists.

stakers & vault users

Beyond trading

cStakingTransfer, vaultDeposit, spotGenesis (the HYPE airdrop) — boundary flows that move account value without being PnL. Each is classified separately so flows and performance never blur.

market makers

Fee-tier & rebate accounts

Fill fees are signed — negative is a cost, positive is a rebate. Six figures of rebates summed with the wrong sign is a real misreport. Funding streams are summed per market, paid vs received.

And where we show the seam instead of hiding it: on builder-dex-heavy accounts the venue's own series disagree — its PnL history excludes unrealized dex PnL that its account-value history includes. We print the measured divergence rather than picking a side. An honest gap beats a clean lie.

different by construction

Other tools trust the venue. We check it.

a typical tax tool
basisproof
Re-prints the venue's exported numbers
Recomputes every fill independently, then proves it two ways
Treats the venue's PnL as ground truth
Treats it as one axis — an independent account-value identity must agree
Stops at the venue API's ~30-hour fill window
Full history from an independent chain indexer, any window
Builder-dex activity missing or miscounted
Builder-dex aware: dex fills, dex pools and dex margin all classified
When the venue's data contradicts itself, you never see it
The disagreement is printed with a measured amount
<$1
identity gap on $300M+ of monthly flow
$8.3k
gap on $120M of market-maker churn (0.007%)
834,902
fills reconstructed in a single window
$5M+
venue-vs-venue divergence found and disclosed

measured on live accounts during development — every figure re-derivable

what this gets you

  • Know whether the venue's own numbers are internally consistent before you hand them to a tax tool or a preparer.
  • Catch the silent gaps — truncated fill history, mis-signed fees, misclassified transfers — that turn into wrong basis.
  • Keep an evidence trail: every figure is a sum you can re-derive, not a black-box estimate.

why this exists

The 1099-DA era started. Basis didn't come with it.

17.4M
US taxpayers have reported crypto sales to the IRS
IRS administrative data, 2013–2021
32–56%
of US crypto owners actually report — 1099-DA matching is closing that gap
Review of Accounting Studies, 2026
$5,000–12,000
what accountants charge for complex DeFi reconciliation
2026 pricing guides
Aug 2026
a perp-fee bug in a leading tax tool's Hyperliquid integration, fixed that month
public feedback thread

brokers report gross proceeds for 2025 sales · mandatory basis reporting from 2026 · first full-basis filing season is 2027

the contract

Every output carries its label.

A tax number you cannot re-derive is a liability. Every Basisproof output is either a sum you can reproduce from the venue's own API, or a reconciliation with its residual explained — and anything we cannot establish is printed as unknown, not filled with a guess.

FACT

Sums of venue-reported per-fill values — realized PnL, funding events, fees. Re-run the same window and you get the same numbers.

RECONCILIATION

Our sums are checked against the venue's official sampled curve. The residual is printed with its likely causes, never hidden.

SCOPE

One address, one venue, one window. Other wallets, CEX accounts and pre-transfer basis are invisible from here. Not tax advice.