Open hats-bug-reporter[bot] opened 1 month ago
As i see it's proxy contract, setup will not revert, it uses proxy storage which is different than DemurrageCircles storage.
Thank you for your report on the address initialization of hub in the DemurrageCircles Contract. After review, we've determined this is not an issue.
This concern indicates a misunderstanding of the proxy pattern and delegateCalls in our implementation. Our approach is correct and does not result in the scenario you've described.
We appreciate your examination of our contract initialization process. Thank you for your participation in this security review.
Github username: -- Twitter username: -- Submission hash (on-chain): 0x87c111e6f030bb2983ea81e3a166ab407f27c9ea72c773b78111b2f17053e8ef Severity: medium
Description: Description\ In the constructor of the
DemurrageCircles
contract, the hub variable is initialized to address(0x1), as seen here:This means that when the contract is first deployed, the hub is not the zero address but is instead set to address(0x1).
In the setup function, there is a check to see if the hub has already been initialized:
This check is comparing the hub address against address(0), but in the constructor, the hub is initialized to address(0x1). This causes an inconsistency because after deployment, the hub will already be address(0x1), meaning the setup function would immediately revert, preventing any further initialization.
Impact\ Since the hub is set to address(0x1) in the constructor, the setup function would always fail due to the mismatch in the hub address check. This makes it impossible to properly initialize the contract after deployment. If this issue goes unnoticed, any attempt to set up the contract would fail, potentially halting the system’s operation or requiring a redeployment with a fix.
Recommendation\ We have two options for this. Change the constructor to initialize the hub to address(0) or change the setup function to check if the hub is address(0x1) instead of address(0).