The SDLPoolPrimary contract has a critical design flaw related to the static nature of the delegatorPool address, which poses a risk for future migration processes, especially when the ccipController is updated or if the delegatorPool is initially set to zero.
The vulnerability stems from the contract's inability to update the delegatorPool address post-initialization. During the initialization phase, the delegatorPool is conditionally set but lacks a mechanism for subsequent updates. This static approach becomes problematic when the ccipController (linked to the delegatorPool) is updated to a new address or the ccipController has zero address on the initializer function, as the delegatorPool remains unchanged, leading to potential discrepancies.
This limitation hinders the contract's ability to effectively migrate stakes if the ccipController changes, as the migration process relies on the delegatorPool address. The lack of flexibility to update this address can lead to operational challenges and may compromise the security and functionality of the contract in the future.
Manual Review
Implement a function to update the delegatorPool address, ensuring it remains synchronized with the ccipController. This update mechanism should include necessary checks and validations to maintain contract integrity. Additionally, consider initializing the delegatorPool explicitly in all scenarios to avoid issues when it is set to zero initially.
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.