Additional Information
In plain terms
Staking rewards are calculated every epoch and stored so they can be claimed later. During the first epoch transition following Supernova, the system filed the newly calculated rewards under the previous epoch instead of the new one.
This created two related problems.
First, one day's reward record could replace a reward record already stored in the same position. Second, if someone submitted a claim during this period, the system could move their claim checkpoint forward even when the claim paid 0 EGLD. Repeating the claim moves that checkpoint further and makes the account's recovery history more complex.
This is an accounting and record-assignment issue. The underlying EGLD has not left the staking system. We can identify the affected reward periods and restore the amounts through the recovery update.
Technical detail
Supernova introduced Header V3 behavior for the epoch-change proposal block. That block still carries the number of the epoch being completed, while epoch-start processing needs to operate on the epoch being entered.
The staking reward path used the epoch exposed by the block header when selecting the storage key. It therefore wrote the rewards under the previous epoch instead of using the effective epoch for the transition.
At the activation boundary, rewards earned during epoch 2232 had already been stored under the epoch 2233 key by the previous flow. The first Supernova transition then stored epoch 2233 rewards under that same key, overwriting the earlier entry.
The claim path also used the misaligned epoch value when advancing its checkpoint. A claim could therefore return zero while still moving the checkpoint past a reward period. Different claim histories produce different recovery cases, which is why users should not continue trying to claim.
The forward fix will align reward storage and claim checkpoints with the effective epoch used during epoch-start processing. The recovery update will then address the two resulting states separately:
Reward entries overwritten at the activation boundary
Claim checkpoints advanced without the corresponding reward payment
As an immediate mitigation, staking actions have been blocked in the main user interfaces and are being restricted at the gateway level, including relayed transaction paths. This limits the number of affected records while the coordinated fix is prepared and deployed.
We will provide further updates as deployment and recovery milestones are completed.