The constructor’s NatSpec documentation claims that the provided admin address receives “all roles” in the TimelockController. However, the constructor only grants the DEFAULT_ADMIN_ROLE, EMERGENCY_ROLE, and CANCELLER_ROLE to the admin, omitting explicit assignment of the PROPOSER_ROLE and EXECUTOR_ROLE. This discrepancy can lead to situations where the admin does not have full control over scheduling and executing operations as might be expected from the documentation.
In the TimelockController contract’s constructor, the following role assignments are made:
The NatSpec comment above the constructor states:
However, the PROPOSER_ROLE and EXECUTOR_ROLE are not granted to the admin by default. As a result, the admin will not be able to schedule new operations (PROPOSER_ROLE) or execute queued operations (EXECUTOR_ROLE) unless those roles are granted separately. This may lead to confusion or operational issues during governance and timelock processes, as the expected “all roles” are not fully assigned to the admin.
If the admin assumes that they have full control over the timelock operations, they may be unable to schedule or execute proposals without additional role assignments. This oversight could lead to delays in governance execution or overall administrative confusion in managing protocol timelock operations.
Manual Review
To align the implementation with the NatSpec comment and expected behavior:
Grant the PROPOSER_ROLE and EXECUTOR_ROLE to the admin in the constructor:
Alternatively, update the NatSpec documentation to accurately reflect the roles that are assigned by default.
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.