How It Works4 min read

IoTeX Zanzibar: Who Calculates the Voter’s Reward?

A reward transfer already left a record on IoTeX. Zanzibar moves the calculation and distribution into the chain’s rules—with snapshots, eligibility checks and work spread across blocks.

IoTeX Zanzibar: Who Calculates the Voter’s Reward?

AI-generated conceptual illustration: two people reproduce the same allocation from a fixed reference. The counters are a metaphor for shared calculation, not actual payouts or equal rewards for all voters.

Key Points

  • IoTeXScan records Zanzibar’s activation block, 53,533,081, at 02:28:37 UTC on October 19, 2026; the announced 02:00 time was an estimate.
  • IIP-59 brings eligible delegates’ voter reward calculation and distribution into protocol rules. Hermes already recorded its transfers on-chain.
  • The released settings use 24-epoch reward eras and a 256-voter block budget. Migration, reward portions and payout destinations still have conditions.

Chronological Timeline

2026-09-24The activation height changes

The official note replaces the October 8 estimate with block 53,533,081 and an October 19 estimate.

2026-10-04A maintenance release preserves the schedule

v2.5.1 is published with the Zanzibar height unchanged and no additional hardfork.

2026-10-19The scheduled block is recorded

IoTeXScan and the Foundation’s public RPC endpoints agree on block 53,533,081 at 02:28:37 UTC.

Before a reward reaches the wallet

A reward in a wallet is the end of a longer calculation: which stake counted, which delegate it supported, what share that delegate assigned to voters, and where the payment should go. IoTeX’s Hermes service automated this work for participating delegates. Its distributions already used a and left on-chain records. Calling Zanzibar the first time those rewards became visible on the chain would miss the change.[5]

Zanzibar moves the calculation and distribution for participating delegates into the protocol itself. Validators derive the result from committed state as part of processing the chain, rather than depending on a separate service to calculate and submit each distribution. This is the idea behind IIP-59: bringing the work that precedes a payment into the rules that nodes reproduce.[1][3]

The clock was an estimate; the block is a record

The Mainnet activation point was block 53,533,081. IoTeXScan records that block at 02:28:37 UTC on October 19, 2026. The released code sets Zanzibar, Zanzibar Beta and Zanzibar Gamma to the same height. That block record supports activation having been reached; the previously announced 02:00 UTC was an estimate, not the observed block time.[2][4]

There was a schedule change along the way. A September 24 documentation commit moved the target from block 53,155,801, estimated for October 8, to the later height. The October 4 v2.5.1 maintenance release kept the new schedule. Mainnet receives the Beta and Gamma corrections together with Zanzibar, while Testnet had activated these stages separately. A release date, an estimated fork time and a recorded activation block describe different steps.[9][8][1]

Freeze the inputs, then share the work

The reward process has an accumulation phase and a settlement phase. The delegate’s portion is paid immediately; the voter portion collects in a pool associated with that delegate. At a reward-era boundary, the system fixes the inputs needed for settlement, including delegate settings and staking state. The released configuration makes an era 24 epochs. It does not promise a fixed clock-hour payment schedule.[3][4]

Payments then proceed in bounded chunks across subsequent blocks. The released default limits a chunk to 256 distinct voters, spreading the work instead of fitting an entire distribution into one block. A snapshot keeps the calculation tied to the relevant earlier state while staking continues to change. As a mental model, it is a fixed allocation sheet worked through in batches: a later edit to the live ledger does not silently rewrite the sheet already being settled.[3][4]

One fork does not put everyone on the same path

The automatic Hermes migration is a one-time operation at activation. It selects candidates using the configured Hermes vault reward addresses and requires both voter-reward portion fields in DelegateProfile. A candidate missing that configuration stays on the existing Hermes path. Other candidates can opt in through an owner-authorized action. The release note’s earlier survey of candidates describes a pre-fork snapshot, not an audited count of who actually migrated on October 19.[1][6]

A voter’s calculated contributions from different delegates can be combined into one payment. The routing code can credit the configured destination account or deposit the amount into an eligible native staking bucket when auto-deposit conditions are met. These are different destinations for an allocated reward. Simply holding IOTX does not establish participation, a reward amount or an automatic-compounding entitlement.[3][7]

What activation tells us—and what comes next

The activation block and released rules establish that the scheduled transition point has been reached. They do not establish that every eligible voter has already been paid. Era boundaries, staged processing and delegate configuration remain relevant after the fork. This article verifies the activation record and explains the released design; it does not audit individual payouts or measure realized returns.[1][2][4]

For a particular payment, the useful questions are concrete: did the delegate enter the new mode, what settings and stake were frozen for that settlement, and what credit or deposit was recorded? Zanzibar makes that chain of calculation part of shared execution. The value of the change is that the path from eligible stake to recorded payment can be examined against common rules, while those rules still determine who receives what.[3][6][7]

The next question

Continue reading

Explore the topic through other cases and contexts.

Sources & References

  1. [1]Source 1: Zanzibar release note: September 24 revisionIoTeX FoundationAccessed 2026-10-19
  2. [2]Source 2: Activation block 53,533,081IoTeXScanAccessed 2026-10-19
  3. [3]Source 3: IIP-59 design: protocol-native voter reward distribution (Draft)IoTeX Improvement ProposalsAccessed 2026-10-19
  4. [4]Source 4: v2.5.1 genesis code: fork heights and reward parametersIoTeX FoundationAccessed 2026-10-19
  5. [5]Source 5: Hermes: off-chain operation and on-chain distributionIoTeX DocumentationAccessed 2026-10-19
  6. [6]Source 6: v2.5.1 code: one-time Hermes migration and profile filterIoTeX FoundationAccessed 2026-10-19
  7. [7]Source 7: v2.5.1 code: combined voter payment and destination routingIoTeX FoundationAccessed 2026-10-19
  8. [8]Source 8: v2.5.1 release: unchanged Zanzibar scheduleIoTeX FoundationAccessed 2026-10-19
  9. [9]Source 9: September 24 commit rescheduling Mainnet activationIoTeX FoundationAccessed 2026-10-19
← Back to all storiesExplore all coins →