This article is for general educational purposes only and does not constitute legal, tax, or financial advice. Tax treatment of staking rewards involves unsettled questions and depends on individual facts and circumstances. Consult a qualified tax professional before taking any position on your return.

Every time your Ethereum validator earns a reward — an attestation, a sync-committee slot, a block proposal, a Capella sweep — that reward has a dollar value. Not an approximate one. Not a year-end total. A specific dollar amount, at a specific moment, attached to a specific on-chain receipt.

Getting that dollar value right is the second half of the staking-income problem. The first half is knowing what you earned (which validator, which event type, how many wei). The second half is knowing what it was worth at the moment you earned it. Both halves are required for an audit-defensible return. This article is about the second half.

The rule: FMV at the date and time of dominion and control

Under US federal income tax law, virtual currency — including ETH — is treated as property. IRS Notice 2014-21 (2014-16 I.R.B. 938) established this in 2014, and it has not changed. When you receive property as income, the taxable amount is the fair market value of that property at the time of receipt.

IRS Revenue Ruling 2023-14 (2023-33 I.R.B. 484) applied this framework specifically to proof-of-stake staking rewards. The ruling establishes that staking rewards are includible in gross income under IRC § 61(a) in the taxable year in which the taxpayer gains dominion and control over those rewards. And critically: FMV is determined as of the date and time that dominion-and-control attaches — not the end of the tax year, not the date of a future sale, not a monthly or annual average.

The phrase "dominion and control" is the operative test. For a 0x01-credential Ethereum validator, the clearest point at which dominion-and-control attaches is when the consensus-layer sweep credits the execution-layer withdrawal address — the moment ETH becomes spendable and fully under the validator operator's control without restriction, consistent with Treas. Reg. § 1.451-2(a).

The practical implication: each on-chain receipt is a separate income recognition event, with its own dollar value, determined by the ETH price at the moment that receipt lands. A validator earning rewards across hundreds of sweeps in a tax year has hundreds of discrete FMV determinations, not one annual number.

What "reasonable manner consistently applied" means

Notice 2014-21 does not tell you exactly which price to use, on which exchange, at which minute of the day. What it says — in Q&A-5 and Q&A-6 — is that taxpayers must determine FMV using a "reasonable manner that is consistently applied." The exchange rate must be established by market supply and demand (not an arbitrary or illiquid source), and once you pick a method, you must apply it the same way across all events.

This standard gives taxpayers meaningful latitude in how they operationalize FMV. Several approaches are in common use:

Spot price at the block timestamp. The ETH/USD price at the exact time the block containing the reward was produced, sourced from a major exchange API. This is the highest-resolution option and most literally implements "at the date and time of dominion and control." It requires a price-history API with minute-grain or second-grain data.

Daily close on the recognition date. The UTC daily closing price on the date the recognition event occurred, sourced from one or more major exchanges. This is a common CPA default because it is straightforward to audit — there is one price per date rather than thousands of per-minute prices, and the price is published and reproducible by any third party. The trade-off is a small timing mismatch between the block timestamp and the daily close.

Daily average. The volume-weighted average price (VWAP) or simple daily average for the recognition date. Some practitioners prefer this on the theory that it smooths intraday volatility and is less susceptible to manipulation than a single-point spot price.

All three of these approaches are plausibly consistent with the "reasonable manner" standard of Notice 2014-21, provided they are sourced from a major exchange with market-supply-and-demand-established rates. None is categorically required or categorically forbidden by current IRS guidance. Which method is optimal for your return is a question for your tax advisor, not a decision you should make based on convenience alone. What the rules require is that you pick a method, apply it consistently to all events in the tax year, and document it so an examiner can verify it.

If you are uncertain which approach your advisor would endorse, the safer path is to document your methodology explicitly and raise the question directly. This is a question tracked in TrueStake's counsel queue precisely because it involves a facts-and-circumstances judgment that merits professional review for a return of material size.

Why the timestamp on each receipt matters

Consider two staking rewards received in the same week: one on a day ETH trades at $2,800, one on a day it trades at $3,400. If you use a single weekly average for both, you report approximately the same income for each. If you use the price on each recognition date, the second receipt is worth roughly 21% more than the first.

At small scale — a few ETH per year — the difference is modest. At scale — a fleet of validators earning dozens of sweep receipts per month — the compounding of per-event vs. annual FMV can move the reported income number by thousands of dollars. More importantly, it can move the cost basis of each ETH lot by the same magnitude.

Cost basis matters because when you eventually sell or exchange the ETH you received as staking income, the capital-gains calculation starts from the FMV at the time you received it. Under the FMV-at-receipt rule, each staking-reward receipt creates a new tax lot with a basis equal to the FMV you recognized as income. If you use an annual average rather than a per-receipt FMV, you will likely report incorrect basis on those lots when you sell — a second tax error downstream of the first.

The IRS's dominion-and-control standard for income recognition implies a per-event basis assignment. Every receipt gets its own FMV, its own income amount, and its own cost-basis entry. Aggregating to annual averages is not a simplification — it is a deviation from the method the ruling contemplates.

The validator-pubkey angle: why per-receipt pricing requires per-receipt data

There is an infrastructure reason why most crypto-tax tools don't implement per-receipt FMV correctly: they don't have per-receipt data. A tool that ingests from your withdrawal-address transaction history sees lump-sum sweep transactions — one ETH amount landing in your wallet, one block timestamp. It can apply an FMV to each sweep, which is reasonable for post-Capella receipts.

What it misses:

Pre-Capella accrual (before April 18, 2023). Validator rewards accumulated inside the beacon chain from each validator's activation date through the Capella upgrade. They were never paid to any wallet during that period. When Capella enabled withdrawals, the accumulated balance swept to the withdrawal address as one transaction. A wallet-scan tool sees one deposit in 2023 or later and applies the FMV of that day to the entire pre-Capella balance — including rewards that were arguably recognized epoch-by-epoch during 2020, 2021, 2022, and early 2023, at ETH prices that were completely different.

Under the dominion-and-control analysis in Rev. Rul. 2023-14, the per-epoch recognition argument has real force: if each epoch's reward credit was available to the staker without substantial restriction at the consensus layer — a question that reasonable practitioners answer differently — then the FMV at each epoch is the correct valuation point, not the sweep date. A wallet-scan tool cannot make this computation because it never sees the per-epoch beacon data.

MEV-Boost block proposals. Block-proposal rewards via MEV-Boost are paid to the fee recipient address, which may be different from the withdrawal address and which may have changed over time. A wallet scan of your withdrawal address misses every MEV tip that landed at a different address. MEV tips are individually significant — one proposal per month can pay more than a month of attestation rewards at current conditions. Each proposal also has its own block timestamp and its own FMV.

Per-validator attribution. If you run multiple validators, your sweep transactions may batch rewards from many validators into a single transaction. The total sweep amount has one on-chain FMV, but the income is allocated across multiple validators by the beacon API. Validator-pubkey ingestion is required to decompose the income correctly for reporting purposes.

The only data source that resolves all of this is the validator pubkey + beacon API. The Lighthouse rewards API, for example, exposes per-validator reward decomposition by epoch: attestation source/target/head, sync-committee, block proposals. Each event carries a precise timestamp. The FMV calculation can be applied to each event at its actual recognition time.

This is why audit-defensible FMV determination is not separable from validator-pubkey-based ingestion. The two go together: without the per-receipt data, you cannot make per-receipt FMV determinations; without per-receipt FMV, you cannot apply the dominion-and-control rule correctly.

Source selection and corroboration

Notice 2014-21 Q&A-5 requires that the exchange rate be "established by market supply and demand." This rules out thin markets, peer-to-peer trades, and illiquid venues, but leaves the choice of specific exchange to the taxpayer's judgment. In practice, CPAs and digital-asset tax software use major centralized exchanges — Coinbase, Kraken, Gemini — and/or aggregation services like CoinGecko.

A defensible approach uses a primary source (a major exchange with continuous ETH/USD trading and published historical data) and a corroborating source (a second exchange or a well-established aggregator). If the two sources agree within a reasonable tolerance on a given date, the price is reliable. If they diverge materially — which can happen on unusual market days — the discrepancy is itself a finding worth noting in your records before filing.

The goal is not to find the "right" exchange but to demonstrate that the price you used was established by normal market forces on the recognition date, and that you applied the same methodology across all events. Those two facts — market-established rate + consistent method — are the substance of Notice 2014-21's "reasonable manner" standard.

What audit defense actually looks like

An IRS examination that touches staking income will typically ask: how did you get from "I ran Ethereum validators in 2025" to the Schedule 1 number on your return?

An answer that relies on crypto-tax software totals, without being able to drill to the underlying data, is not a complete answer. An answer that traces every receipt is.

The chain of custody that makes a staking-income number defensible:

1. The beacon API response for each reward event — raw payload, stored at ingestion time.
2. The on-chain receipt — execution-layer transaction or sweep, with block number, timestamp, and wei amount.
3. A reconciliation confirming that the derived total (from the beacon API) matches the on-chain receipt total within tolerance.
4. The FMV determination — the ETH/USD price on the recognition date, from a named source, applied consistently, with the source API response stored.
5. The income amount — wei amount × FMV → USD income, per event.

Steps 1–3 establish what you earned. Steps 4–5 establish what it was worth. Both legs are required. A number that can point to step 5 but not steps 1–3 is a valuation without an asset. A number that can point to steps 1–3 but not 4–5 is a quantity without a dollar figure.

The per-receipt FMV methodology is not bureaucratic overhead. It is the mechanism that makes step 5 possible in the first place. Annual averages do not have a step 5 — they have an approximation. Whether an approximation is defensible depends on the size of the discrepancy and the examiner's tolerance for it. Correct per-receipt FMV does not have that exposure.

The open question: which method satisfies "reasonable manner"?

To be direct about the unsettled part: the IRS has not specified whether spot-at-block-timestamp, daily-close, or daily-average is the preferred method for staking rewards. All three are defensible positions under the current "reasonable manner consistently applied" standard. All three have been used on filed returns reviewed by CPAs.

The question of which method is optimal — or whether any specific method is required — is open pending further IRS guidance or Treasury rulemaking. TrueStake implements daily close as its default FMV method because it is a well-established CPA practice, it is auditable from publicly available price histories, and it satisfies the reasonable-manner standard as understood today. Whether that default is the right choice for your return, at your filing scale, with your advisor's guidance, is a judgment that belongs in that conversation — not here.

What is not open: the timing anchor is the date and time of each dominion-and-control event, per Rev. Rul. 2023-14. Whatever price method you use, it must be anchored to the recognition timestamp of each receipt, not to a period average that ignores those timestamps. That part of the rule is settled.

Practical takeaways

• One FMV per receipt, not one per year. Rev. Rul. 2023-14's dominion-and-control standard implies per-event income recognition; per-event recognition implies per-event FMV.
• The timestamp on each receipt is not metadata. It is the operative date for the FMV determination. Store it. Cite it.
• Cost basis follows FMV. Each staking-reward receipt creates a tax lot with basis equal to the FMV recognized as income. Per-receipt FMV → correct per-lot basis → correct capital gains when you sell.
• Pick a method and document it. Spot, daily close, and daily average are all plausibly consistent with Notice 2014-21. Pick one, apply it to every event in the tax year, and record which source you used.
• Validator-pubkey ingestion is required. Wallet-address scanning cannot produce per-receipt FMV for pre-Capella accrual, MEV tips to a separate fee-recipient, or multi-validator batch sweeps. The data has to come from the beacon API keyed on validator pubkey.
• Two-source corroboration adds defensibility. Using a primary exchange and a corroborating aggregator, and documenting any divergences, demonstrates the price was market-established — the core of Notice 2014-21 Q&A-5.

Sources: IRS Notice 2014-21, 2014-16 I.R.B. 938 (Apr. 14, 2014); IRS Rev. Rul. 2023-14, 2023-33 I.R.B. 484 (Aug. 14, 2023); IRS FAQs on Digital Asset Transactions (current revision, irs.gov); IRC § 61(a); Treas. Reg. § 1.451-2(a). FMV methodology is governed by a "reasonable manner consistently applied" standard under Notice 2014-21; the specific method (spot at block timestamp, daily close, or daily average) involves a judgment question that has not been resolved by explicit IRS guidance — consult a qualified tax professional before adopting any specific methodology on a filed return. This article is educational content only and does not constitute legal, tax, or financial advice.