The AaveDIVAWrapper::constructor() incorrectly passes parameters to its mother contract, AaveDIVAWrapperCore::constructor(). Consequently, the AaveDIVAWrapper contract can be bricked after deployment.
The AaveDIVAWrapper::constructor() receives the _aaveV3Pool, _diva, and _owner as parameters and respectively passes them (see @1 in the snippet below) to its mother contract, AaveDIVAWrapperCore::constructor().
However, the AaveDIVAWrapperCore::constructor() (i.e., the mother contract) defines its parameters in a different order (refer to @2.1). Instead of receiving the aaveV3Pool_ and then diva_, it expects the opposite order.
Hence, the AaveDIVAWrapperCore::constructor() will eventually assign the immutable variables _diva and _aaveV3Pool erroneously (@2.2), rendering the AaveDIVAWrapper contract to be bricked after deployment.
In addition to the test script, we noticed that the setup() wrongly passes the parameters in the opposite order (@3) of the AaveDIVAWrapper::constructor()'s requirement.
This mistake makes the test script runnable, fortunately. That's the reason why the test script cannot detect this mis-implementation.
Note: this is not about the admin-input mistake issue but the incorrect implementation of the
AaveDIVAWrapper::constructor().
The impact is considered low (there are no direct financial problems, but the AaveDIVAWrapper contract cannot operate after deployment with the correct order of parameters).
The likelihood is high (if an admin deploys the contract by inputting arguments to the AaveDIVAWrapper::constructor() in the correct order, the issue will arise).
For this reason, this issue deserves a medium.
Manual Review
Improve the order of parameters of the AaveDIVAWrapper::constructor() to be consistent with that of the AaveDIVAWrapperCore::constructor(), as in the snippet below.
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.