Venus - ACM Commands Aggregator

The documentation provided state the following: "Normal Timelock contracts on each remote network will have the DEFAULT_ROLE in the AccessControlManager contract. So only Normal VIPʼs on BNB Chain (that will use the Normal Timelocks on the remote networks) will be able to complete the proposed plan, because no other timelock contract will be able to grant and revoke the DEFAULT_ROLE to/from the ACMCommandsAggregator." However, when reviewing the `AccessControlManager` contracts deployed on the remote networks, we noticed that in addition to the normal timelock having the `DEFAULT_ADMIN_ROLE` (if it is deployed), a multi-sign is also given the `DEFAULT_ADMIN_ROLE`. This allows for the `DEFAULT_ADMIN_ROLE` to granted and revoked to/from the ACMCommandsAggregator through a method other than normal VIPs. For example on Ethereum, the `AccessControlManager` contract is at address [0x230058da2D23eb8836EC5DB7037ef7250c56E25E](https://etherscan.io/address/0x230058da2D23eb8836EC5DB7037ef7250c56E25E) and the mutli-sign at address [0x285960C5B22fD66A736C7136967A3eB15e93CC67](https://etherscan.io/address/0x285960C5B22fD66A736C7136967A3eB15e93CC67) has the `DEFAULT_ADMIN_ROLE` along with the normal timelock at address [0xd969E79406c35E80750aAae061D402Aab9325714](https://etherscan.io/address/0xd969E79406c35E80750aAae061D402Aab9325714). Can you please confirm if the intention is to revoke the `DEFAULT_ADMIN_ROLE` from the multi-signs and when this action will take place.

Other files within the codebase include NatSpec comments for the title, author, and summary of the contract. However, `ACMCommandsAggregator` does not have such comments.

In the constructor, the input `_acm` is not checked to ensure it is not the zero address.