Anyone who reconciles DeFi portfolios for tax purposes knows the pattern: a tool pulls the wallet history, applies FIFO, spits out a number. The number looks plausible. It gets filed.
The problem is rarely the calculation logic. FIFO is FIFO. The problem sits one layer down — in whether the engine actually saw every relevant transaction before it started calculating. And that's exactly where systems fail silently: no error, no crash, just an incomplete number wearing the same confident formatting as a complete one.
We ran our own engine against real multi-chain wallets for months and found (and fixed) five structural failure classes. Below are five concrete failure modes, with the technical mechanisms behind them — not because they're quirks of our implementation, but because they can affect any engine that relies on the same underlying data sources and assumptions.
1. Provider rate tiers that refuse entire chains — with HTTP 200
Explorer APIs (Etherscan V2 and compatible endpoints on other chains) respond to low-tier requests on certain chains not with an error, but with a success-shaped status message: status: "0", message "Free API access is not supported for this chain". No HTTP error code, no exception — a formally valid response with no content.
An engine that doesn't check the status field inside the body logs this as "no transactions on this chain." On a multi-chain portfolio, that means an entire chain silently disappears from the tax report. (Confirmed live, including on Base.)
A related second case: the same APIs cap result sets (typically 10,000 rows per query). Without active pagination via startblock, you get the first 10,000 entries and treat them as the full history.
2. Internal transfers that simply aren't available on most chains
Native internal transfers (contract-to-contract, triggered by a smart contract call rather than an external transaction) aren't an edge case for DeFi users — bridges, liquidations, and wrapper repayments run through them.
On Alchemy, the internal category in alchemy_getAssetTransfers is only queryable on a subset of chains. On the rest, the request doesn't partially degrade — it fails completely with a -32602 RPC error, taking every other requested category down with it. An engine has to know, per chain, whether it's even allowed to ask for that category.
The honest consequence is uncomfortable: on chains where the provider doesn't support the category, internal transfers via this path are not collectible. That's not a bug you code away — it's a data gap you either close with a second source or declare openly in the report. What you can't do is silently log it as "no internal transfers found."
3. WETH unwraps that emit no transfer event
WETH9.withdraw(uint256) burns the WETH balance and sends native ETH 1:1 — but only emits a Withdrawal log, never a standard ERC-20 Transfer event.
Every common indexer (Etherscan's tokentx, Alchemy's erc20 category) is built on transfer logs. The WETH leg of the operation simply doesn't exist for them. What lands in the journal is only the native ETH side flowing back.
The result is inventory drift in both directions: ETH appears from nowhere, while the corresponding WETH position never gets drawn down. Without an active reconciliation between computed and actual on-chain balance, this doesn't surface — the report stays internally consistent and is still wrong.
4. Phantom transfers from failed transactions
Explorer APIs' transaction lists include transactions that reverted on-chain — with a non-zero value field. The transaction was sent, burned gas, but the state change never happened.
Skip checking isError / txreceipt_status separately, and you book an asset movement that never occurred. Depending on where this phantom entry lands in the FIFO stack, it shifts acquisition order, holding periods, and therefore tax liability — in either direction.
(The gas fee actually spent is real, by the way, and stays correctly recorded — only the transfer itself isn't.)
5. The same method selector meaning a different asset on every chain
DeFi protocols get recognized by method selectors (the first 4 bytes of calldata). Aave's WrappedTokenGateway uses the exact same depositETH selector for native-gas-token deposits on every chain — including chains where the native token isn't ETH at all.
On Sonic, that identical selector fires for a native S deposit. An engine that infers the asset from the selector's name books WETH instead of WS: wrong asset, wrong price, wrong cost basis — while correctly recognizing the transaction type.
The fix requires deriving the actual token that moved from the transaction's balance changes, instead of guessing it from the selector name.
What these five have in common
None of them throws an error. Each produces a number that looks like a complete calculation — cleanly formatted, decimal places included, ready to file. The difference between a correct and a silently incomplete tax calculation isn't visible from outside without active cross-checking.
That's why we built our engine to report its own incompleteness instead of hiding it: an automatic tie-out between on-chain balance and computed inventory after every run, a completeness statement listing which chains were covered with which data source and coverage level, and a hard rule that an unresolvable transaction gets flagged, never silently dropped.
The question worth asking any DeFi tax tool isn't "does it calculate FIFO correctly?" — most do. It's:
"What does it do when it can't fully attribute a transaction — does it show you, or does it hide it?"
This describes software behavior, not tax advice.
Top comments (0)