Understanding Chain Derived receipts
Chain Derived is TrueStake's strongest audit grade — the one every Solo and SaaS-managed validator gets. The guarantee behind it: every reward is reconciled, to the wei, against an on-chain settlement event your validator actually originated, with the raw upstream API payload preserved as evidence.
Nothing about the number is TrueStake's word for it. The chain is the witness — which is what makes the record audit-defensible rather than merely accurate.
Every amount lives on a receipt: TrueStake's record of a single settled amount, tied to its settlement event and audit grade.
The settlement events it's checked against
A Chain Derived receipt always traces back to one of three kinds of on-chain events:
- A sweep withdrawal — the protocol's automatic payout of any balance above 32 ETH on a 0x01/0x02 validator, roughly every 9–12 days.
- A user-triggered (EIP-7002) withdrawal — a withdrawal you or your provider explicitly requested at the execution layer.
- A fee-recipient payment — priority fees and MEV-Boost relay payments paid directly to your validator's fee recipient address when it proposes a block.
Each of these is a real transaction on the Ethereum chain, not an estimate or a snapshot.
How the reconciliation works
For each account and period, TrueStake sums the receipts it has recorded and checks that sum against your own on-chain wallet settlement for the same period.
The check runs against TrueStake's own Reth (execution) and Lighthouse (consensus) node data — not a third-party API. The two are expected to match within a 100-wei tolerance by default; the tolerance is configurable per account.
If they don't match, TrueStake doesn't quietly adjust the number to make it fit. The mismatch becomes a reconciliation finding you can see and investigate from your dashboard.
Why "the chain, not TrueStake" is the trust model
This is what auditors and tax preparers call a Chain Trust model. You're not asked to trust TrueStake's bookkeeping — you're shown the on-chain event, and you or your CPA can independently verify it against a block explorer.
TrueStake's job is to find the event, reconcile it to the wei, and preserve the raw upstream payload it was built from, so the chain of evidence survives even if a data source is later found to have had an error.
How this differs from Oracle Derived or Best-Effort
Chain Derived is specific to setups where TrueStake can point at a settlement event you originated. Liquid staking positions instead reconcile against a protocol's own on-chain Oracle report — a different audit trail that terminates at the protocol's Oracle, not your own node. Best-Effort covers staking topologies with neither a node nor a protocol Oracle available, and isn't used in v1. See What is audit grade and why does it matter? for how all three compare.
Questions?
Email support@truestake.io if a receipt's grade or reconciliation status looks wrong.