Venus Protocol Isolated Pools - fatherOfBlocks's results

ExponentialNoError.sol

• L149 - Before doing the division, you should check that b is not 0 to handle the exception and not just that it occurs.

• L12/16 - Two structs are created: Exp and Double, which only have one variable inside, this is strange since the idea of ​​stucts is to group multiple variables in one concept.

BaseJumpRateModelV2.sol

• L141/158 - Before doing the division by (cash + borrows - reserves) it should be checked that it is not 0 to handle the exception and not just that it occurs.

ComptrollerInterface.sol

• The contract is called ComptrollerInterface and inside there are two interfaces: ComptrollerInterface and ComptrollerViewInterface, therefore the correct thing would be for the file to be called ComptrollerInterfaces.sol

RiskFund/ProtocolShareReserve.sol

• L18/19 - Two constants are created: protocolSharePercentage and baseUnit in storage, but they are never used, therefore it is an unnecessary expense in the deploy.

WhitePaperInterestRateModel.sol

• L96 - Before doing the division by (cash + borrows - reserves) it should be checked that it is not 0 to handle the exception and not just that it occurs.

VTokenInterfaces.sol

• L11/133 - The file is called VTokenInterfaces, but inside it contains a contract and an abstract, therefore, this is somewhat confusing when it comes to understanding the code. If you can't implement it with interfaces, you should change the file name to VTokenStorage, for example.

RiskFund/RiskFund.sol

• It is confusing that the name of the folder is RiskFund and that the file has the same name, the idea of ​​a folder is to group multiple contracts in the same idea and in this case that would not be fulfilled.

Rewards/RewardsDistributor.sol

• L420/422 - The _grantRewardToken() function has only two possible return values: 0 or amount. Therefore, it could be simplified by using bool.

Shortfall/Shortfall.sol

• L359 - The _startAuction() function has 75 lines of code and there are parts that have many operations together, therefore to improve the understanding of the code It would be beneficial to use helper functions with names that define what is done in that block of code.

RiskFund/RiskFund.sol

• L47 - The AmountOutMinUpdated event is created, but it is never used, therefore it generates unnecessary expense in the deploy.

• L83 - When the MaxLoopsLimit contract is initialized it is zero, therefore, in the MaxLoopsLimitHelper contract, Line 26 validates this: require(input > maxLoopsLimit, "Comptroller: Invalid maxLoopsLimit"); therefore it is not necessary to validate two times the same operation.

• L100/101/102/103/117/118/119/128/129/130/140/141/142 - Gas could be saved if instead of implementing it like this, it was done like this: example: require(_poolRegistry != address(0), "Risk Fund: Pool registry address invalid"); emit PoolRegistryUpdated(poolRegistry, _poolRegistry); poolRegistry = _poolRegistry;

Pool/PoolRegistry.sol

• L425/426/427/434/435/436 - Gas could be saved if instead of implementing it like this, it was done like this:

  emit NewShortfallContract(shortfall, address(shortfall_)); shortfall = shortfall_;

Lens/PoolLens.sol

• L164/165/179/180/193/194/512/513/532/533 - It is not necessary to create a variable in memory if it does not help to better understand the code and it is only used once, therefore at least expensive would be to use the operation directly where it is needed.

Comptroller.sol

• L707/708/709/785/788/791/915/916/917/964/965/966 - Gas could be saved if instead of implementing it like this, it was done like this: For example: emit NewPriceOracle(oracle, newOracle); oracle = newOracle;

• L1059/1061 - It is not necessary to create a variable in memory if it does not help to understand the code better and it is only used once, therefore the least expensive would be to use the operation directly where it is needed.

• L1214 - The calculation of the allMarkets length is performed for the second time, this is an unnecessary expense of gas, since the only line that is added after the operation in line 1206 is the push in L1214. Therefore you could directly execute _ensureMaxLoops(marketsCount + 1);

ErrorReporter.sol GO

• L7/9/10/12/15/19/23/29/32/37/39/42/51 - Multiple errors are created in the contract and are never used, therefore they should be eliminated, since they generate a unnecessary expense in the deploy.

MaxLoopsLimitHelper.sol GO

• L28/29/31 - Gas could be saved if instead of implementing it like this, it was done like this: example: emit MaxLoopsLimitUpdated(maxLoopsLimit, limit); maxLoopsLimit = limit;

ExponentialNoError.sol

• L22/23 - Two constants are created: halfExpScale and mantissaOne in storage, but they are never used, therefore it is an unnecessary expense in the deploy.

• L39/40 - It is not necessary to create a variable in memory if it does not help to better understand the code and it is only used once, therefore the least expensive would be to use the operation directly where it is needed.

RiskFund/ProtocolShareReserve.sol

• L55/56/57 - Gas could be saved if instead of implementing it like this, it was done like this: example: require(_poolRegistry != address(0), "ProtocolShareReserve: Pool registry address invalid"); emit PoolRegistryUpdated(poolRegistry;, _poolRegistry); poolRegistry = _poolRegistry;