PUR #10: revised execution
PUR #10, as reviewed by Blockful, has been modified in execution only: rather than applying the permission changes to the existing Zodiac Roles module, the proposal now swaps the Endowment to a new Roles module. The swap permanently resolves a security issue that was previously identified and mitigated.
The new module ships with the PUR #10 permissions already applied as reviewed. This combines the security fix and the permissions update into a single batch, with no change to the permissions themselves.
Why the Main is being replaced
Two reasons, and a single swap settles both.
- A patched version of the module: every Roles Modifier runs on a shared implementation contract (its “mastercopy”). The current Main runs v2.1.0, the version flagged in a security disclosure earlier this year and the same Zodiac Roles component involved in the June 2026 Gnosis Pay incident. The Endowment’s exposure is limited because the affected behaviour isn’t reachable with the current
MANAGERpermissions, and an interim safeguard is already in place. Still, the correct permanent fix is to move off v2.1.0. The new Main runs the patched v2.1.1. - Transaction batching: batched actions are routed through a helper contract (MultiSend), and a Roles Modifier only accepts the MultiSend versions registered on it. The current Main accepts only the older version (1.3.0), while PUR #10’s Sub-Roles Modifier uses the current one (1.4.1). Once the Sub is live, every transaction passes through the Sub and then the Main, so the old Main and Sub would have no common MultiSend version and batches would revert. The new Main registers the current version on both required entrypoints, so batching works end to end.
1. The switch payload, ENS_Switch_ZRM.json
A single batch of two transactions, signed by the Endowment Safe:
disableModuleon the current Main,0x703806E61847984346d2D7DDd853049627e50A40enableModuleon the new Main,0xa23BEBFD3628D6Dd7B0638c147db11d9B6FaBD59, already fully configured, Sub included
That is the whole of PUR #10 on ENS’s side: no further transactions and no additional signatures.
2. The diff page, ens-main-zrm-compare-eth.html
The diff compares the current Main against the new one. The differences are exactly the permissions requested in PUR #10 and nothing else. The new Main reproduces the live MANAGER policy as it stands today, plus the PUR #10 additions.
The swap payload and the diff are the two deliverables we are submitting for a second round of Blockful verification. They supersede ensPermissionsUpdate10.json, which is no longer the artefact to review.
On the Sub-Roles Modifier
PUR #10 originally carried the Sub-Roles setup inside its payload. That is now folded into the preconfiguration we deliver. The Sub is redeployed at a new deterministic address, 0x48dC0d88766a59E119e3f2585BC1dC5436Ee6ce0, replacing 0xa5dd28EC9C69627A96202897b35B88827854bd3b from the original payload. It is wired to the new Main and granted the MANAGER role during preparation, so it needs no separate setup step after the swap and still requires no extra signature from ENS.
The new Main is deployed on v2.1.1 and configured with the current policy, the PUR #10 additions, the members, both 1.4.1 MultiSend entrypoints (MultiSend and MultiSendCallOnly), and the Sub. The setup is verified on-chain.
A plain-English version of the permissions added are available in our original specification
The one step remaining on our side
This payload is pending review from Blockful. Once reviewed with no issues found, we will forward the payload to the ENS Foundation for final review and execution.