Every crypto-tax tool we surveyed does the same thing: give it a wallet address, and it fetches the ETH that landed in that wallet. It adds up the deposits, applies the fair-market value at the time of each receipt, and produces a Schedule 1 number. That approach works fine if your staking income arrives cleanly in one wallet. For solo validators, it doesn't — and the gap it leaves is not cosmetic.

The three classes of income a wallet scan misses

Solo and SaaS-managed validators (Allnodes, Kiln, Blockdaemon and their peers) earn ETH through three distinct mechanisms. Wallet-based tools capture one of the three reliably.

Capella sweep withdrawals land in the withdrawal address. A wallet scan catches these. For most validators with 0x01 credentials running since Capella (April 2023), this is the dominant income stream today. So if your tool only does this one thing, it gets most of the post-Capella number approximately right.

MEV-Boost block proposals pay the fee recipient — which may be a different address from the withdrawal address, and which may rotate over time if you've changed your configuration or use a SaaS provider that manages fee recipients on your behalf. A wallet scan of your withdrawal address misses every MEV tip that went to a different address. At current MEV conditions, a validator that proposes one block per month can see MEV tips that are individually larger than a month of attestation rewards. This is not rounding error.

Pre-Capella beacon-chain accrual — the entire period from validator activation through April 18, 2023 — never appeared in any wallet at all. Balances accumulated inside the beacon chain and were only paid out as a lump-sum sweep when Capella enabled withdrawals. A wallet scan that starts at the sweep date sees one large deposit and applies the FMV of that day to the entire amount. That misstates the income: under IRS Rev. Rul. 2023-14's dominion-and-control standard, each epoch's reward was earned — and arguably recognized — when the protocol credited it, not when it was swept years later.

Post-Pectra 0x02 consolidations add a fourth wrinkle. Validators with 0x02 credentials (introduced in Pectra, May 2025) are exempt from automatic sweeps. Their balances grow inside the beacon chain until the operator initiates an EL-triggered withdrawal via EIP-7002. The sweep date and the income date diverge by design. A wallet scan will not even find a receipt for the pre-withdrawal accrual period.

The upshot: the only complete data source for validator income is the validator pubkey, not the withdrawal address. The beacon API exposes reward decomposition by validator index — attestation rewards, sync-committee rewards, block-proposal rewards, and slashing penalties, slot by slot. A correct ingestion pipeline starts there.

What a reconciliation gate is

Reading the beacon API is necessary but not sufficient. APIs have bugs. Indexing services have gaps. Your own node can miss slots during downtime. MEV relays sometimes don't report a delivered payload immediately.

A reconciliation gate is a check that runs after all reward data has been ingested for a period: the derived total (what the beacon API reports you earned across all validators, by event type, summed to wei) must match the on-chain receipt total (what the execution layer actually paid to your withdrawal address and fee recipient addresses, converted from gwei to wei and summed) within a configured tolerance.

If the two sides don't balance within that tolerance, the system blocks report generation. The discrepancy is flagged with the exact epoch, slot, or transaction where the gap first appeared. No report ships until the gap is explained or corrected.

In practice this gate catches:

• Missed epochs during node downtime that were not backfilled
• MEV relay payments attributed to the wrong slot
• Gwei-to-wei rounding in any upstream service
• Fee-recipient address mismatches (the reward went somewhere, just not where the system expected)

The gate is not a report feature — it's a precondition for report generation. We built it as the first thing the report pipeline checks, before any tax computation begins.

Why 100 wei is the right tolerance

One hundred wei is $0.000000000000000036 at $3,600/ETH. No auditor cares about that dollar amount.

What auditors do care about is the discipline that number implies. A tolerance of zero would fire spuriously on any gwei-level rounding in upstream APIs — it would block legitimate reports constantly. A tolerance of 1 ETH would let material errors through silently.

One hundred wei sits in the gap: tight enough to surface any real ingestion problem (even a single missed attestation reward for a single epoch is approximately 14,000–20,000 gwei, i.e., 14,000,000,000–20,000,000,000 wei — four orders of magnitude above the gate), loose enough that gwei↔wei rounding in a well-behaved API never triggers a false positive.

The discipline is what matters. A system that ships tax reports without first confirming the data balances is implicitly saying "this is our best estimate." A system with a reconciliation gate is saying "we verified this against the on-chain record." The distinction is the difference between a number a CPA can defend and a number they have to qualify with "prepared from available data."

Under IRS Notice 2014-21, virtual currency is treated as property, and property transactions require accurate cost basis and income recognition. A tax report that can't show how its numbers trace to on-chain facts is not a tax report — it's a spreadsheet. The reconciliation gate is what turns the spreadsheet into a report.

Worked example: a 23-wei sync-committee gap

(Synthetic example — validator indices, rewards, and FMV figures below are illustrative only and do not correspond to any real validator.)

Suppose you run a validator with index 512300. During epoch 280,500, it participates in a sync committee. The Lighthouse rewards API at /eth/v1/beacon/rewards/sync_committee/{epoch} (see Lighthouse Book citation) returns the following for that validator:

{
  "data": [
    {
      "validator_index": "512300",
      "reward": "105750"
    }
  ]
}

That is 105,750 gwei, or 105,750,000,000,000 wei, for one epoch's sync-committee participation.

The beacon chain processes this reward across 32 slots in the epoch. On the execution layer, the corresponding sweep transaction (for a 0x01 validator) arrives two to four epochs later. The actual ETH receipt in the withdrawal address for that sweep batch, attributed to validator 512300's sync-committee component, sums to 105,749,999,999,977 wei.

The gap is 23 wei. This is not a data error — it is a known gwei-to-wei rounding artifact in how the beacon chain processes fractional reward calculations at the consensus layer before issuing the sweep to the execution layer. The Ethereum consensus spec describes the reward calculation in integer arithmetic with truncation at the gwei boundary; the 23-wei residual is the accumulated truncation across 32 slots.

The reconciliation engine sees this gap, compares it to the configured tolerance (100 wei), finds it within tolerance, marks the reconciliation as clean, and allows report generation to proceed. The reconciliation record stores: the epoch, the validator index, the derived reward (105,750,000,000,000 wei), the on-chain receipt (105,749,999,999,977 wei), the gap (23 wei), the tolerance applied (100 wei), and a status of within_tolerance.

If instead the gap had been 150 wei — above the tolerance — the system would flag the epoch and block the report. A human or automated correction pass would investigate: did the sweep actually arrive? Was there a fee-recipient mismatch on a MEV tip? Is the node missing a slot? The report cannot proceed until that question is answered.

The audit trail entry for a clean reconciliation looks like this:

• Source: Lighthouse /eth/v1/beacon/rewards/sync_committee/280500
• On-chain receipt: Execution layer tx 0xabc... (synthetic), block 21,500,000
• Derived reward: 105,750,000,000,000 wei
• Actual receipt: 105,749,999,999,977 wei
• Gap: 23 wei
• Tolerance: 100 wei
• Status: within_tolerance
• FMV at recognition: $3,412.50/ETH (synthetic, illustrative)
• Income recognized: $0.361 (synthetic, illustrative)

That entry, for every event in the tax year, is what the report cites.

What this means for your filing

The nine reward types a solo validator earns — attestation source/target/head rewards, sync-committee rewards, block-proposal base fees, MEV tips (per relay), slashing penalties, and exit-related events — each carry different income timing characteristics and potentially different cost basis treatment depending on your recognition policy.

Under Rev. Rul. 2023-14, staking rewards are ordinary income at FMV at the moment of dominion and control. For 0x01 validators, that is the sweep timestamp. For 0x02 validators, the question is open — the ruling predates Pectra — and TrueStake allows the user to configure recognition policy per account (at protocol credit vs. at withdrawal trigger) with the choice recorded in the audit log.

What the reconciliation gate produces is a per-event income record where every number traces to a specific on-chain transaction, a specific beacon API response, and a specific reconciliation run — all stored as raw payloads, not processed summaries. If the IRS examines your return and asks how you got from "I ran Ethereum validators in 2025" to a specific Schedule 1 number, the answer is: here is every receipt, here is every beacon API response, here is the reconciliation that proves they match, and here is the FMV at each recognition event.

That is what audit-defensible means. Not "I ran it through a software tool." Not "my exchange reported it." A chain of custody from on-chain fact to Schedule 1 line item, with wei-level precision and citations at every step.

This is the pipeline we built first — because the only way to know a reconciliation gate actually works is to run it against real validator data, under the same conditions our users will face. The gate is not a marketing claim. It's an engineering requirement: a system that ships tax reports without first confirming the data balances is producing estimates, not evidence.

This is a methodology piece, not a vendor comparison

We're not recommending any crypto-tax tool here — including this one. We're describing a standard: what does it mean for a staking-tax report to be audit-defensible? It means starting from validator pubkeys, decomposing income into its nine components, reconciling derived rewards against on-chain receipts within a tight tolerance, and storing raw payloads so the chain of custody is reproducible.

If you evaluate any tool for solo-validator tax reporting — including TrueStake — those are the questions to ask. Does it read validator pubkeys or just wallet addresses? Does it catch pre-Capella accrual? Does it account for fee-recipient MEV separately from withdrawal-address income? Does it reconcile, or does it estimate?

The right answer to each of those questions is not "yes, probably." It's "yes, here is the reconciliation record."