Aztec NM - Delegation Rewards Incident Post Mortem - 7/2/26

Summary:

For transparency and to close the loop on an incident, we are posting our analysis and post mortem on a delegation rewards incident that occurred on 7/2/26.

If anyone has any questions or concerns please reach out.


Date: February 7, 2026

Status: Resolved - all affected delegators have been fully compensated.


What happened

Between December 6, 2025 and February 7, 2026, a software bug in our internal keystore configuration tool caused a portion of our attesters to propose blocks with incorrect coinbase addresses. This misrouted block rewards across split contracts, some delegators received less than owed, while others received more.

The bug was a logical error introduced during a routine update to accommodate new validator slots. It caused the keystore entries to be sorted in a way that shifted coinbase assignments across attesters.

This was an operational error on our side. The Aztec protocol and its smart contracts functioned correctly throughout.


Impact

Affected period December 6, 2025 – February 7, 2026
Total delegations 876
Attesters affected 444 (sent rewards to incorrect split contracts at least once)

All delegators with a deficit have been fully compensated from our own token allocation. No action was required from any delegator.


Resolution

The bug was identified and fixed on the same day it was discovered (February 7, 2026). Keystores were corrected immediately and all sequencers resumed proposing blocks with the correct coinbase addresses.

We then conducted a full on-chain analysis to calculate the exact deficit for every affected delegator and funded the entire shortfall from our own pre-sale token allocation. Remediation funds were distributed to all affected split contracts at TGE on February 12, 2026.

  • All deficit delegators have received their full missing rewards
  • No action was required from affected delegators
  • No delegator has been or will be asked to return excess tokens

Timeline

Date Event
Dec 6, 2025 Bug introduced during internal tooling update to support new validator slots
Dec 6 - Feb 7 A portion of block proposals routed to incorrect split contracts (undetected)
Feb 7, 2026 Bug detected during routine keystore review and fixed same day - all keystores corrected
Feb 8, 2026 Full on-chain impact analysis completed
Feb 9, 2026 Independent verification completed; decision to self-fund the full deficit
Feb 12-18, 2026 Remediation funds distributed to all affected split contracts

Root cause

Our internal tool that maps delegations to attester keystores relied on array index positions rather than explicit attester identity matching. When the tool was updated on December 6 to support additional validator slots, a sorting change shifted the index mapping, causing coinbase addresses to be assigned to incorrect attesters.

The underlying process - operators manually configuring coinbase addresses in sequencer keystores - is inherently fragile and error-prone at scale. We raised concerns about this design with the Aztec team from our very first delegation. The Aztec team has acknowledged this and is developing a protocol-level fix to automate coinbase assignment, removing the need for manual operator configuration entirely.


What we’ve done to prevent recurrence

  1. Attester identity verification - The keystore updater now validates that the attester address matches the delegation record before writing any coinbase address. The previous index-based matching pattern has been eliminated.
  2. Automated real-time monitoring - We have deployed continuous monitoring that compares every keystore coinbase entry against on-chain delegation data, with immediate alerting on any mismatch.
  3. Dry-run mode with diff review - All keystore modifications now run in dry-run mode first, producing a human-readable diff that must be reviewed and approved before changes are applied to production.
  4. Pre-deployment validation - Automated consistency checks verify a strict 1:1 attester-to-coinbase mapping before any configuration update takes effect.

Delegator FAQ

Was I affected?

If you delegated to our provider (Provider ID 6) and had an active attester between December 6, 2025 and February 7, 2026, you may have been affected. All deficit delegators have already been compensated - no action is needed on your part.

Do I need to do anything?

No. The remediation has been completed. Your split contract has received the appropriate funds.

What about delegators who received excess rewards?

Some split contracts received more rewards than owed due to the coinbase shift. We covered the full deficit from our own allocation. No delegator will be asked to return tokens.

Will this happen again?

We have implemented automated identity verification, real-time monitoring, and dry-run review processes to make sure this never happens again. Additionally, works is being done on a protocol-level fix that will eliminate the need for manual coinbase configuration entirely.

Who can I contact?

If you have questions about this incident or your specific delegation, please reach out via our Discord channel #aztec-sequencer-support - Join the Nethermind Discord Server!

3 Likes

Thank you for this transparency.

After remediation, are the rewards now sent automatically to the split contract or to your coinbase address (0x340853553F8696c65fFe06bf7E898bD35165CC39) ?

1 Like

Thanks for the transparency John and the quick fix.

1 Like

@niceday, rewards are automatically being sent to the split contracts (associated with each delegation).

1 Like

Hi John,

I just saw this and kudos for transparency, but on our website, https://aztec.vision/provider/6?page=6, which indexes all these events, we still see gaps for Nethermind. Anything on a similar scale has only happened with P2P, which still happens from time to time with their new sequencers, but the point is they keep covering them and it perfectly matches our data; we observe these and we don’t see any mismatch concretely, yet we see them with Nethermind. If you can share your data with us, we would like to verify the numbers and fix the mistakes on our end if they are on our end, or if they are on your end, assist with recovering the gap.

Thanks for bringing this up @emrepiconbello.

We are digging into it, and will follow up asap.

Hi @emrepiconbello , I’m Denis from Nethermind, thanks for reporting it. I was checking your website, and the wrong Coinbase looks right, but I’m wondering how you are calculating the compensation.

Let’s use this sequencer as an example: https://aztec.vision/sequencer/0x71b4b1611e2dad0122527b80f3db7f4e4bb1266d

This shows 3 blocks proposed with the wrong coinbase, only 1 covered.

This is correct. On our analysis, we just covered 1 because this attester proposed 3 blocks with the wrong coinbase, but on the other hand, it received rewards for 2 blocks proposed by another sequencer, so the owed amount was only for 1 block proposed with the wrong coinbase.

@0xDones, I see your configuration mismatched the split contracts across sequencers. We just watch if it is misconfigured; if it is misconfigured, it remains in the DB as misconfigured. If any transactions after the misconfiguration come to the split contract address equal to the misconfigured block reward amount, it counts as covered. When it comes to things like this, there are millions of combinations, so we just keep things simple and try to keep on chain values. I guess them receiving rewards happened before the misconfiguration. That is still a very specific edge case. We will investigate and we will consider if we can also cover this case reliably. Thanks for sharing the details and making it clear for us.

I want to create a simple dashboard and keep it to the most minimal, but with all these different index requirements, it started to get very complicated and is burdening the team who maintains it. Hopefully, we can make it work because I believe the data is valuable as none of the current websites or platforms currently provide the L1 data for the Aztec network.

@emrepiconbello agree that it’s not simple to consolidate everything, we put a lot of effort into identifying the destination of every reward before compensating users. According to our analysis, we compensated all users 100% of the owed amount. To make sure everything matches, the sum of all AZTEC that was sent to the split address must be the number of blocks proposed * 280 AZTEC.

Let us know if you can cover those edge cases and if you need more info!

@0xDones Hi,

I finally had time to go over this. These and a few others like these look like they have one block gaps. I went over all the data and could not find them, so I wanted to verify and cross check with your data. There are six validators registered after this coverage with some misconfigurations, but we are keeping them out of this investigation.

0x1f51c03c9376776c2174bfe15032081614c22217
0x65fc197983dd6cf6b3cdc7e7e384749e95ce13fd
0xf019ce81501b288f706c99a5bfe45ef6b618167c
0xe0e841d5c386d76dbf0af56e46ede59b1661f55e
0x0df6753449786f6bb4f0c83b3aed9a8abc8c075c