Incident report: inactivity slashes following the v5 upgrade

Aztec
1

Incident report: inactivity slashes following the v5 upgrade

Posting as the PM responsible for the node at Aztec Labs. This is a factual account of the inactivity slashes that occurred after the v5 upgrade, and the measures taken to prevent this from happening again.

What happened

On 2026-07-14, the network upgraded to v5 following a successful vote of token holders and sequencers. The v5.0.0 node software shipped with a default slash grace period of 24 hours; the intended configuration was 7 days. When the grace period ended on 2026-07-15, nodes began voting to slash sequencers that were offline, primarily operators that had not yet upgraded to v5. The votes passed and reached L1.

The slashing mechanism operated correctly. The default configuration gave less time for operators to upgrade their node software.

Impact

  • Approximately 370,000 AZTEC has been slashed, all for inactivity offences. There is no sign of defective slashing.
  • Slash round 159 executed. The slash veto council has since paused slashing from round 160 through round 180. Rounds from 181 onward may be executed by sequencers, which would trigger further slashes.

Root cause

In March, the grace period was raised from 24 hours to 7 days on the v4 release branch and shipped in v4.1.0. That change was never forward-ported to the main development branch. v5.0.0 was cut from that branch, so it went out with the original 24-hour default. The default configuration was fully public and available on the aztec-packages repo.

Why detection took time

  • There was no internal alerting on slash votes or payloads; we learned of the issue from affected operators.
  • Nodes log no warnings when the configured sequencer identities appear in a slashing payload, which is hard to reconcile if a node is offline or on a different p2p network.
  • Community dashboards such as dashtec began tracking the v5 network three days after the upgrade, so the main tool operators use to check slashing activity showed nothing during the execution delay period.

What we’ve done

  • Worked with the slash veto council to pause pending slash rounds.
  • Released a patch restoring the correct defaults on all development branches.
  • Stood up a QA process for default configuration on every stable release.
  • Setup internal monitors to detect large slashing events ahead of their execution time.
  • Authored this incident report.

Edits:

  • Slashed amount is 370,000 not 182,000 as previously stated.
5 Likes
2

Thanks for the report — it confirms the root cause several of us reconstructed during the incident (the 7-day setting shipped on the v4 release branch and never forward-ported), and the new QA process and monitoring are the right preventive steps.

One gap remains, though: every measure listed is preventive. Nothing in the report addresses the slashes that already executed. Validators whose rounds happened to execute before the pause lost their stake; validators in identical circumstances whose rounds sat later in the queue lost nothing. That split is a function of round timing, not conduct, and at this point only governance can correct it.

I’ve published a proposal to complete the remedy: AZIP-TBD: Compensate Validators Slashed During the Excused Post-v5 Upgrade Window — a one-time transfer from the Protocol Treasury (~0.073% of its balance) to the registered withdrawers of all affected validators, under a parametric criterion reproducible from L1 data alone. Notably, the slashed funds were never burned: on-chain they were re-routed into the rollup’s reward pool, so the treasury would be correcting an accidental internal redistribution, not spending new value.

One note on figures: the report estimates ~182,000 AZTEC slashed. Summing the Slashed events of the executed rounds (148–159) gives 185 events × 2,000 = 370,000 AZTEC across 142 validators — the full per-address table is attached to the proposal and can be regenerated from a public RPC. Happy to share the method if useful.

Feedback on the proposal is welcome — in the discussion thread or here.