When the IRS examines digital-asset activity, the requests don't start with "what was your total?" They start with identifiers: the addresses linked to you, transaction-level history for each receipt, and documentation of the valuation source behind every figure — that's the examiner playbook in the agency's own manual (IRM 4.26.16).

For a staker, there's one identifier that makes all of those answerable, and most tax tools never touch it: the validator pubkey.

What a pubkey identifies

Every Ethereum validator is a public key with 32 ETH behind it. The pubkey is the validator's permanent identity: which duties it performed, which blocks it proposed, which sweeps it generated, when it activated and exited. Own six validators and you own six distinct income-generating entities that happen to pay into your addresses.

A wallet-level view — an address's incoming transfers, the standard exchange or explorer export — sees the payments but not the payer. It can't tell you which validator earned what, which duty a payment represents, or whether a validator's expected income and settled income actually agree. It records arrivals; it can't attribute them.

Why attribution is the audit question

Staking income under Rev. Rul. 2023-14 is recognized when you gain dominion and control over it — which makes each settlement event, per validator, the atomic fact of your tax record. The §6001 standard asks for records sufficient to establish your income; establishing means being able to show, for any figure, the event chain that produced it:

this line ← this sweep ← this validator ← these duties, this period

Break that chain at "this validator" and everything upstream becomes unattributable. Fine when nobody asks. Expensive when someone does — a self-custodied staker's income is self-reported, with no broker's 1099-DA to share the substantiation burden.

What a pubkey-anchored record looks like

Anchoring on pubkeys is what lets a record do things a wallet view can't:

• Per-validator attribution. Every line names its validator, so a multi-validator record decomposes cleanly instead of arriving as one undifferentiated stream.
• Expectation against settlement. Knowing the validator's duties lets the record derive what should have arrived and reconcile it against what did — the check that catches missing income before an examiner or a 1099 mismatch does.
• Complete lifecycle. Activations, exits, and credential changes are events on the pubkey, so the record knows why income started, stopped, or changed shape mid-year.

This is exactly how TrueStake is built: pubkey-anchored receipts, reconciled against settlement, each line carrying its chain reference and price provenance into the Tax Report.

Handle with care

One caution runs the other direction: a validator pubkey, linked to an identity, maps a person's staking footprint. TrueStake treats pubkeys and withdrawal addresses as sensitive personal data — collected because the record requires them, disclosed in the export because your substantiation requires them, and otherwise nobody's business. A tool that anchors on pubkeys owes its users that discipline.

The takeaway

Wallet-level records answer "what arrived?" Pubkey-anchored records answer "what did each validator earn, and how do we know?" — and the second question is the one examiners, CPAs, and future-you actually ask. If your staking record can't name your validators, it isn't a staking record; it's a deposit log.