A single operator’s scan is an observation. The way to check it is to rerun it, not to take a signed stamp on faith. Trust here is reproduction from public chain data. It is not consensus, not a zero-knowledge proof, not an on-chain attestation, and not a validator network.
Machine-readable copy of this page: /method.json.
What has to be true before a dollar is shown
- The balance tie-out on every scanned wallet matches the chain. If it does not, the dollar figures are withheld — that is the gate, not a footnote.
- Every finding cites a public transaction hash.
- The output is a software step (mark a transfer, add a wallet). It is not tax advice, and it does not say a row is or is not taxable.
- When coins arrived with no purchase on record, a live scan may list the sending addresses so you can add one and re-run. A gift, an exchange withdrawal, and a move from another wallet you hold look the same on chain — the list does not say which. Saved links never store those full addresses.
To rerun a published example:
- Paste the same public addresses and cutoff, or drop the same CSV, on /check.
- Read the balance tie-out table. If it does not match, the dollar figures were withheld — that is the gate, not a caveat.
- Open every finding's transaction hash on a public explorer for that chain.
Matching a tax-software CSV against the chain has its own false-positive rule (unique within tolerance; ambiguity is reported, never guessed) on The Tool Error Ledger.
Edge cases the engine names
This is the log that compounds. Each block is a failure mode tax software hits, the signal the engine uses, and the software step on the repair table. A public example is linked only when a published article exists — “None yet” means we have not demonstrated that type in public, not that it does not fire.
Self-transfer booked as a sale transfer_broken_basis
What the software typically does. A move between wallets you own is imported as a disposal on the sending side and a $0-basis deposit on the receiving side.
How the engine flags it. The same disposal's realized gain differs between a linked run (transfers carry basis) and a naive run (they do not).
In your software. Mark as transfer in your tax software This looks like a move between wallets in the scanned set. In the software, mark the matching row as a transfer (not a disposal).
Public example. Same engine, linked vs unlinked, on a public cluster. Not a measured error in someone else's software.
Bridge leg that drops basis bridge
What the software typically does. One leg is booked as a withdrawal or sale; the other arrives with no purchase price.
How the engine flags it. A bridge deposit or withdrawal is one-sided or attrited in the scanned set — the matching leg is missing or the amount does not survive.
In your software. Mark as transfer in your tax software This looks like a bridge leg. In the software, mark both legs as transfers so the receiving side keeps its cost.
Public example. None yet
Elastic-supply adjustment rebase
What the software typically does. A supply change is imported as income or as a disposal, with no matching purchase.
How the engine flags it. The decoder flagged an elastic-supply (rebase) adjustment. Treatment is uncertain, so the row is named rather than classified as a transfer.
In your software. Review this row in your tax software This row could not be classified with certainty. Leave it for the software's review queue.
Public example. None yet
No usable market price unpriced
What the software typically does. The software guesses a price, drops the row, or books proceeds against a made-up cost.
How the engine flags it. No fair-market value could be resolved for this event, so it is skipped rather than priced from a guess.
In your software. Review this row in your tax software This row could not be classified with certainty. Leave it for the software's review queue.
Public example. None yet
Disposal with no recorded purchase missing_basis
What the software typically does. The software books the whole proceeds as gain because the lot has no arrival on file.
How the engine flags it. A disposal consumed coins that have no recorded acquire in the scanned wallets or uploaded CSV.
In your software. Add wallets to fill missing basis The disposal has no recorded purchase. Add the sending wallet or the exchange CSV that bought these coins, then re-run.
Public example. None yet
Coins arrived with no purchase on record unattributed_inflow
What the software typically does. The software assigns fair-market value as cost, or books $0, for coins that appeared without a matching buy.
How the engine flags it. An inflow has no consideration on record. It is booked at $0 cost, not at FMV, so a guessed basis cannot walk into the figures.
In your software. Add wallets to fill missing basis Coins arrived with no purchase on record. Add the source wallet or the exchange CSV, then re-run.
Public example. None yet
Blank or missing cost on a 1099-DA / tax-software export blank_reported_basis
What the software typically does. A blank Box 1g or a missing purchase-price column is imported as $0, so the whole sale is taxed as gain.
How the engine flags it. The file parser lists sale rows whose reported basis is blank. Wallets are not required for this preview; they fill the gap on the next run.
In your software. Add wallets to fill missing basis This row has no purchase price in the file. Add the wallets that held these coins so the scan can fill the gap.
Public example. None yet
Adding a new finding type to the engine without a row here fails the build. That is how the log stays complete as the tax-year pack sees more history.