The Diamond contract of the protocol exhibits an inconsistency in its initialization checks. While it rigorously checks the _contractOwner
and _baseOracle
addresses against the zero address, it doesn't apply the same check to the _diamondCutFacet
address. Furthermore, a potential centralization concern exists in the governance model, contrasting the protocol's promise of decentralization.
constructor(address _contractOwner, address _diamondCutFacet, address _baseOracle) payable {
require(_contractOwner != address(0), "Diamond: owner can't be address(0)");
require(_baseOracle != address(0), "Base oracle can't be address(0)");
LibDiamond.diamondCut(cut, address(0), "");
}
However, the _diamondCutFacet address, crucial for Diamond pattern functionality, does not have a similar check.
Additionally, certain operations within the contract are restricted solely to the contract owner, which presents a centralization aspect:
modifier onlyDAO() {
LibDiamond.enforceIsContractOwner();
_;
}
## Impact
- The lack of an initialization check for `_diamondCutFacet` can lead to potential vulnerabilities and unintended behaviors in the protocol.
- The presence of a contract owner and operations limited to this owner suggests centralization, contradicting the protocol's promise of decentralization and censorship resistance.
## Tools Used
- Contract code analysis (manually).
## Recommendations
- To maintain consistency and avoid unexpected behaviors, introduce a validation check in the constructor for the `_diamondCutFacet` address. Ensure it is not the zero address before further initialization.
- Reevaluate the governance structure to align with the protocol's promise. Consider renaming "DAO" to "Diamond Contract Owner" or introduce a more decentralized governance model.