When the U.S. Treasury and IRS released Revenue Procedure 2025-31, they did more than “green light” staking for Ethereum and Solana ETFs. They told issuers that if they want the comfort of a safe harbor, they have to accept a very real operational constraint: staking rewards, net of trust expenses, need to be pushed out to investors on a regular schedule instead of being quietly trapped inside the product.

Jamison Sites at KPMG summarized it well: crypto ETFs can stake, but all the rewards need to be distributed to holders. On Solana, that requirement collides with some of the most complex accounting mechanics in digital assets. https://www.linkedin.com/posts/jamisonsites_treasury-secretary-scott-bessent-secscottbessent-activity-7393770340335636480-vjOT 

This post explains why tracking and distributing Solana staking rewards is not just a tax question. It is a data problem that touches protocol design, custody, staking providers, and the traditional fund accounting stack.

What the new guidance actually expects

Under Revenue Procedure 2025-31, an investment trust that wants to stake digital assets and still be treated as a grantor investment trust has to meet a list of conditions. One of the most important for fund operations is how staking rewards are handled.

At a high level:

• The trust can only hold cash and one type of proof-of-stake digital asset.
• Staking must be done through a custodian and independent staking provider.
• The only new asset the trust receives from staking is more of the same token it already holds.
• Staking rewards, after trust expenses, must be distributed proportionally to investors, either in kind or by selling for cash and distributing the proceeds, on a periodic schedule that is at least quarterly, and handled consistently over time.
  

For Ethereum this is already nontrivial. For Solana it is far more demanding, because of how the network represents stake, how frequently rewards are emitted, and how value moves through the system.

First challenge: finding the rewards on Solana

On Solana, there is no single “ETF wallet” where all staking rewards land in a neat, auditable stream.

Instead, Solana uses dedicated stake accounts. Each stake account:

• Holds a specific amount of SOL delegated to a validator
• Has a stake authority that controls delegation
• Has a withdraw authority that controls withdrawals and ownership changes
  

This dual authority model is excellent for separating portfolio management from custody, but it destroys the simple assumption that one public key equals one owner. As we outlined in Tracking Solana Stake Accounts, the private key for a stake account is effectively discarded once the account is initialized. From that point forward, control flows through the embedded authorities, not signatures from the stake account itself. 

For a staking-enabled ETF this leads to several complications:

• Stake accounts multiply quickly. Large positions are often split across many stake accounts per validator for risk management, operations, and liquidity.
• There is no on chain “master list” that says, “these 237 stake accounts belong to ETF X.”
• Authorities can change over time, especially when custodians or operational setups are updated.

The result is simple to describe and painful to implement: before you can even measure rewards, you need a reliable way to discover and track every stake account that is, or ever was, tied to the ETF’s authorities. NODE40 solves this with custom indexing. Without that kind of infrastructure, an issuer is stuck crawling raw chain history and maintaining homegrown lists that drift out of sync.

Second challenge: high-frequency, micro-sized reward flows

Solana runs in epochs that typically last a few days. At each epoch boundary, the protocol pushes staking rewards into stake accounts. For a single retail wallet this might be a handful of deposits each month. For an ETF staking across many validators and stake accounts, it can quickly become a firehose.

Each reward event:

• Lands in a specific stake account
• Carries a precise slot and block time
• May reflect a validator commission schedule that changed mid-epoch
• Has to be valued in fiat for NAV and tax reporting at a defensible timestamp

In Deconstructing Solana Validator Financial Performance we show how quickly this grows. A single validator can see hundreds of thousands of reward entries and fee-related movements over a reporting period. Scaling that to a fund that delegates to many validators, and potentially rebalances positions over time, creates millions of individual data points that need to be captured, classified, valued, and rolled forward. 

For an ETF that now must distribute the net of those rewards to shareholders at least quarterly, it is no longer acceptable to treat the chain as a black box and rely on approximate yields. The distribution obligation requires precise, transaction-level evidence.

Third challenge: matching rewards to a moving cap table

Even if you can see every lamport of reward flowing into every stake account, you still have to answer a harder question:

Which investors are entitled to which portion of those rewards?

In an ETF structure:

• Shares are created and redeemed throughout the day.
• Staked SOL may move between validators or be partially unstaked to meet redemptions.
• Rewards pertain to the period during which the trust held and staked the SOL, not to whoever happens to be a shareholder when the distribution check is cut.

That means you need two ledgers to talk to each other:

1. An on chain ledger that knows, for each epoch and stake account, how much reward was earned, when, and under what validator economics.
2. A fund ledger that knows the timing of share creations and redemptions, and the number of shares outstanding at every point in time.

If the ETF receives 1,200.567890123 SOL of net rewards across all its stake accounts for a quarter, you have to allocate that precisely across the shareholders of record in line with the product’s prospectus and applicable tax rules. The accounting team cannot round away the differences. Those fractions matter once they are converted to dollars and reported to investors and the IRS.

On Solana, where reward events may occur multiple times per week per stake account, that allocation problem becomes a high-frequency exercise. You are effectively running a tiny profit and loss allocation for every reward deposit, across a constantly shifting base of shares.

Fourth challenge: validator economics and ancillary revenue

Protocol rewards are not the only source of value in Solana staking.

Validators participating in programs like Jito capture additional revenue streams, including tips and MEV-related payments. Validators also collect transaction fees and may participate in ecosystem incentives. From the ETF’s perspective, this matters for two reasons:

• Validator commissions and fee arrangements determine the net reward received by the trust.
• Different streams may need different tax treatments and disclosures, even if they ultimately arrive in the same asset.

NODE40’s validator analytics already break apart inflationary rewards, commissions, fees, and MEV for Solana validators. For an ETF, that same level of attribution is required, but now it has to be reconciled back to the grantor trust and shareholder-level reporting. 

If the ETF wants to comply with the safe harbor and distribute “all” staking rewards, it cannot ignore these ancillary flows. They have to be visible, categorized, and included in the distribution calculus.

Fifth challenge: Solana’s evidence chain and PDAs

Solana uses cross-program invocations and Program-Derived Addresses extensively. Value often moves into PDAs and through DeFi or staking workflows before returning to a user-controlled account. A surface read of only the outer instructions will miss key movements.

In Building the Evidence Chain on Solana we describe what reliable audit evidence looks like:

• Start from the transaction signature, slot, and block time.
• Walk the full instruction tree, including inner instructions.
• Map PDAs back to the beneficial owner.
• Attribute token and lamport deltas, including all fee components, to the correct ledger entries.

For an ETF, this is not a nice-to-have. If any part of the evidence chain is missing, it becomes impossible to prove that the correct amount of SOL was:

1. Staked on behalf of the trust.
2. Rewarded by the protocol and related programs.
3. Received by the custodian in line with contractual splits.
4. Distributed, in kind or in cash, to shareholders in the right amounts.

Regulators, auditors, and large institutional allocators will eventually test this chain. If the story breaks in the middle, confidence erodes.

Why “distribute everything” strains existing information reporting

Traditional information reporting pipelines were not designed for this environment.

Most legacy systems assume:

• A modest number of income events per security, per period.
• Clean feeds from issuers and custodians.
• Limited need to reconcile back to a highly granular, public ledger.

Solana breaks those assumptions. Once staking is enabled inside an ETF:

• Every epoch-level reward, and every related adjustment, must be captured.
• Net income must be computed after validator, custodian, and trust expenses.
• That net income must be allocated across shareholders and pushed through the distribution and tax reporting stack.

Forms like the new 1099-DA will sit at the end of that pipeline. If upstream data is incomplete or inconsistent, issuers will find themselves re-stating information or fielding questions they cannot answer with documentary evidence.

Jamison Sites is right to flag this as a pressure point. The guidance opens the door to staking yield in regulated products, but it also exposes how fragile many of today’s digital asset data pipelines are once you move beyond simple “buy and hold” exposure.

What a workable Solana rewards solution looks like

To meet the new requirements without overwhelming operations teams, issuers need infrastructure that is purpose built for Solana and for compliance.

At a minimum, that includes:

• Stake account discovery and mapping
  A deterministic way to find and track every stake account associated with the ETF’s authorities, including splits, merges, and authority changes over time.
• Epoch-level rewards ledger
  A complete record of reward events that includes stake account, validator, slot, block time, lamports, and associated fee or commission context.
• Evidence-based valuation
  Independent price references and cutoffs that can be tied to each reward event, with clear rules for NAV and tax reporting.
• Share-level allocation logic
  Tight integration with fund accounting and transfer agent data so rewards are allocated fairly and precisely to shareholders based on the fund’s governing documents.
• Support for Solana edge cases
  Handling PDAs, CPI-heavy transactions, validator MEV programs, and ecosystem incentives without manual exceptions.

That is the standard NODE40 applies when we work with Solana validators and institutional clients. The same approach extends naturally to ETFs and other grantor trust structures that now want to stake SOL under the safe harbor.

Conclusion

Revenue Procedure 2025-31 removes a major legal barrier for Solana and Ethereum ETFs that want to stake. It does not make the data any simpler.

On Solana, “distribute every reward” means recovering a precise history of stake accounts, rewards, and validator economics, then lining that history up with a constantly changing cap table and a traditional information reporting stack.

Issuers that treat this as a spreadsheet problem will struggle. Issuers that treat it as an evidence problem, and invest in infrastructure that can turn Solana’s raw history into defensible schedules, will be able to offer staking yield with confidence.

That is where NODE40 operates: bridging Solana’s protocol-level complexity with the reporting standards ETF investors, auditors, and regulators already expect.