AZUP-2 proposed inclusions

[koenmtb1]

AZUP-2 (Aztec Network V5) is tentatively scheduled for deployment on June 24 2026.

Proposed inclusion:	Impl Status
AZIP-2 #3 Governance can't brick rollups	PR ready
AZIP-5 #14 Optimise prover rewards for consistency	Will be implemented as part of payload
AZIP-6 #17 Pipelined block building	Merged
AZIP-7 #16 Update slashing rules	Merged
AZIP-8 #19 Public key hash to mitigate "harvest now" risks	Merged
AZIP-9 #20 Private immutables	Merged
AZIP-10 #37 Add message-signing and fallback public keys	PR ready
AZIP-12 #29 Reduce protocol contract set	PR almost ready
AZIP-13 #30 Barretenberg v5 prover optimisations	Merged
AZIP-14 #33 Multiple roots per epoch in Outbox	PR ready
AZIP-16 #36 Activate Equivocation Slashing and Update Economic Parameters	Will be implemented as part of payload
AZIP-17 #41 Optimized Rollup Verifier	Merged

[iAmMichaelConnor]

The following need to be addressed in AZUP-2, but they don't technically need an AZIP:

Address domain separator:

The domain separator for an address preimage should be bumped. This process -- of bumping the address domain separator in every new version of Aztec -- is already understood to be a part of the protocol spec, so the act of bumping the domain separator doesn't need an AZIP. Nevertheless, AZUP-2 should specify what this domain-separator is.

Background: There was a lengthy discussion in 2025 about this subject (see here -- it's a notion doc, please request access). The doc began seeking to preserve the same addresses across rollups, but the solutions were so complicated and dangerous (from the perspective of people accidentally sending tokens to broken addresses) that it was decided that instead the safest thing to do would be to go in the other direction: to make it impossible for the same address to exist on two rollups, for strong safety.

The current domain separator is DOM_SEP__CONTRACT_ADDRESS_V1 = 1788365517, which is derived as (psuedocode) hash_to_u32("az_dom_sep", "contract_address_v1"). See constants_tests.nr.
Interestingly (and somewhat confusingly) the name "v1" was chosen since it was the first version of aztec with actual transactions, but colloquially that version of Aztec is being referred to as v4 (I think because the years-old aztec rollup was colloquially being included in version numbers for some strange reason).
AZUP-2 will bring "v5". So either we can choose "v2" or "v5".
I suggest jumping to hash_to_u32("az_dom_sep", "contract_address_v5") to match colloquial naming. Nightmare.

Public setup functions whitelist

AZUP-2 should also include the contract addresses of whitelisted public setup functions. This bytecode can only be whitelisted once the final release candidate is known. This is related to AZIP-12 #29 .

[IlyasRidhuan]

AZIP-10 is merged