This article is educational and does not constitute legal or tax advice. MEV income classification involves open questions under US tax law that the IRS has not specifically addressed. Consult a qualified tax professional before taking any position on your return. The tax-research basis for this piece is documented in TrueStake's internal research library (us-08-mev-income-classification.md, status: counsel-required).

If you run Ethereum validators, your income comes from at least two distinct on-chain flows — and they land at two different addresses. The first is the consensus reward stream: attestation rewards, sync-committee rewards, and block-proposal base fees, which sweep to your withdrawal address (for 0x01 validators) via the beacon chain. The second is the MEV-Boost payout stream: when your validator proposes a block and wins an MEV auction, the winning relay's payout goes to your fee-recipient address — which may or may not be the same as your withdrawal address.

Most crypto-tax tools read wallet addresses. A tool pointed at your withdrawal address captures the first stream. It will never see the second stream unless you separately add the fee-recipient address, and even then it won't connect the payout to the specific slot and validator that earned it.

Before we get to the software problem, there's a tax-law question that needs to be answered: what is MEV income, and how should you report it?

The short answer is that MEV-Boost payouts are almost certainly ordinary income under IRC §61, recognized when your fee-recipient address receives the credit — the same characterization that applies to your consensus rewards under Rev. Rul. 2023-14. The longer answer is that the IRS has never specifically addressed MEV-Boost relay payouts, that characterization rests on analogy rather than direct authority, and that several edge cases remain genuinely open.

This piece explains the reasoning, the gaps, and why getting the data infrastructure right matters regardless of how the edge cases eventually resolve.

What MEV-Boost actually is

MEV stands for maximal extractable value: the profit available to a block proposer by controlling the ordering, inclusion, or exclusion of transactions within a block. It surfaces as arbitrage opportunities, liquidations, and sandwich trades that are only visible to whoever assembles the block.

MEV-Boost is the dominant infrastructure for capturing MEV on Ethereum. Instead of building the block themselves, validators using MEV-Boost outsource block construction to specialized builders. Builders compete in a relay-mediated auction: they submit bids to a relay, and the relay presents the highest-paying bid to the validator. If the validator signs the relay's proposed block, the relay delivers the full block and the winning bid amount flows to the validator's fee-recipient address. The fee-recipient address is set in the validator's execution client configuration — it receives the payout directly from the relay's escrow, typically in the same block, via a coinbase transaction.

The result is that a validator can earn significantly more on its block-proposal slots via MEV-Boost than it would from the base fee alone. The amounts vary by market conditions and slot opportunity, but a single high-value block proposal can yield a MEV tip that exceeds weeks of attestation rewards. These are not cosmetic amounts.

The address problem: why your tax software is probably missing MEV

For post-Capella validators with 0x01 credentials, the withdrawal address and the fee-recipient address are logically distinct. Your withdrawal address is encoded in the validator's credentials on the beacon chain and receives consensus reward sweeps automatically. Your fee-recipient address is a configuration value in your execution client — you set it when you configure your node, and it can be any address.

Many solo validators set both to the same Ethereum address. But many don't — especially validators set up before best practices crystallized, validators run through SaaS providers (Allnodes, Kiln, Blockdaemon) who manage fee recipients on your behalf, or validators that have changed fee-recipient configuration over time.

When these addresses differ, here's what happens with a wallet-based tax tool:

1. You scan your withdrawal address. You see your consensus reward sweeps. You report those.
2. Your MEV tips went to a different address. The tool never saw them. They don't appear on your return.

This is a reporting gap, not a legal ambiguity. Whether MEV income is taxable is a question the analysis below addresses. That it belongs on your return if it is taxable is not in question. The practical problem is that the data capture has to start from the validator pubkey — which links the withdrawal address AND the fee-recipient address AND the specific block proposals — not from a wallet address scan.

IRC §61 and the "all income from whatever source" standard

The US tax code's definition of gross income is deliberately broad. IRC §61(a) reads: "Except as otherwise provided in this subtitle, gross income means all income from whatever source derived." The Supreme Court in Commissioner v. Glenshaw Glass Co., 348 U.S. 426 (1955), articulated the test that has governed ever since: an item is gross income if it is (1) an undeniable accession to wealth, (2) clearly realized, and (3) over which the taxpayer has complete dominion and control.

MEV-Boost payouts satisfy all three the moment the fee-recipient address is credited:

1. Undeniable accession to wealth: ETH has arrived in an address you control. There is no contingency, no clawback, no further obligation required to keep it.
2. Clearly realized: Unlike a gain on an asset you still hold, the MEV payout is a completed transaction. You don't need to sell anything; the ETH has transferred.
3. Complete dominion and control: The fee-recipient address is yours. The ETH is spendable from the moment the block is finalized.

The §61 inclusion argument is strong. The more uncertain questions are about characterization within §61 — which we return to below.

The Notice 2014-21 and Rev. Rul. 2023-14 analogies

The IRS has not issued guidance specifically addressing MEV-Boost payouts. Two pieces of authority provide the closest analogies, and both cut toward ordinary income treatment:

IRS Notice 2014-21 (2014): Established that virtual currency is property for federal tax purposes. Q&A-8 of the Notice addresses mining rewards: "If a taxpayer's mining of virtual currency constitutes a trade or business, and the mining activity is not undertaken by the taxpayer as an employee, the net earnings from self-employment... are subject to self-employment tax." More broadly, the Notice treats mining rewards as includible in gross income at FMV on the date of receipt. Mining and block-proposing are structurally analogous: both are per-block computational reward flows to the party that extends (or in Ethereum's PoS case, attests and proposes within) the chain. The IRS has never suggested that this analogy breaks down, and the academic consensus among crypto-tax practitioners treats it as the operative framework for block-proposer rewards.

Rev. Rul. 2023-14 (2023): Addressed PoS staking rewards specifically, holding that they are includible under §61 in the taxable year the taxpayer gains "dominion and control." This ruling covers consensus rewards — attestation rewards, sync-committee rewards, and base-fee proposal rewards — by the dominion-and-control standard. MEV-Boost payouts, which also flow from block proposals, sit in the same analytic neighborhood. The fee-recipient address receives the MEV credit at proposal time, establishing dominion and control at that moment. The ruling doesn't address MEV specifically, but its framework applies cleanly.

The gap: Neither Notice 2014-21 nor Rev. Rul. 2023-14 addresses MEV-Boost relay payouts as a distinct payment type. The §61 ordinary-income treatment is the common practitioner default — it is defensible by analogy — but it is not settled by direct IRS authority. This distinction matters for a return that might be examined.

Recognition timing: when is MEV income recognized?

Under the §61 ordinary-income framework applied by analogy from Rev. Rul. 2023-14, MEV income is recognized when the fee-recipient address receives the credit — the proposal block's timestamp. This is the moment of dominion and control.

This timing matters practically because MEV payouts do not flow through the beacon-chain withdrawal queue. They are immediate execution-layer transfers: the relay's coinbase transaction in the same block the validator proposes. There is no sweep delay, no withdrawal queue latency. Income attaches at the proposal block timestamp regardless of whether you've swept or moved the ETH since.

For FMV: the same methodology applicable to consensus rewards applies to MEV. Most practitioners use the daily close price on the recognition date from a reputable exchange. Rev. Rul. 2023-14 requires FMV at the time of dominion-and-control, and Notice 2014-21 requires FMV at the date of receipt. Whatever FMV source you use for your consensus rewards should be applied consistently to your MEV income.

What the IRS has never addressed — and why it matters

The IRS has not issued guidance specifically covering:

• MEV-Boost relay payouts as a distinct income type separate from consensus rewards or mining rewards
• Whether the proposer, builder, or relay is the "earner" for §61 purposes (though the practical answer — the proposer earns it via the fee-recipient credit — is strongly supported by the structure of the payment)
• Priority fees vs. MEV tips: execution-layer priority fees (included in every block, not just MEV-Boost blocks) are economically similar to MEV tips and are treated identically in TrueStake's implementation, but the IRS has not addressed either type directly

This is not an academic concern. The difference between "defensible by analogy" and "settled by direct authority" matters for two reasons:

First, a return that takes a position not directly covered by IRS guidance is exposed to challenge on that position even if the underlying legal theory is strong. The ordinary-income characterization by analogy is unlikely to be wrong, but "unlikely to be wrong" is not the same as "covered by Rev. Rul. 2023-14."

Second, the open questions about characterization within §61 — fee-for-service income? self-employment income? — carry different downstream consequences depending on how your overall staking activity is characterized under §162 (trade-or-business analysis). Those questions interact, and they haven't been resolved.

Open questions your CPA should know about

1. Fee-for-service vs. ordinary income from a trade or business. The practical difference between these §61 sub-characterizations is primarily SE-tax exposure. If MEV-Boost relay payouts are fee-for-service income from a trade or business, they may be subject to self-employment tax under the same analysis applicable to any SE income. If they're ordinary income from property, SE tax may not apply. The §162 trade-or-business analysis (which depends on facts like the number of validators, the time spent, and the intent of the activity) governs this — and MEV-Boost configuration decisions are arguably more "active" than passive consensus participation. The research library flags this as counsel-required.

2. Local-builder MEV: is any portion capital gain? A solo staker who runs their own MEV builder (not relying on external relays) and extracts value from their own ETH positions — rather than from transaction ordering — raises a different question: could any portion of that extraction be a capital gain from a disposition rather than ordinary income? This is a tail-risk edge case; most validators use external MEV-Boost relays and this scenario doesn't apply to them. But it remains open, and the IRS Notice 2014-21 mining-reward analogy doesn't cleanly reach it.

3. MEV's contribution to the §162 / §183 analysis. Whether you're running a trade or business (§162) or a hobby (§183) affects the deductibility of your validator expenses, your SE-tax exposure, and potentially the character of any MEV income. MEV-Boost configuration and relay selection require active management decisions; an operator who actively curates their relay list is arguably more business-like than a purely passive depositor. No IRS guidance draws this line.

None of these open questions affect whether MEV income belongs on your return — it does, under the ordinary-income framework. They affect how it's characterized, which has downstream consequences for specific tax calculations.

The data problem is independent of the legal question

Whether the open legal questions eventually resolve in favor of "ordinary income, full stop" or "SE income" or some other characterization, the data you need for your return is the same: the MEV payout amount (in wei), the recognition timestamp (the proposal block), the fee-recipient address that received the credit, the validator index that proposed the block, and the FMV at recognition.

You cannot produce that data from a wallet address scan. The wallet address scan captures deposits to a specific address. The connection between "this credit arrived in this address on this date" and "this was a MEV-Boost payout from validator 512300 on slot 7,400,220 at the following FMV" requires starting from the validator pubkey, following the proposal record, and reconciling the execution-layer receipt against the beacon-chain data.

This is why TrueStake builds from the validator pubkey rather than the withdrawal address. Every MEV payout is captured as an mev event-type receipt, linked to the specific proposal slot via the relay query log, and reconciled against the actual on-chain credit. The fee-recipient address — whichever address it is — is the one that needs to be tracked, separate from the withdrawal address, and the connection between them runs through the validator's block-proposal record.

What to do now

If you run validators and use MEV-Boost, the minimum checklist is:

Know your fee-recipient address. Log into your execution client configuration (Geth, Reth, Nethermind) and confirm the fee-recipient or suggested-fee-recipient setting. If you use a SaaS staking provider, ask them what address receives your MEV tips and whether it is the same as your withdrawal address.

Check whether your tax tool captures it. Ask specifically: does it track fee-recipient addresses separately from withdrawal addresses? Does it connect MEV payouts to specific validator indices and proposal slots? If the answer is no, you have a data gap.

Treat it as ordinary income pending guidance. The §61 ordinary-income characterization is the defensible default by analogy to Notice 2014-21 and Rev. Rul. 2023-14. Recognize it at the proposal block timestamp at FMV, consistent with your consensus rewards. Apply the same FMV source consistently.

Flag the open questions with your CPA. If you have a significant number of validators, meaningful MEV income, or any uncertainty about your §162 trade-or-business status, bring the open questions in this article to your CPA's attention. They don't have IRS guidance to cite on MEV specifically — which is the point. Document your position and the reasoning behind it.

Why this matters more than it used to

MEV conditions vary by network activity and validator slot luck, but validators that propose blocks regularly can see MEV tips that individually exceed weeks of consensus rewards. In high-activity periods — major protocol events, NFT mints, DeFi liquidation cascades — MEV payouts per slot can be substantial. This is no longer edge-case income for an actively-running validator fleet.

Meanwhile, IRS data-matching capability is improving. The 1099-DA regime (beginning for tax year 2025 transactions) puts broker-level reporting in place for centralized exchange users. Solo validators are not brokers and don't receive 1099-DAs for their own staking income — but the broader data infrastructure the IRS is building means that income the agency can verify will increasingly be matched against returns. MEV income that went to a separate fee-recipient address and never appeared on a wallet-scan return is exactly the kind of gap that surfaces in an examination.

The solution is not to guess whether MEV is income. It almost certainly is. The solution is to build the data infrastructure that proves what you earned, from which validators, via which proposals, at which FMV — so that when the IRS catches up with specific MEV guidance, you have the records to comply or defend regardless of how the question resolves.

Policy coverage in this article reflects TrueStake's tax research library as of October 2026. Primary sources: IRC §61(a), Treas. Reg. §1.61-1(a), Commissioner v. Glenshaw Glass Co. 348 U.S. 426 (1955), IRS Notice 2014-21 (Mar. 2014), IRS Rev. Rul. 2023-14 (Aug. 2023). MEV-Boost relay architecture: mevboost.org. The IRS has not issued guidance specifically addressing MEV-Boost relay payouts; the ordinary-income characterization in this article rests on analogy to existing authority, not direct IRS ruling. Open questions regarding characterization within §61 (SE income, fee-for-service, §162 trade-or-business interaction) are flagged in TrueStake's internal research library as counsel-required (status: 🔴). This is not legal or tax advice — consult a qualified tax professional for positions specific to your situation.