1. In one paragraph
Today, voter rewards are distributed by Hermes, a service that runs outside
consensus. It holds keys, recomputes staking weights off-chain, claims delegate
rewards, and sends out the voter portion. IIP-59 moves that job into the
protocol. After activation, the chain itself splits each delegate’s reward
according to that delegate’s configured portions, accumulates the voter share,
and pays every voter directly — either into their account or into their staking
bucket — with no claim transaction and no distribution fee.
2. What this means for you
If you are a voter
- You stop needing Hermes. Rewards arrive in your account on their own.
There is no claim step and no service fee taken out. - Payouts happen once per reward era, currently 24 epochs (roughly a day),
rather than continuously. Your reward accrues every block and every epoch; the
payout is batched. - You can send rewards somewhere else. A one-time on-chain action sets a
destination account — useful for custody, treasury, or tax separation. Without
it, rewards go to your voting account. - You can compound automatically. If you have registered an eligible native
staking bucket in the existingAutoDepositcontract, your reward is added to
that bucket instead of your account balance. - If you used
ForwardRegistrationwith Hermes, you must re-register. Those
entries are not imported into protocol state. ExistingAutoDeposit
registrations do carry over and keep working. - NFT/contract staking counts toward your weight but cannot be compounded.
Those rewards are paid to your account.
If you are a delegate
- Your commission is paid immediately, every block and every epoch, straight
to your owner account. No claim, no waiting for the era boundary. - Two groups migrate automatically at activation: delegates whose reward
address is one of the two configured Hermes vaults. Everyone else stays on the
legacy path until they opt in. - Opting in is owner-only and one-way. There is no action to return to
legacy mode. - Your
DelegateProfileportions are enforced by consensus. If your profile
is missing, incomplete, or unreadable, the protocol falls back to 100%
commission for that era — voters receive nothing until you register valid
portions. See §5.1; we would like feedback on this default. - Rewards go to your current owner account, not your stored reward address.
For a migrated delegate, the legacy reward address stops receiving newly
generated rewards. Balances accrued before migration stay claimable. - Priority tips remain 100% yours. They are fee income and are not split.
If you run a node
- Nothing to configure. The change is gated by a fork height and is inert
before it. - The first reward era after activation may pay voters one era late; see §6.
3. How rewards are calculated
For a migrated delegate, each reward stream is split using rates read from the
DelegateProfile contract:
commission = amount × commissionRate
voterShare = amount − commission
Two properties worth noting:
- Rounding favors voters. The commission is floored, so any division
remainder goes to the voter side. The delegate never receives dust. - The split is exact. Every rau in a delegate’s voter pool is paid out. The
final voter in the payout order receives the remainder from integer division,
which is always less than the number of voters in rau — a negligible amount,
but it means the total always reconciles.
Voter shares accumulate in a per-delegate pool block by block and epoch by
epoch. At each era boundary, the protocol freezes a snapshot — each voter’s
weight and the delegate’s rates — and pays the accumulated pool out against that
frozen snapshot over the following blocks.
Freezing matters: changing your stake mid-era does not retroactively change the
era being paid out. It affects the next one.
4. Why it is paid in chunks
A delegate can have tens of thousands of voters. Paying all of them in a single
block would exceed the time budget for producing and validating that block.
So the payout is spread across blocks, with a cap on how many voters are paid
per block. A settlement that has not finished by the next era boundary does not
halt anything — the remaining balance carries forward into the next settlement.
Nothing is lost or double-paid.
The order in which delegates and voters are paid is rotated each era, derived
from the previous block hash. Without rotation, if a settlement repeatedly ran
long, the same voters at the head of the list would be paid first every time.
Rotation changes only the order of service, never who is included, what they
are owed, or the total paid.
5. Design decisions we would like feedback on
These are the choices where reasonable people could disagree. Each reflects a
real trade-off, and we would rather hear objections now than after activation.
5.1 Missing delegate profile → 100% commission
If a delegate has no valid DelegateProfile entry when the era snapshot is
taken, the protocol treats the voter portion as zero and pays the whole reward
to the delegate owner.
Why: the protocol cannot invent a voter portion the delegate never configured,
and the alternative — refusing to pay anyone — would strand funds indefinitely.
The objection: a delegate that migrates automatically but has never set up a
profile would collect 100% while its voters get nothing, and voters may not
notice quickly. An alternative would be to keep the voter portion pending rather
than paying it as commission, forcing the delegate to configure a profile before
collecting the full amount.
Question for the community: should an unconfigured profile pay 100% to the
delegate, or hold the voter share pending?
5.2 Automatic migration limited to the two Hermes vaults
Only delegates whose reward address is one of the two configured Hermes vault
addresses migrate automatically. Every other delegate stays on the legacy path
until its owner explicitly opts in.
Why: those two addresses unambiguously indicate a delegate that was already
having Hermes distribute voter rewards. Migrating anyone else would change the
economics for delegates who never opted into voter distribution at all.
Question: is the automatic set correctly scoped? Are there delegates
distributing to voters through a different address who would expect to be
included?
5.3 Opt-in is one-way
Once a delegate enables on-chain distribution, there is no action to go back.
Why: a return to legacy mode could strand an accumulated pending pool and an
in-flight settlement, and reversibility invites switching to game a particular
era.
Question: is a permanent decision acceptable, or should there be an exit path
with a cool-down?
5.4 Priority tips are not shared with voters
Base block rewards and epoch rewards are split. Priority tips go entirely to the
delegate.
Why: tips are fee income for the work of block production and inclusion, not
protocol issuance.
Question: should voters share in tip income, and if so at what rate?
5.5 Compounding takes precedence over the direct destination
If a voter has both an eligible AutoDeposit bucket and a configured direct
destination, the reward is compounded and the destination is ignored for that
payout.
Why: a registered compound bucket is a stronger statement of intent than the
default routing.
Question: is that the right precedence? Should an explicitly set destination
instead override a previously configured compound bucket?
5.6 Payout cadence: one era ≈ one day
Voter rewards are paid once per 24-epoch era. Delegate commission is paid
continuously.
Why: every settlement carries fixed overhead — snapshots, routing decisions,
state writes. Batching amortizes it. Paying every voter every epoch multiplies
that cost with no change in the amount anyone receives.
Question: is a daily cadence right? A shorter era means faster payouts and more
overhead; a longer one means the opposite.
5.7 Contract-staking rewards cannot compound
NFT/contract-staking positions earn voting weight and therefore earn rewards,
but those rewards are always paid out directly — they cannot be added back into
a contract-staking position.
Why: the compound path deposits into native staking buckets, and contract
buckets are governed by their own contracts.
Question: is this asymmetry acceptable, or should contract-staking compounding
be a follow-up proposal?
6. Activation
The change is gated by a fork height. Before it, nothing changes.
At activation, the protocol writes out the voter weight table — the aggregated
weight of every (delegate, voter) pair. This is too large to write in a single
block, so it is spread across the following blocks. The window is short: at
current scale it closes in well under a minute, against a reward era of roughly
a day.
If an era boundary happens to fall inside that window, that era’s voter payouts
are deferred by one era. The funds stay in the pending pools and are paid in
full at the next settlement. Nothing is lost.
7. What happens when something goes wrong
The guiding rule is that no single bad input can stop the chain. Every failure
degrades one item rather than halting a block:
| Situation | What happens |
|---|---|
| A delegate’s profile is unreadable | That delegate pays 100% commission for the era; others are unaffected |
| A voter’s compound bucket is ineligible or gone | That voter is paid directly instead |
| A delegate’s voter snapshot is unusable | That delegate’s pool stays pending and is paid in a later era |
| A settlement runs past the next era boundary | The remainder rolls into the next settlement; an event is emitted |
| A delegate stops being rewarded but still has a pool | The pool is paid to its owner, or returned to the reward fund if the delegate no longer exists |
In every case funds are conserved: they are either paid, or they remain in the
pool waiting to be paid. Nothing is burned.
8. What this proposal does not change
- How block producers or epoch reward recipients are selected
- The staking vote-weight formula
- Probation, unproductive-delegate slashing, or foundation bonuses
- Delegates who do not migrate — their behavior is byte-for-byte unchanged
- Balances accrued before migration, which remain claimable as before
9. Verifying your rewards
Every payout is recorded on-chain. For each delegate window, an event records
the beneficiary, the account actually credited, the amount, and — for a compound
payout — the destination bucket. State queries expose the pending pool, the
current settlement’s progress, and an individual voter’s status and exact amount
in the active or most recent settlement.
This is the concrete improvement over the current arrangement: today, verifying
that you were paid correctly means reproducing Hermes’ off-chain calculation.
After IIP-59, it means reading the chain.
For the full normative specification — state layout, event formats, settlement
algorithm, and failure semantics — see
iip-59.md.