Thank you @Entreprenerd for your thorough review and the time you’ve dedicated to auditing these payloads. Your commitment and detailed feedback are deeply appreciated.
Any modifications to permission payloads must be approached with utmost diligence and transparency. This ensures the DAO can maintain confidence in the integrity and reliability of all executed transactions.
Below, we address each of the points you’ve raised:
-
“0xcf4fF1e03830D692F52EB094c52A5A6A2181Ab3F not present on mainnet, there’s a different signer between the two chains”.
Great catch — thanks for flagging this.
This is a signer set change that has indeed been implemented on Ethereum Mainnet, and is currently in queue for Gnosis Chain. We’re coordinating its execution with Maxis.
-
“Can you please provide us with a tool that would allow us and the public to determine the exact scopes and limitations for the roleKey: 0x4d414e4147455200000000000000000000000000000000000000000000000000”
The Zodiac Roles UI has become a central part of our migration to Roles V2, as outlined in BIP-667.
You can use the following link to inspect the live, on-chain permissions currently assigned to the Manager Roles Module.
Where:
- 0x13c61a25DB73e7a94a244bD2205aDba8b4a60F4a is the Roles V2 contract instance.
- 0x4d414e4147455200000000000000000000000000000000000000000000000000 corresponds to the Manager Role key, assigned to the Manager Safe. (Note: You can use a Hex-to-Text decoder (e.g. this one) to convert the Role Key into its ASCII representation, which is; “MANAGER”).
- All permissioned target contracts, their function selectors, and scoped parameters should be available for anyone to verify.
-
“The Payload seems to set a default role and then assign the same role, is this necessary?”
As you rightly pointed out—and as outlined in the architecture flowchart—we’ll deploy a Sub-Roles Module with its Role Key set to match the Manager Role Key (0x4d414e4147455200000000000000000000000000000000000000000000000000).
The key distinction is that ownership of this Sub-Role Module will be assigned to the Manager Safe. This design ensures that any nested roles created within the Sub-Role Module remain fully scoped and cannot exceed the permissions defined in the MANAGER Roles Module.
-
“We Recommend reviewing old roles contracts and possibly deprecating them”.
To keep things clean and consistent, we’ll queue the removal of the Manager Role V1 from the Managed Treasury and coordinate its execution with the Maxis.
-
“MultisendUnwrapper seems to allow you to perform any arbitrary call”.
The MultiSendUnwrapper enables the Roles contract to decode and evaluate each call within a batched transaction, such as those sent through the
multiSend(bytes)function. This allows complex actions—like “claim, wrap, and send”—to be permission-checked individually, even when bundled into a single transaction.
You’ll find more about this function in the Zodiac Roles documentation.