AZIP-TBD: Compensate Validators Slashed During the Excused Post-v5 Upgrade Window

[SrWilbur]

Preamble

azip	title	description	author	discussions-to	status	category	created
TBD	Compensate Validators Slashed During the Excused Post-v5 Upgrade Window	Returns, from the Protocol Treasury, the stake slashed for inactivity during the post-v5 window the SlashVeto Council excused	SrWilbur (@SrWilbur)	#57	Draft	Economics	2026-07-21

Abstract

During the v5 upgrade (executed on L1 on 2026-07-14 at 20:26 UTC), operators were told in the official migration thread that a 1-week grace period would apply before inactivity slashing. The actual deployed default was ~24 hours: the 7-day setting existed but never shipped in v5. Between 2026-07-19 and 2026-07-20, twelve slashing rounds (148–159) executed 185 slash events against 142 validators, for a total of 370,000 AZTEC — all for inactivity during the window operators had been told was safe. The SlashVeto Council recognized the miscommunication and approved a blanket veto (council issue 10), which saved the then-pending rounds; the already-executed rounds were beyond its powers. This proposal completes the remedy for the executed portion: a one-time transfer from the Protocol Treasury (~0.073% of its balance) returning the slashed amounts to the affected validators' registered withdrawer addresses. The slashed funds were never burned — they were internally re-routed to the rollup's reward pool — so this restores the status quo ante at negligible net cost to the protocol.

Impacted Stakeholders

Sequencers — 142 validator addresses across many independent operators (large pools and solo operators alike) lost 2,000–6,000 AZTEC each. Compensation restores their stake position. Sequencers not affected see no change to their stake or rewards going forward; the reward-pool subsidy created by the slashed funds is small and transient.

Tokenholders — The transfer spends 370,000 AZTEC (~0.073%) of the Protocol Treasury's 505,000,000 AZTEC. No tokens are minted; total supply is unchanged. Tokenholders gain from restored operator confidence: the credible message that following official instructions will not be economically punished lowers the risk premium of running (and delegating to) Aztec validators.

Aztec Labs / Core Contributors — The root cause was publicly acknowledged in Aztec Labs' official incident report: the 7-day grace period shipped only on the v4 release branch and was never forward-ported to the v5 line, and no QA process verified the deployed defaults (one was stood up only after the incident). A protocol-level remedy resolves the incident without requiring any party to fund compensation privately, while AZIP-TBD: Enshrine Post-Upgrade Grace Periods On-Chain (companion proposal; link to be added once its discussion thread is up) prevents recurrence.

Motivation

Three facts, all verifiable, make the executed slashes qualitatively different from ordinary inactivity:

1. Operators were given a written commitment. In the official v5 migration thread on the forum (V5 node migration guide, post #3, 2026-07-12), in direct response to the question of whether non-migrated nodes would be slashed: "Yes similar to the Alpha upgrade, there is a 1 week grace period from the moment the v5 upgrade is executed on Ethereum." The post was never edited or corrected — the first public acknowledgment of the discrepancy came in the official incident report of 2026-07-22, three days after the last round had executed. The 2026-07-09 mainnet announcement pointed operators to that thread as the reference for operator impact.
2. The commitment was not the deployed reality. The deployed mainnet default (spartan/environments/network-defaults.yml, mainnet block, tag v5.0.0) produced an effective grace of ~24 hours. Aztec Labs publicly confirmed the root cause in its official incident report (2026-07-22): the grace period had been raised to 7 days in March on the v4 release branch (shipped in v4.1.0) but was "never forward-ported to the main development branch", so v5.0.0 shipped with the original 24-hour default. The same report confirms there was no internal alerting on slash votes ("we learned of the issue from affected operators") and that the main community dashboard only began tracking v5 three days after the upgrade, "so the main tool operators use to check slashing activity showed nothing during the execution delay period". The report notes the deployed default was public in the repository; the official guidance operators were directed to stated otherwise, and no channel corrected it before execution.
3. The Council already accepted the argument — for the part it could still act on. The SlashVeto Council approved a blanket veto on 2026-07-20 explicitly "because of the miscommunication on this thread" (council issue 10), and pending rounds 160–164 expired unexecuted. Rounds 148–159 had already executed and are outside the Council's powers, which are veto-only, forward-looking, and time-boxed.

Two further points from the incident report bear directly on this proposal. First, its remediation list — a patch restoring the intended defaults, a QA process for release configuration, internal slashing monitors — is entirely preventive: it offers no remedy for the slashes already executed, which is precisely the gap this proposal closes. Second, the report estimates the impact at "approximately 182,000 AZTEC" without stating a methodology; the figure used throughout this proposal — 370,000 AZTEC — is the sum of the 185 executed slash events of rounds 148–159 at 2,000 AZTEC each, reproducible address by address from L1 event data (see the attached CSV).

The protocol's existing mechanisms therefore produced an arbitrary split: validators whose offenses landed in rounds that executed before 10:43 UTC on July 20 lost their stake; validators in identical circumstances whose rounds happened to sit later in the queue lost nothing. The split is a function of round timing, not of conduct. Governance is the only mechanism that can remove it.

An important factual point: the slashed tokens were not burned. On-chain, a slash performs no ERC-20 transfer; it reduces the validator's internal stake accounting and initiates a withdrawal from the Governance contract with the rollup instance as recipient. The 370,000 AZTEC ended up in the v5 rollup contract, where they subsidize the sequencer/prover reward pool. Total supply is unchanged at 10,350,000,000. Compensation from the treasury therefore does not leak value out of the protocol; it corrects an accidental internal redistribution from the slashed validators to the general reward pool.

Specification

The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Eligibility criterion. A slash event is eligible if and only if:

• it was executed on L1 (an offense that expired or was vetoed is not eligible), and
• its qualifying offense streak includes at least one committee epoch inside the excused window: from the v5 upgrade execution (2026-07-14 20:26 UTC) through the end of the grace period committed to in the migration thread (2026-07-21 20:26 UTC).

This criterion, applied at the time of writing, yields exactly the 185 events of rounds 148–159 (each offense epoch lies in the range 576–650, inside the excused window). It is deliberately parametric rather than a round list: the streak rule in force (SLASH_INACTIVITY_CONSECUTIVE_EPOCH_THRESHOLD: 2, with non-committee epochs skipped and not resetting the streak) allows an offense executed later to have its first qualifying leg inside the excused window (two such derived offenses are currently pending in rounds 191 and 194,council issue 12). If any such offense executes before the compensation payload is frozen, it becomes eligible under the same criterion.

Amounts. Each eligible event corresponds to 2,000 AZTEC (the deployed SLASH_AMOUNT_SMALL). Compensation per validator address is 2,000 × (number of eligible executed events). The full per-address table, reproducible from L1 data alone, is attached to this discussion as eligible-slashes.csv (to be moved to assets/ in the formal PR).

Recipient. For each affected validator (attester address), the compensation MUST be sent to the withdrawer address registered for that validator in the rollup's staking registry at a snapshot block declared in the payload, not to the attester hot key. Validators exited or ejected between the incident and execution remain eligible via their last registered withdrawer.

Mechanism. A single governance payload that, for each eligible withdrawer, calls ProtocolTreasury.relay(AZTEC_token, transfer(withdrawer_i, amount_i), 0) — the treasury at 0x662de311f94bdbb571d95b5909e9cc6a25a6802a (balance 505,000,000 AZTEC), owned by the Governance contract (0x1102471eb3378fee427121c9efcea452e4b6b75e). Total: 370,000 AZTEC as of writing (+4,000 maximum if the two derived offenses execute), i.e. ~0.073% of the treasury.

Timing constraint (inherited from the treasury contract). ProtocolTreasury.relay reverts unless (a) block.timestamp ≥ GATED_UNTIL (2026-11-13 14:00 UTC) and (b) the executing proposal was created after the treasury activation timestamp (2026-11-20 05:00 UTC). The on-chain proposal for this AZIP therefore MUST be created after 2026-11-20, giving an earliest execution around early December 2026. This AZIP is published now so that eligibility, amounts and design are settled and socially ratified long before the payload window opens.

Rationale

• Treasury, not minting. The CoinIssuer could mint the amount, but minting changes supply for a remediation the treasury can absorb at 0.073% of its balance. The treasury exists precisely for protocol-level expenditures ratified by governance.
• Network-wide, not per-operator. Eligibility is defined by an on-chain criterion, applied uniformly to all 142 affected validators regardless of operator. No operator is named and none receives discretionary treatment; the author's own affected validators are included by the same rule as everyone else's.
• Withdrawer, not attester. Attester keys are hot keys on operator infrastructure and frequently do not custody funds. The withdrawer is the address the protocol itself recognizes as entitled to the stake.
• Executed-only. Vetoed and expired offenses cost their validators nothing; compensating them would overshoot the damage. This also makes the proposal strictly complementary to the Council's action: the veto handled the future, this handles the past.
• Precedent risk is bounded. The eligibility criterion is anchored to a written official commitment contradicted by deployed defaults and to the Council's own finding of miscommunication. It does not create a general insurance mechanism for inactivity, operator error, or infrastructure failure — offenses without a qualifying leg inside the excused window (including the author's own pending same-day offenses from an unrelated infrastructure incident, council issue 13) are explicitly out of scope.
• Alternative considered — voluntary compensation by the responsible party. In the delegation-rewards incident of February 2026, the operator whose software caused the damage compensated affected parties from its own allocation (Aztec NM incident post mortem). That path remains open and welcome here: should Aztec Labs or any party make affected validators whole before this proposal reaches its on-chain stage, this AZIP SHOULD be withdrawn as moot.

Backwards Compatibility

Fully backwards compatible. The payload performs ERC-20 transfers from the treasury; no protocol parameter, contract code, or consensus rule changes.

Economics Considerations

• Source and size: 370,000–374,000 AZTEC from a 505,000,000 AZTEC treasury (~0.073%). No minting; circulating supply impact limited to moving custody from an idle treasury to ~142 validator withdrawers.
• Destination: fully enumerated per-address in the attached CSV; every row is independently reproducible from the Slashed / RoundExecuted events on L1 and the committee history exposed by getSlashTargetCommittees on the SlashingProposer (0x8a36b8f2ca71d8d8bd98e03ebf8b4d0939daf0ba).
• Incentive effects: the compensation restores the incentive that slashing is meant to protect — that following the protocol's official operational guidance is safe. Leaving the split standing teaches operators that written guidance from the core team cannot be relied on, which raises the effective cost of capital for the whole validator set.
• Reward pool interaction: the slashed funds currently subsidize the rollup reward pool. This proposal does not claw that subsidy back (doing so would penalize uninvolved sequencers); the treasury absorbs the full cost.

Security Considerations

• The payload consists exclusively of ProtocolTreasury.relay calls wrapping ERC-20 transfers: no state-changing calls into the rollup, staking, or slashing systems, no approvals, no delegatecalls.
• The recipient set and amounts are fixed at payload deployment and independently verifiable against L1 data before signaling; reviewers can regenerate the table from public RPC alone.
• The snapshot block for withdrawer resolution MUST be declared in the payload and be in the past at deployment time, eliminating registry-manipulation races.
• Treasury gating rules (proposal created after activation; execution after GATED_UNTIL) are enforced by the ProtocolTreasury contract itself; a mis-timed proposal fails closed with GateIsClosed.

Copyright Waiver

Copyright and related rights waived via CC0.
Annex: eligible-slashes.csv — 142 addresses / 185 events / 370,000 AZTEC. eligible-slashes.csv

[sekuba]

all slashes were visible on slashveto.me directly after the v5 upgrade, while dashtec was late with updating as amin says in the postmortem
i personally saw them but did not assume anything wrong because i didn't know about the new 1 week intended grace period
in general i feel like the onchain proposal process leaves enough time for operators to prepare, even with a 1 day grace period

no strong opinion either way but this might provide some context ;)

[SrWilbur]

Good point on slashveto.me — fair. To clarify: that line in the proposal ("the main tool operators use to check slashing activity showed nothing…") is quoted from the official incident report, and refers specifically to the main community dashboard — the data was visible for anyone who knew where to look, as you say.

I think your experience and mine are the two halves of the same failure: you were watching the data but didn't know about the promised grace period, so nothing looked wrong; I knew about the grace period and precisely because of that I had no reason to be watching for slashes — I'd been told the window was safe. The 1-week commitment never became common knowledge, so the alarm couldn't come from anywhere. That's why data visibility, on its own, wasn't enough.

On whether 1 day is enough in general: maybe — but the proposal deliberately takes no position on the right duration. The argument is narrower: 1 week was committed to in writing, something else was deployed, and 142 validators paid the difference. With a 1-day commitment from the start, there would be no case here.

[aminsammara]

Amin here, I wrote the incident report referenced in this discussion.

On the decision itself: Aztec Labs currently does not participate in Governance and does not vote. Whether or not Governance should compensate validators is up to the sequencers, their delegators and token holders.

On "official protocol guidance": No forum posts, migration guides, release notes and/or repository defaults from Aztec Labs should be construed as official protocol guidance. Aztec Labs is one of many contributors to the Aztec Network protocol. The protocol is the deployed contracts and what they do, and they are always voted on by Governance.

On the numbers: The total slashed amount is 370,000 AZTEC as reported by @SrWilbur and not 182,000. I will revise the incident report.

If Governance concludes compensation is warranted, Aztec Labs is happy to consult on the implementation. An upcoming ACD call would be a reasonable place to work out the path forward.

[SrWilbur]

Thanks Amin — for engaging here and for revising the incident report figure. The per-address breakdown behind the 370,000 total is in the attached eligible-slashes.csv, in case it's useful for the revision.

On the guidance point: agreed — and the proposal doesn't actually depend on construing any Labs communication as protocol law, nor does it require attributing fault to any contributor. Eligibility is anchored to three facts that stand on their own: the written commitment in the migration thread that operators relied on, the deployed defaults that contradicted it, and the SlashVeto Council's own finding of miscommunication (issue #10). It extends to the executed rounds the same reasoning the Council already applied to the rounds it could still veto. And whether that warrants compensation is, as you say, entirely up to the sequencers, delegators and token holders — which is precisely why this is before Governance as an AZIP rather than a request to Labs.

An upcoming ACD call sounds like a reasonable place to work out the implementation path.

[SrWilbur]

@koenmtb1 Following Amin's suggestion above, I'd like to bring this proposal to an upcoming ACD call to work out the path forward. Would the August 13 call work? I I've also requested to join the governance Signal group — request pending.