The wallet's Arbitrum transaction list contains 16 transactions before the cutoff, and every one of them is inbound. Read that list and you would conclude the address never sold anything on this chain. The chain disagrees: 0.122920998109231953 ETH left the wallet on 2025-12-20, and the scan books it as $366.05 of realized gain against $0.00 of cost basis. The outflow is not in the transaction list because the wallet did not send a transaction. It appears once, as internal transfer index 7, inside an ERC-4337 bundle a third party submitted.
This is the ledger's first measurement on a Layer 2. This is not tax advice. It is a measured run of an open-source engine on a public address, with the limits named.
What we scanned
- Address:
0xab5801a7d398351b8be11c439e05c5b3259aec9b— submitted alone. This is the address our $44,975,739 cluster measurement lists as "VB (legacy)", identified there by its Etherscan public name tag. - Chain: Arbitrum One (
--chain arbitrum). The three prior entries in the Tool Error Ledger are all Ethereum mainnet. - Cutoff: 2025-12-31 (cutoff block 416,593,973)
- Run: local CLI,
maxEvents5,000 (the CLI default), 2026-08-24. Run twice — the second with--refresh, which bypasses every cache and refetches from the chain. Identical output both times: same event counts, same summary, same tie-out row.
The engine read the address's counters as 19 transactions and 1,098 token transfers. Sixteen of the 19 transactions fall before the cutoff; those are what it ingested, plus one internal transfer.
What came back
- Status:
partial - 671 events — 14 acquires, 1 disposal, 0 self-transfers, 0 bridges, 0 fees
- Of those, 656 ERC-20 events across 108 token contracts
- Balance tie-out: PASS — ledger 0 ETH vs on-chain 0 ETH at block 416,593,973, diff 0
- Realized gain, wallets not linked: $366.05
- Realized gain, wallets linked: $366.05
- Potential phantom gain: $0
- Events flagged for professional review: 669
- Findings:
unattributed_inflow× 16 (14 in ETH, 2 in ERC-20 tokens). Every other finding type: zero.
The linked and non-linked runs agree because there are 0 self-transfers in a one-wallet set — the same structural reason the 27,000 ETH allocation case produced no difference. Wallet linking has nothing to link. There were also 0 bridge events: the ETH in this wallet did not arrive through Arbitrum's canonical bridge, so the bridge tagging the engine does on L2 scans had nothing to tag.
The disposal that is not in the transaction list
One transaction carries the entire taxable result:
| field | value |
|---|---|
| transaction | 0x1d24db…d7117 |
| timestamp | 2025-12-20T16:40:59Z (block 412,683,609) |
outer from |
0x4337007aB182EbE9cDB0BC4B96734c32176d44cc — a bundler, not the wallet |
outer to |
0x0000000071727De22E5E9d8BAf0edAc6f37da032 — the ERC-4337 EntryPoint |
outer value |
0 |
| internal transfer #7 | 122,920,998,109,231,953 wei from the wallet to 0x1231DE…F4EaE (LiFiDiamond) |
The wallet is neither the sender nor the recipient of the transaction. It is the account an ERC-4337 user operation was executed for, which is why the outer transaction carries a value of 0 and the ETH movement exists only in the trace. On Arbitrum this address is a contract with an EIP-7702 delegation to AmbireAccount7702 — an ordinary key-controlled address that has delegated execution to a smart-account implementation. That is what makes the account-abstraction path available to it.
The engine picked this up because it reads the explorer's per-address internal-transaction index in addition to the transaction list. That index returns exactly one row for this address, and it is this one. An importer that reads only the transaction list gets 16 inbound rows and no sale.
The resulting Form 8949 draft is three rows, all with $0.00 in column (e):
| part | box | term | description | proceeds | basis | gain |
|---|---|---|---|---|---|---|
| II | L | long | 0.122908748109231953 ETH | $366.01 | $0.00 | $366.01 |
| I | I | short | 0.00001225 ETH | $0.04 | $0.00 | $0.04 |
| I | I | short | 0.012496 USDT0 | $0.01 | $0.00 | $0.01 |
The two ETH rows sum to 0.122920998109231953 ETH — the wei figure from internal transfer #7, split by holding period across 14 lots. The row totals are each rounded to the cent, so they add to $366.06 while the summary figure computed at full precision is $366.05. We are stating both rather than picking whichever looks tidier.
Why "$0-basis disposals: 0" and "$0.00 basis" are both true
The run reports 0 zero-basis disposals and simultaneously assigns $0.00 basis to every Form 8949 row. That is not a contradiction, and the distinction is worth naming because it is easy to misread in either direction.
The zeroBasisDisposals counter counts disposals that consumed a MISSING_BASIS placeholder — cases where the ledger shows more units sold than it ever saw acquired. Here nothing is missing: all 14 lots exist, in the right quantities, and the balance ties out. The lots simply carry a cost of zero, because every ETH that ever arrived did so as an unattributed_inflow — an inbound transfer with nothing leaving the wallet set in the same transaction, so the chain does not show what was paid for it. The engine books those at $0 rather than at the day's market value, which states the gain at its maximum instead of inventing a purchase.
The two largest are:
| date | amount | value at receipt | transaction |
|---|---|---|---|
| 2023-03-06 | 0.1 ETH | $156.48 | 0x2d29fa…d45bc |
| 2021-09-14 | 0.02 ETH | $65.82 | 0xeb8e95…71015 |
So "0 zero-basis disposals" means the ledger is complete, not that the basis is nonzero. A reader who took the counter as reassurance would have the story backwards.
507 of 653 unpriced token events carry a phishing ticker
Of the 656 ERC-20 events, the engine could price 3, across 3 of the 108 contracts. The other 653 ship as unpriced for review rather than valued. Pricing is per event, not per contract: USDT0 appears in both counts, priced on three events and unpriced on a fourth.
The unpriced pile is not obscure long-tail tokens. 507 of the 653 events come from 11 contracts whose ticker text is itself an instruction to visit a website:
| events | ticker as written on-chain |
|---|---|
| 200 | $ ETH77Go.com - Visit to claim |
| 150 | $ ETH77Go.com - Visit to claim (second contract) |
| 100 | $ USDCFree.com - Visit to claim |
| 50 | $ ETH77Go.com - Visit to claim (third contract) |
| 7 | Visit https://arbinu.fun to clai…, Visit https://univ4.org to earn, Claim $ENS rewards at https://…, Claim $DHT rewards at https://…, ARB - [ t.ly/ARB ] *Claim within… |
These were pushed into the wallet; nothing was paid for them and nothing can be. They are the reason 669 of 671 events land in the review queue. The engine's rule is the point here: a token with no price series is surfaced as unpriced, never guessed. A pipeline that valued unknown ERC-20 inflows at "whatever the pool says" would manufacture income out of unsolicited spam — and on an L2, where sending that spam is cheap, the spam is the majority of the history by event count.
What the tie-out proves here, and what it doesn't
The tie-out passed: reconstructed 0 ETH against 0 ETH on chain at block 416,593,973. We confirmed the on-chain side independently, outside the engine, with a direct eth_getBalance at that block against an Arbitrum archive node: 0x0.
It should be said plainly that a tie-out at zero is a weaker statement than a tie-out at 27,000.998704 ETH. It confirms the engine accounted for every unit the chain says the wallet holds, and the chain says it holds none. It does not confirm that the 671 events between genesis and the cutoff are individually right, and it says nothing at all about the ERC-20 balances, which this check does not tie out on any chain.
Two further limits on this run specifically. Prices came from a single source (DefiLlama); the second price source — Coinbase ETH-USD daily candles — was unreachable, so the usual cross-check did not run, and we say so rather than bury it. And an Arbitrum scan is scoped to Arbitrum: consensus-layer income does not exist here, canonical bridge legs would have their matching leg on Ethereum mainnet, and the same address holds a separate mainnet history that this run does not read.
How to reproduce
npm run check -- 0xab5801a7d398351b8be11c439e05c5b3259aec9b --chain arbitrum --until 2025-12-31
The free web scan caps at 500 events and this address produces 671 by the 2025-12-31 cutoff, so it cannot reproduce this run. The open-source CLI above (default cap 5,000 events) can. /method describes the method; /check runs the free version on your own addresses within its cap.
What this page does not claim
- It does not claim any vendor mis-handled this wallet. No commercial tool was measured here; this is our engine, run on a public address, on a submission set of one.
- It does not claim the holder of this address realized $366.05, or anything about anyone's tax position, filings or liability. We have no visibility into any of that. The figure is what a scan of one wallet in isolation produces, and outbound transfers to addresses outside the submitted set are priced as disposals by construction.
- It does not claim that reading the internal-transaction index is unusual or proprietary. It claims only what we measured: that on this address, on this chain, the transaction list alone shows no disposal and the trace shows one.
- It is not a tax return, and it is not tax advice. None of it substitutes for a qualified professional looking at your actual records.