[AztecBot]

Into #25521. Carries @spalladino's two commits from #25622 unchanged and adds the one failure they don't cover, so merging this lands everything and closes that PR.

The pattern

Each is a test pinning an address derived from inputs the separator doesn't change, so the pin — and only the pin — moves. Four so far, in the order CI surfaced them:

labs patch	what pinned a v5 address	author
0015	protocol-contracts/fixtures/ContractInstancePublishedEventData.hex + its event snapshot	spalladino
0016	key-store/src/key_store.test.ts inline snapshots; PXE AddressStore.json + KeyStore.json	spalladino
0017	handshake_registry_contract's recipient_signature fixture	claudebox

0017 — the remaining failure

RecipientSignature::verify opens by binding the returned keys to the address:

assert_eq(
    recipient,
    AztecAddress::compute(self.public_keys, self.partial_address),
    "handshake public keys do not match recipient",
);

The fixture's recipient was derived under the old separator, so seven of the eight recipient_signature tests fail on that line — every one that gets past it. interactive_signature_rejects_wrong_recipient passes, because it is the one that expects this mismatch. The schnorr signature is over [chain_id, version, registry, eph_pk_x] and never commits to the address, so only the one constant moves:

0x1b94108a…d15b → 0x1866b3a2…f2c4

Cross-check of 0016

Rather than take the new values on trust I re-derived all three from the fixtures' own fields, with an independent Poseidon2-BN254 + Grumpkin implementation built from barretenberg's parameters and self-tested against poseidon2.test.cpp::HashConsistencyCheck. The check that matters is the backwards one — recomputing with the old separator has to reproduce each pinned value exactly, which is what proves the derivation inputs are right:

pin	V2 recompute	V3 →
key-store snapshot	reproduces 0x0a3120bd…3940	0x085dc217…a7b3 ✓ matches 0016
PXE complete_addresses[0]	reproduces 0x2369ead0…ce44	0x20c1641e…493a ✓ matches 0016
PXE complete_addresses[1]	reproduces 0x1fc97e4d…ba63	0x23210e69…05aa ✓ matches 0016
handshake recipient	reproduces 0x1b94108a…d15b	0x1866b3a2…f2c4 (this PR)

The complete_address_index reordering in 0016 is also right: the map is keyed by the address string, and under v3 0x20c1641e… sorts before 0x23210e69…, so the num:0/num:1 values swap against the keys. For the record the serialized CompleteAddress layout is address, npk_m_hash, ivpk.x, ivpk.y, ovpk, tpk, mspk, fbpk, partial_address.

I had pushed a narrower version of the PXE fix before picking up 0016; it was wrong — it replaced only complete_addresses[0]'s address, leaving [1] stale and the index map mis-sorted. 0016 is the correct one and this branch now carries it verbatim.

Not verified locally

No test was run here. nargo is not present in this container and rebuilding it is blocked by cargo-binstall failing to reach index.crates.io (403 on api.github.com/graphql through the proxy), and the labs jest workspace needs the labs-use-local marker commit that rebuild would produce. labs-patches/bootstrap.sh check passes on all 17 patches; the rest is CI's.

---

Created by claudebox · group: slackbot · requested by Mike (@iAmMichaelConnor) · Slack thread

[AztecBot]

Closing as redundant. Everything on this branch is on next: #25521 was squash-merged as a36ddcc1c4c carrying labs patches 0015–0017, including the handshake-registry fixture (0x1866b3a2…f2c4) that this PR added on top of @spalladino's #25622. The change is also on v6 via #25624.

---

Created by claudebox · group: slackbot · requested by Mike (@iAmMichaelConnor) · Slack thread