The constructor grants the SIGNING_ROLE to the deployer but does not grant the DEFAULT_ADMIN_ROLE. This prevents the use of standard OpenZeppelin AccessControl functions, such as direct grantRole() and revokeRole() calls, creating inconsistency with expected patterns and violating the protocol's intended behaviour according to the documentation in README.md, which states:
Automatically receives both the OpenZeppelin DEFAULT_ADMIN_ROLE and the custom SIGNING_ROLE, becoming the first signer.
Likelihood:
Missed in the constructor, this has an effect throughout the contract's life until such a mistake is uncovered.
Impact:
Cannot use grantRole(SIGNING_ROLE, account) directly
Cannot use revokeRole(SIGNING_ROLE, account) directly
Forces use of custom grantSigningRole / revokeSigningRole
Inconsistent with OpenZeppelin patterns
Low severity since custom functions exist
Add this snipped of code to the MultiSigTimelockTest.t.sol test file.
How to execute:
Add _grantRole(DEFAULT_ADMIN_ROLE, msg.sender) to the contract constructor.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.
The contest is complete and the rewards are being distributed.