In September 2025, Kiln made a decision that showed exactly what responsible infrastructure management looks like. Following a hot-wallet breach at a partner company — a breach with no connection to Kiln's own systems — Kiln took the precautionary step of exiting approximately 1.6M ETH in validator stake from the Ethereum network. The 46-day exit-and-re-entry cycle was orderly. Funds were not lost. Kiln did the right thing.

That isn't the story. The story is what happened in the finance departments of Kiln's institutional customers during those 46 days.

The question that kept finance teams up at night

For any institution running staked ETH through a SaaS provider, a precautionary mass exit raises a question that's simple to ask and very hard to answer with confidence: during those 46 days, can we prove to our auditor that nothing was missing?

This isn't a question about whether Kiln made a mistake. It's a question about evidence. Staked ETH earns rewards continuously — attestation rewards accumulate every epoch (roughly every 6.4 minutes), block proposals happen randomly, MEV tips land in fee-recipient addresses that may or may not match the withdrawal address. A 46-day gap in active validation means roughly 10,150 epochs of rewards that didn't accrue. That's expected and explainable. But to prove it to an auditor requires an independent accounting of what should have been there versus what was there — one that doesn't rely entirely on the provider's own report.

For most institutional customers in September 2025, that independent accounting didn't exist. Provider reports were a black box. Customer-side on-chain data was either not collected or not reconciled against those reports. When finance teams went looking for their independent verification layer, they found they hadn't built one.

Why provider reports are not enough

This isn't a criticism of any specific provider. It's a structural observation about the relationship between SaaS-managed validators and their customers.

When you run validators through a managed provider — Kiln, Allnodes, Figment, Blockdaemon, or similar — the provider controls the operational side: the node infrastructure, the validator keys, the fee-recipient configuration, the MEV-Boost relay setup. They produce reports. Those reports are generated from their own data, verified against their own systems. The report is, by definition, the provider attesting to themselves.

For most purposes, this works fine. Providers have strong incentives to produce accurate reports: their business model depends on it.

But for audit purposes, the question isn't whether you trust the provider. The question is whether your auditor can verify the numbers independently. An auditor reviewing a tax return that says "staking income: $X" based entirely on a provider report is reviewing an attestation, not evidence. The distinction matters when something unusual happens — an emergency exit, a fee-recipient migration, a 1099-DA amendment, a billing dispute, a partnership change. Any of these events can cause a provider report to differ from the underlying on-chain reality. If you don't have an independent data layer, you have no way to tell which is right.

What independent reconciliation actually means

The Ethereum chain doesn't trust anyone. Every validator's reward history is publicly available. Every sweep to a withdrawal address is a transaction in the execution layer. Every fee-recipient payment is visible in block data. Every sync-committee participation, every attestation, every proposal — all of it is on-chain, with timestamps, in a form that can be reproduced independently by anyone running a beacon node.

TrueStake's ingestion pipeline reads this data directly: validator pubkeys and indices into the Lighthouse beacon API, execution-layer receipts from Reth. No provider reports. No intermediary attestations. The raw payloads from each API call are stored verbatim — not processed summaries — so the chain of custody is reproducible at any future point.

The reconciliation step is where this becomes verifiable rather than merely comprehensive. For each validator, for each period, the system computes a derived reward — what the beacon API says was earned across all reward types (attestation rewards, sync-committee rewards, block proposals, MEV tips) — and cross-checks it against the on-chain receipt — what actually landed in the withdrawal address and fee-recipient address, to the wei. If those two numbers don't agree within 100 wei, the system flags the discrepancy and blocks report generation until it's resolved.

(100 wei is approximately $0.000000000000000036 at current ETH prices — tight enough to catch any real data error, loose enough that known gwei-to-wei rounding artifacts in beacon-chain consensus math don't generate false positives.)

The result is a per-receipt income record where every number traces to a specific on-chain transaction, a specific beacon API response, and a specific reconciliation run. Not a spreadsheet of estimates. A chain of custody.

The SaaS-managed problem is structurally different from solo

Solo validators already have most of what they need to build this themselves. They control their own node infrastructure, they can query their own Lighthouse instance, they can see their own withdrawal address receipts. For a solo staker, the hard part is classification — decomposing income into its correct categories, handling the pre-Capella accrual period, accounting for MEV tips separately from attestation rewards. The data is accessible; the analysis is hard.

SaaS-managed customers face both problems, but the second one is harder. They can see their withdrawal address transactions — those are on-chain and public. What they often can't see independently is:

• Their validator pubkeys, which may not be disclosed by the provider or may be rotated without customer notification
• The fee-recipient address used during any given period, which the provider controls and which may differ from the withdrawal address
• The MEV relay configuration, which determines which MEV tips are attributable to which validators
• The exit and entry timing at the validator level, which is the data needed to compute exactly which reward epochs were missed during an event like the September 2025 exit

Independent reconciliation solves the visibility problem. If a customer provides their validator pubkeys — or TrueStake's onboarding process captures them directly from the customer's withdrawal address history — the reconciliation layer can independently verify what happened at the validator level, regardless of what the provider's report says.

Applying the reconciliation gate to a 46-day exit

What would the September 2025 timeline look like for a customer with independent reconciliation in place?

(The following is a synthetic illustration. Validator indices, reward amounts, and timing details are representative, not drawn from any real account.)

Suppose a customer has 50 validators under management with a SaaS provider. In September 2025, those validators exit the active set over a three-day period as part of the provider's precautionary withdrawal. They re-enter the active set 43 days later.

The reconciliation gate would see the following:

• Active epochs (before exit): Derived rewards match on-chain receipts within tolerance. Clean. Each receipt stored with epoch, slot, beacon API payload, execution-layer tx hash.
• Exit queue epochs: Validator status transitions from active_ongoing to active_exiting to exited_unslashed. No attestation rewards after exit. The epoch of each validator's last attestation reward is recorded. On-chain sweep for accumulated balance arrives at withdrawal address. Receipt stored.
• Dormant period (the 46 days): No validator-level rewards. On-chain: nothing in withdrawal address from those validators. Reconciliation: derived reward = 0 wei; on-chain receipt = 0 wei; gap = 0 wei; status = clean. The "nothing happened" is verified, not assumed.
• Re-entry epochs: New deposits detected, validator indices confirmed in Lighthouse, attestation rewards resume. Chain of custody resumes from the new activation epoch.

At the end of the period, the customer has a complete, validator-level income record for the year — including a verified record of the 46-day gap. The audit trail shows exactly what was earned before, exactly what was earned after, and a reconciled (zero-reward) accounting of the dormant period. There is no window where the customer is relying on the provider's assertion that nothing was missing. The on-chain data says nothing was missing, and the reconciliation gate confirmed it.

That is the audit-defensible answer to the question finance teams were asking.

Why this becomes more important, not less

The September 2025 event was unusual but not unique. The conditions that create audit-trail gaps for SaaS-managed customers aren't going away:

Provider consolidation is ongoing. When providers merge, migrate, or are acquired, validator sets change hands. Fee-recipient addresses may be migrated in bulk. Reward attribution during transitions is exactly the kind of thing that creates 1099-DA amendment scenarios.

1099-DA is coming. The IRS's digital asset reporting requirements are phasing in. Brokers and providers will be required to issue 1099-DA forms. When those forms are issued, customers will need to either accept the numbers on the form or have an independent basis for correcting them. The correction process requires the same chain of custody that a reconciliation gate provides.

Tax law is still settling. The Jarrett ruling and the ongoing question of whether staking rewards are income at receipt or at sale are not resolved. If the law changes retroactively — or if a specific customer's situation requires arguing a particular recognition policy — the ability to recompute recognition using the underlying on-chain data (rather than a provider's pre-computed number) is the difference between having options and not having options. TrueStake stores the raw receipts; tax recognition is computed at report time. If the law changes, recomputation is a parameter change, not a data reconstruction project.

What TrueStake is and isn't

To be direct about the scope: TrueStake is not a SaaS staking provider. We don't run validators, manage keys, configure MEV relays, or handle operational staking. Allnodes, Kiln, Figment, Blockdaemon, and the infrastructure providers in this market do that work well, at scale, with institutional-grade SLAs.

TrueStake is the independent reconciliation layer that sits alongside your provider. The provider runs the validators; TrueStake independently verifies what those validators earned.

This distinction matters for how to think about the value proposition. The question is not "should I switch providers?" The question is "do I have an independent record of what my provider's validators earned on my behalf, one that my auditor can verify without asking the provider?" For most institutional customers today, the answer is no. That's the gap TrueStake fills.

The September 2025 event made this gap visible. A precautionary exit by a well-run provider, with no customer losses, exposed the structural absence of an independent accounting layer in SaaS-managed staking. That absence isn't a reason to distrust providers. It's a reason to build the layer that should have been there already.

TrueStake is in early access. If you manage staked ETH through a SaaS provider and want to discuss your reconciliation setup, reach out at truestake.io.