Ethereum Staking Rewards Accounting: Recognition and Measurement

Native Ethereum staking rewards are not one recurring payment stream. The streams a validator earns differ in ledger, evidence, timing, counterparty structure, and potentially accounting presentation, so Ethereum staking rewards accounting cannot begin with a single yield number and has to separate the components before it measures any of them.

An entity running its own validator can earn:

• consensus-layer rewards that change the validator balance without a transaction;
• proposal-related consensus rewards;
• sync-committee rewards;
• execution-layer priority fees;
• and builder or MEV-related payments that can arrive through a different execution-layer path.

The core problem in Ethereum staking rewards accounting is therefore not "what is the staking yield?" It is:

When does a recognisable event arise, how should high-frequency protocol changes be aggregated, how is each recognised quantity measured, and is the resulting income revenue or something else?

This article covers Ethereum staking rewards accounting for native staking by the holder's own validator. Pooled staking, liquid staking tokens, restaking, and staking-provider claims are different arrangements.

Reward frequency is high, but "225 rewards per day" is too simple

Ethereum currently uses 12-second slots and 32-slot epochs:

86,400 seconds / (32 × 12) = 225 epochs per 24-hour day

That creates 225 epoch boundaries per day, but not 225 identical cash-like payments. Reward components are calculated and applied through different parts of the protocol. The accounting population is high-frequency; the events are not all economically or evidentially identical.

Ethereum staking rewards accounting starts by separating the reward streams

A validator earns in two economically and evidentially different ways. This article covers native staking only, meaning the holder runs the validator and holds the withdrawal credentials.

Consensus-layer rewards are paid by the protocol for voting on blocks, proposing blocks, and serving on a sync committee, a rotating group of validators that publishes a compact summary of the chain for lightweight clients. They are credited directly to the validator's balance on the consensus layer. There is no transaction, no hash, no gas, no counterparty, and nothing an execution-layer block explorer will ever show.

ethereum.org summarises the timing as "All rewards and penalties are applied once per epoch", and for the largest component, attestation rewards - an attestation being the vote each validator casts once per epoch, on the block proposed in its assigned slot - that is exactly right: the specification applies them in the epoch transition, roughly 225 times a day per validator. Two components are credited earlier, during block processing rather than at the epoch boundary: the proposer's reward for including other validators' attestations, and sync-committee rewards. The distinction rarely changes a number, but it changes what an entity can prove about when a reward arose, which matters when a reporting date falls mid-epoch.

Execution-layer rewards are the priority fees inside the block the validator proposes, and any additional payment from the sale of that block's construction to a specialist. They arrive at an execution-layer address called the fee recipient, and they arrive in one of two shapes.

If the validator builds its own block, the priority fees are credited to the fee-recipient address directly, in the block, with no transaction. If the validator uses the widely-used MEV-Boost software to buy a ready-made block from a builder, the mechanics change. MEV stands for maximal extractable value: the profit available from choosing what goes into a block and in what order. Builders compete to capture it and pass part of it to the validator for the right to have their block proposed. Flashbots' documentation puts it in one sentence: "To process MEV payment, builders set their own address as the payload's coinbase address and append a transaction to the block proposers' feeRecipient address at the end of their proposed block." The coinbase there is the block's own fee-recipient field, a name inherited from proof-of-work mining and nothing to do with Coinbase Exchange, which appears elsewhere in this series as a price source. In that case the block's own fee-recipient field is normally the builder's address, and the validator's income arrives as an ordinary incoming ETH transfer from a party the validator has never dealt with. Not always, though: some builders instead set the proposer's fee-recipient address as the coinbase, so the priority fees reach the proposer directly, with no transaction and no hash, exactly the way a locally-built block pays. No published source says which of the two routes predominates, or in what proportion, so a reconciliation routine has to expect both.

A verified example, on the first of those two routes, makes the two-ledger split concrete. At slot 15,067,725 on 25 August 2026, validator index 2,280,163 proposed execution-layer block 25,830,206. The payload's fee_recipient was 0x4838b106fce9647bdf1e7877bf73ce8b0bad5f97, the builder. The last transaction in that block, hash 0xaa1e5431ba33af8c6ee1d83fcdf22c349796c35470ce7695d58bffc9d09323fe, sent 0.012851867871411458 ETH from that builder to 0xfeeeeee44046c3f61a8cc081e0918ef0de0a7ffc, the proposer's configured fee recipient. Separately, the consensus layer recorded a block reward for the same slot of 52,273,868 gwei (0.052273868 ETH), credited to the validator's balance with no transaction at all. That last figure was captured when the block was recent. An ordinary node no longer serves it, which is the retention problem Why the Ethereum Blockchain Is Not an Accounting Ledger returns to. And the validator's withdrawal address is a third address again, 0xb9d7934878b5fb9610b3fe8a5e441e8fad7e293f.

One economic event. Two ledgers. Three addresses. Two amounts, four times apart, arriving by two completely different mechanisms, only one of which produces a transaction anyone can look up.

Recognition timing

Consensus-layer rewards can alter validator state before anything is withdrawn to an execution-layer address. That immediately rules out one common shortcut in Ethereum staking rewards accounting: wallet receipt is not necessarily the reward event.

Candidate recognition points that appear in analysis or practice include:

• when the protocol reward is applied;
• when a validation event is confirmed;
• when an aggregation period ends;
• when the reward becomes withdrawable;
• when ETH reaches an execution-layer address; or
• a revenue-model timing derived from a contract or analogy.

No IFRS or US GAAP pronouncement reviewed through 31 August 2026 selects one of those dates for native Ethereum staking.

That does not mean any date is acceptable. A policy should be anchored in the entity's conclusion about what economic event creates the asset increase and what reporting model it applies. The choice should be made before the outcome is known and applied consistently.

Under an accrual policy, withdrawal is not a second recognition event

If rewards are recognised while they accrue in validator state, a later automatic sweep, requested partial withdrawal, or full validator withdrawal is a movement of already recognised ETH.

Booking the execution-layer receipt as new staking income would count the same reward twice.

Aggregation is unavoidable for many accounting systems

A validator can have a reward population measured at epoch frequency. Creating one book lot for every small protocol increment can generate roughly 80,000 recognition intervals in a year for one validator.

An entity therefore needs an aggregation policy.

Possible controlled conventions include:

• daily;
• weekly;
• monthly;
• duty-based groupings; or
• another interval supported by materiality and faithful representation.

The policy should specify:

1. which reward components are aggregated;
2. the exact start and end of each interval;
3. whether penalties are netted or recorded separately;
4. the quantity source;
5. the measurement timestamp;
6. the market-data source;
7. the lot created by the aggregation; and
8. how period-end partial intervals are handled.

Aggregation is an accounting convention. It must never be written as though Ethereum itself pays monthly or daily.

Measurement belongs after recognition

Recognition answers what quantity is being booked and when.

Valuation answers what price is used at that measurement point.

Do not collapse those questions.

A defensible process for a monthly consensus-reward policy could be:

1. capture validator balance and component-level reward data throughout the month;
2. reconcile gross rewards and penalties to the net validator movement;
3. determine the recognised reward quantity under the policy;
4. apply the documented principal-market price at the selected measurement timestamp;
5. create the accounting lot;
6. retain both protocol and market-data evidence.

The price-source policy is owned by Ethereum Valuation for Accounting.

Revenue, other revenue, or other income?

Protocol labels do not answer financial-statement presentation.

"Reward" is an Ethereum word. "Revenue" is an accounting conclusion.

The key questions include:

• Is validating part of the entity's ordinary activities?
• Is there an identifiable customer?
• Are protocol-created rights legally enforceable?
• Is ASC 606 or IFRS 15 applied directly, by analogy, or not at all?
• Is the entity acting as principal or agent?
• Are validator-provider fees presented gross or net?

These questions can produce different answers for:

• an ETH treasury company running its own validators;
• an exchange staking customer assets;
• a delegated staking arrangement; and
• an investment product that stakes through an operator.

The divergence in published US practice is therefore evidence of judgement, not permission to choose a preferred presentation without analysing the facts.

Principal versus agent

Execution-layer and delegated-validator arrangements make principal-agent analysis particularly fact-sensitive.

An entity that operates the validator infrastructure and controls the service may have different gross-versus-net economics from a delegator that pays a validator operator.

The protocol does not decide the accounting role. Contracts, operating responsibilities, control of service delivery, and exposure to the economic effects matter.

Accounting lots created by rewards

Every recognised reward quantity becomes part of the entity's ETH position.

The blockchain does not give that quantity a financial-reporting basis. The recognition entry does.

If a monthly policy recognises 0.07 ETH at $3,000 per ETH, the new financial-reporting lot is 0.07 ETH with a $210 initial amount under that policy. The tax lot may be created at a different time or under different authority. Do not merge the two.

A later validator withdrawal also does not tell the accountant which reward lot moved. The entity's lot policy does.

Reward data must be retained before it disappears

A current validator balance is a net state. It can reflect:

• rewards;
• penalties;
• withdrawals;
• slashing;
• other validator changes.

The final balance alone may not reconstruct each historical component.

Some node interfaces do not retain every detailed historical reward response indefinitely. That creates an accounting evidence problem, not merely an infrastructure preference. The entity should use one or more of:

• contemporaneous capture;
• controlled archive infrastructure;
• a validated third-party staking-data provider; or
• another reproducible source with tested retention.

The control design is developed in Ethereum Accounting Records, Controls, and Reconciliation.

Tax guidance must keep its scope qualifiers

Financial reporting and tax recognition can diverge sharply.

The most important example is the United States. Revenue Ruling 2023-14 expressly frames its issue and holding around a cash-method taxpayer. It requires fair market value inclusion when that cash-method taxpayer gains dominion and control over validation rewards. That qualifier cannot be deleted when summarising the ruling.

The ruling also expressly says its facts do not address gas or transaction fees other than the validation rewards described. It therefore does not settle priority fees or MEV simply because they are economics earned by a validator.

Canada's current public guidance has another scope boundary. CRA states a timing rule for staking rewards credited on a centralized crypto-asset exchange platform and describes proof-of-stake validator activity, but the reviewed public guidance does not provide an equally explicit timing rule for a holder operating its own non-custodial validator.

The UK likewise needs its own taxpayer-type and transaction-specific analysis.

Use the jurisdictional articles rather than importing one country's rule into another:

• Ethereum Tax in Canada
• Ethereum Tax in the United States
• Ethereum Tax in the European Union

IFRS: standards provide a route, not a staking rule

There is no IFRS pronouncement on staking rewards, on when a holder running its own validator recognises them, or on control of ETH that has been staked natively. That is a verified negative: the 2019 agenda decision does not mention staking, the related project is closed, and IFRIC Updates from March 2024 through June 2026 contain no crypto or staking item. The nearest live event is not a project. The IASB Update for June 2026 records that "The IASB held an education meeting with the Financial Accounting Standards Board (FASB) on 5 June 2026", that the two boards "discussed: … cryptoassets; and emerging issues", and that "The boards were not asked to make any decisions." Both boards discussed cryptoassets twelve weeks before this article's review date, and nothing was decided.

What the standards supply is a route, not an answer:

• Is there a customer? KPMG's June 2026 IFRS Q&A puts the difficulty precisely. It says it is "unclear whether these arrangements meet the contract existence criteria in IFRS 15", and in particular whether "there is an identifiable counterparty (i.e. a customer)" and whether "the rights and obligations created by the protocols are considered legally enforceable." For an entity running its own validator and earning consensus rewards from the protocol, the counterparty is a network, not a person. For execution-layer income the picture is different again: a priority fee is paid by an identifiable transaction sender, and a builder payment arrives under a real, if automated, commercial arrangement.
• If IFRS 15 does not apply, the same source says the entity "develops an accounting policy, considering the requirements in IAS 8 … In doing so, it considers whether the requirements in IFRS 15 are relevant."
• Is it revenue? "Staking rewards and transaction fees are generally considered to meet the definition of revenue when staking activities are part of a company's ordinary activities." For a company whose ordinary activity is something else, other income may be the better characterisation. This is interpretation, not requirement.
• When? Nobody has answered this. The reward accrues every epoch. The entity must choose a recognition and aggregation convention and defend it.

ETH the holder has staked natively is not derecognised. No pronouncement says so, but the general derecognition requirements get most of the way there without help. IAS 38 paragraph 112 requires an intangible asset to be derecognised "(a) on disposal; or (b) when no future economic benefits are expected from its use or disposal", and paragraph 114 fixes the date: "The date of disposal of an intangible asset is the date that the recipient obtains control of that asset in accordance with the requirements for determining when a performance obligation is satisfied in IFRS 15." Natively staked ETH has no recipient, so no disposal date arises - this article's application of paragraph 114, not a conclusion the standard draws about staking. KPMG's analysis of delegated staking works from the same control framework: "A delegator only derecognises its staked assets if it loses control of those assets under the staking arrangement. The guidance on control in IFRS 15 is typically used as the basis for this assessment. Generally, the validator does not obtain the right or ability to direct the use of these cryptoassets, so the delegator retains control", and it adds "Similar considerations also apply to staked assets of the validator." It also qualifies the analysis: "However, rights and obligations can vary between arrangements. Companies need to assess these rights and obligations thoroughly before reaching a conclusion." For an entity running its own validator and holding its own withdrawal credentials the conclusion is stronger still: nobody else can direct the ETH at all. The correct response is not derecognition. It is restriction disclosure under IAS 38 paragraph 122(d): "the existence and carrying amounts of intangible assets whose title is restricted".

US GAAP: no explicit staking model and no single market practice

This is the largest open question in ETH accounting, and it is worth being blunt about how open it is.

KPMG's April 2026 hot topic states the position: "There is currently no explicit US GAAP that directly addresses the accounting for crypto intangible asset staking." The AICPA's practice aid, non-authoritative in any case, has no staking question and answer at all in the edition checked for this article, the one "as of Sept. 30, 2025", which is the most recent edition that downloads without a member login. Its accounting chapters cover proof-of-work mining, and staking appears only in the auditing chapters as something to confirm. The landing page carries a "2026 Update" heading over that same download, so a newer text may sit behind that login; it has not been inspected here, and the negative is stated as at the September 2025 text. The FASB has no project on staking, staking rewards or crypto revenue recognition.

What the practice aid does have is the nearest available analogy, and it splits the question the way the protocol does. Mining Q&A 27: "Transaction fees earned by a miner should be recognized as revenue from customers in accordance with FASB ASC 606 … The requester meets the definition of a customer", while "Block rewards earned by a miner are generally recognized as revenue, but an evaluation is required …", and then, a few lines later, "a miner could apply by analogy the revenue recognition guidance in FASB ASC 606". What the practice aid puts between those two block-reward sentences is a condition, and it is the operative one: it works through whether the block rewards are revenue from a contract with a customer, and the analogy is available only where the miner concludes they are not. That is the execution-layer and consensus-layer split of Ethereum for Accountants in accounting language; carrying it across from proof of work to proof of stake is this article's own reading, not the AICPA's. One consequence travels with the by-analogy route: "If analogizing to FASB ASC 606, the revenue from block rewards would be presented separately from FASB ASC 606 revenues from contracts with customers on the statement of comprehensive income or separately disclosed in the notes to the financial statements", which is the requirement in ASC 606-10-50-4(a).

What fills the gap is ASC 606, and the threshold judgement is the one IFRS poses in the same place: is there a customer? KPMG gives a sentence that looks like an answer - "We believe the 'customer' for the validation services is the blockchain network" - but gives it inside the principal-agent analysis; when it turns to revenue classification it lists the network as one of several possible customers and records that entities often conclude a decentralised network "cannot, as a non-entity, be a customer and, therefore, the staking rewards are most appropriately characterized as 'other revenue'". The route then follows whatever that answer turns out to be: "we believe it will typically be appropriate to apply the Topic 606 revenue guidance, either directly (if the rewards are revenue from a contract with a customer) or by analogy (if the rewards are other revenue or other income)". Direct application and application by analogy are not the same thing, and the results diverge either way. Nine SEC registrants were examined. Individual registrants are described rather than named where the point is the spread of positions rather than any one company's; a name is given where a specific filing is itself the point, as with BitMine below and with the exchange-traded products. Eight of them stake, and among those eight there are seven different positions on when an ETH staking reward is recognised and how it is measured. Six of the seven come from audited annual financial statements and one from an unaudited quarterly report. (The ninth registrant, an exchange-traded product, "is not permitted to engage in Staking Activities" at all.) That position is no longer the uniform one among Ether exchange-traded products, though it is still the larger one by assets: Grayscale's ETHE and ETH Mini have staked since 6 October 2025, 21Shares' TETH was enabled on 8 October 2025, BlackRock's ETHB listed on about 12 March 2026, Morgan Stanley's MSSE launched on NYSE Arca on 28 July 2026 intending to stake "50 to 80% of the Trust's ether", and Fidelity's FETH was cleared to stake on 21 August 2026, ten days before this article's date. Enablement is not earning, and the gap is the validator entry queue: ETHB's ether "became actively staked and earning rewards" only on 4 May 2026, and TETH booked $1,121 of staking income across the whole of the fourth quarter of 2025 against $62,288 in the first quarter of 2026. Counting products, staking is roughly half the field. Counting assets it is the minority, because BlackRock's ETHA still does not stake, per its Form 424B3 of 6 August 2026, and ETHA is more than half the category by itself: $4,292,908,953 of the $8,390,726,363 in net assets that the ten single-asset US ether ETPs with a 30 June 2026 quarter end reported, or 51.2%. That share is this article's computation from those ten filings, not a statement in any of them, and it clears half by just over one percentage point - another $195 million anywhere else in the field would take it back to half. MSSE, which listed after that quarter end, has reported no net assets at all. The ETP row below is a snapshot of a line that is still moving.

Two of those deserve emphasis. One large exchange books rewards on its own investment ETH in other income rather than revenue, while every ETH treasury company examined books its own rewards as revenue. That first choice is not the anomaly it looks like: the AICPA presentation sentence above puts block-reward income recognised by analogy apart from ASC 606 revenue from contracts with customers, whether on the face of the statement or in the notes, and other income is one of the places it can sit. And two entities reach opposite gross-versus-net answers on the same protocol, but on genuinely different facts, which is the useful part. One operates the nodes and presents gross as principal node operator. The other stakes as a delegator and presents net, concluding that "it is the validators that control the service". The divergence is in the role, not in the reasoning, and an entity cannot pick whichever answer it prefers without first settling which role it is in.

The cost-basis methods diverge just as widely. Four methods appear across the same nine filers: specific identification, FIFO (in one case expressly applied wallet by wallet), LIFO and average cost. So do the pricing conventions: midnight UTC, hourly spot at receipt, 4:00 p.m. New York, and, in one ETP, 11:59 p.m. Eastern for the GAAP financial statements while the published net asset value uses a 4:00 p.m. Eastern benchmark.

The practical consequence for a preparer running its own validator is that Ethereum staking rewards accounting has no "market practice" to fall back on. There is a documented policy, or there is an exposure.

How Tokenbooks helps with staking reward recognition

A recognised reward has to become a dated, measured, lot-creating event before any of the questions above can be answered on it. Tokenbooks does that part. Reward income is recognised at the transaction timestamp, kept distinguishable from transfers, carries a selectable subtype of rewards or airdrop, and opens a lot in a ledger that records every add, disposal, cut, move, reservation and release. Rewards earned on a connected exchange account are ingested as income on Coinbase, Binance, Kraken and OKX.

Rebasing stETH is handled as a mechanic rather than as drift: the daily balance increase is synthesised into an income leg from the protocol's own oracle event, so growth becomes a dated receipt instead of an unexplained balance.

See the Ethereum integration page.

More in this series

Accounting Token Anatomy: Native ETH. This article stands alone, but the series builds in order.

Previous (01.2.6): Ethereum Valuation for Accounting

Next (01.2.10): Ethereum Accounting Under US GAAP

Sources and authority map

• Ethereum consensus specifications. github.com/ethereum/consensus-specs
• ethereum.org, proof-of-stake pages. proof of stake
• ethereum.org, staking pages. staking
• Flashbots documentation, block proposal. docs.flashbots.net
• Beacon API specification. ethereum.github.io/beacon-APIs
• IAS 38, IAS 36, IAS 2, IFRS 13, IFRS 15, IAS 8, IAS 21, IAS 7, IAS 12, IAS 1, IAS 10, IFRIC 23. IAS 38
• IASB staff paper AP6A, March 2024, and the IFRS 15 post-implementation review feedback statement, September 2024. AP6A
• KPMG IFRG, "Staking activities", questions and answers, June 2026. kpmg.com
• FASB ASU 2023-08 (ASC 350-60 and ASC 230-10-45-27A). storage.fasb.org
• AICPA, "Accounting for and auditing of digital assets" practice aid. aicpa-cima.com
• KPMG, "Crypto assets" handbook, April 2026, and "Accounting for staking activities", April 2026. handbook
• PwC, "Crypto assets guide", August 2025, and EY Technical Line, updated 28 March 2025. PwC
• Sharplink, Inc., Form 10-K for FY2025. sec.gov
• BTCS Inc., Form 10-K for FY2025. sec.gov
• Bit Digital, Inc., ETHZilla Corporation (now Forum Markets Inc) and BitMine Immersion Technologies, Inc., Forms 10-K. Bit Digital 10-K
• Exchange-traded-product filings on staking and on slashing. ETHE 10-K
• CRA, "Reporting income from crypto-asset mining and staking activities". canada.ca
• Revenue Ruling 2023-14. irs.gov

Research status. Protocol mechanics and published guidance were refreshed through 31 August 2026. Where a source is interpretive rather than authoritative, the text says so. This article is educational research, not accounting, tax, legal, valuation, or investment advice.