LendingPool Static Analysis Findings

LPL-01S: Inexistent Visibility Specifier

Type	Severity	Location
Code Style		LendingPool.sol:L22

Description:

The linked variable has no visibility specifier explicitly set.

Example:

Copy
22ILendingPoolConfig lendingPoolConfig;

Recommendation:

We advise one to be set so to avoid potential compilation discrepancies in the future as the current behaviour is for the compiler to assign one automatically which may deviate between pragma versions.

Alleviation (4325253d6de0ea91c1e9fb9e01d2e7e98f3d83a9):

A public visibility specifier has been introduced to the referenced variable, addressing this exhibit's concerns.

LPL-02S: Literal Equality of bool Variables

Type	Severity	Location
Gas Optimization		LendingPool.sol:L175, L188, L212, L414, L424

Description:

The linked bool comparisons are performed between variables and bool literals.

Example:

Copy
175require(borrowers[msg.sender].approved == true, "Borrower not approved");

Recommendation:

We advise each bool variable to be utilized directly either in its negated (!) or original form.

Alleviation (4325253d6d):

Of the referenced boolean equality comparisons all but the second one have been replaced by the bool values being compared themselves, rendering this exhibit partially alleviated.

Alleviation (7c9b2b09db):

The final remaining bool literal comparison has been updated as well, rendering this exhibit fully alleviated.

LPL-03S: Inexistent Sanitization of Input Addresses

Type	Severity	Location
Input Sanitization		LendingPool.sol:L76-L90

Description:

The linked function(s) accept address arguments yet do not properly sanitize them.

Impact:

The presence of zero-value addresses, especially in constructor implementations, can cause the contract to be permanently inoperable. These checks are advised as zero-value inputs are a common side-effect of off-chain software related bugs.

Example:

Copy
76constructor(
77  string memory _name,
78  string memory _symbol,
79  address _asset,
80  bool _isNativeAsset,
81  uint256 _protocolFee,
82  ILendingPoolConfig _lendingPoolConfig,
83  address _treasury
84  ) ERC20(_name, _symbol) {
85    asset = _asset;
86    isNativeAsset = _isNativeAsset;
87    protocolFee = _protocolFee;
88    lendingPoolConfig = _lendingPoolConfig;
89    treasury = _treasury;
90}

Recommendation:

We advise some basic sanitization to be put in place by ensuring that each address specified is non-zero.

Alleviation (4325253d6de0ea91c1e9fb9e01d2e7e98f3d83a9):

The constructor of the LendingPool implementation adequately sanitizes its address input arguments in the latest implementation, ensuring that the contract cannot be misconfigured during its deployment.

LPL-04S: Potential Lock of Native Assets

Type	Severity	Location
Language Specific		LendingPool.sol:L486

Description:

The linked receive / fallback function performs no sanitization as to its caller and no function within the contract expects funds to have been received directly by the contract.

Impact:

Any native funds accidentally sent to the contract may be forever locked.

Example:

Copy
486receive() external payable {}

Recommendation:

We advise the code to properly prohibit accidental native assets from being permanently locked in the contract by introducing a require check restricting the msg.sender to the contract(s) expected to transfer assets to the system (i.e. in case of a wrapped native version of an asset, only the WXXX contract address should be allowed). Alternatively, if the contract is not expected to receive native assets directly the function should be removed in its entirety.

Alleviation (4325253d6de0ea91c1e9fb9e01d2e7e98f3d83a9):

The receive function was updated to only accept native funds when the pool has been set to isNativeAsset mode, ensuring that funds cannot be locked within it when the pool's token is an EIP-20 asset. As a result, we consider this exhibit adequately alleviated.