Bloq

The ERC20 approve() function creates the potential for an approved spender to spend more than the intended amount. It is possible to perform a frontrunning attack, enabling an approved spender to call transferFrom() both before and after the call to approve() is processed. While there is no proper solution to this issue implemented into the standard, there are multiple workarounds that may or may not sacrifice backwards compatibility.

The function liquidate() is meant to be used to liquidate unhealthy debt positions of other users. Whenever a position is unhealthy, this function makes a call to quoteLiquidateOut() to determine the amount of processing fees. As an example, we can suppose the processing fees are as follows.amountToRepay_ / _toLiquidator = 100 _protocolFee = 10% _liquidatorIncentive = 0%After the function quoteLiquidateOut() is executed, it will return the following values:_toLiquidator = 100 _fee = 10 _totalToSeize = 110Since the account of the unhealthy position is paying the liquidation fees, the user of said account must possess a balance of deposit tokens greater than his actual debt. This factor is controlled by the collateralFactor variable. In order for the debt to be repaid in full, the collateralFactor needs to allow for a sufficient margin that should be greater than the fees paid during the liquidation process.However, this fact is not guaranteed in the code. Not only can the collateralFactor variable range from 0% to 100%, but also the total percentage of liquidation fees is never checked if it is smaller than the current collateralFactor. This may ultimately lead to the impossibility of liquidating unhealthy positions.

The smart contracts Manageable and Pauseable implement the same functionality and could be adapted to remove the inherent duplication of code. Avoiding code duplication makes the code more readable for the smart contracts' users and saves gas during deployment.

The LayerZero protocol specification requires that whenever cross-chain estimates are being made or messages being sent, the input parameter zroPaymentAddress should not be hardcoded. This is due to the fact that different chains may have different implementations of the zero address, and, as such, this variable should be passed in as an argument by the user, and should not be hardcoded.It should be noted that the impact for this finding is specific to the respective chains being included and implemented in the protocol.

The ERC165 is a community-wide standard that implements a method to publish and query whether contracts support specific interfaces and their respective version. It is therefore useful when interacting between contracts and to perform more secure validations between functions that are expected to be implemented by specific contract addresses. This is possible through the usage of the function supportsInterface(). It should be noted that while it is not guaranteed that the implementation of the external contract is legitimate, it is possible to ensure that the respective interface being used in the external call is correct.Throughout the code, several instances were found to be lacking the implementation and proper validation of address parameters that implement specific contracts. However, it should be noted that the specified list is not extensive.