The Standard

Summary

There are general inconsistencies and deviations from the Solidity Style Guide throughout the codebase. These lead to misconceptions and confusion when reading the code.

Vulnerability Details

Below is a non-exhaustive list of inconsistent coding styles observed:

• On the LiquidationPool contract, manager and tokenManager global state variables could be declared as immutable.

• On the LiquidationPool contract, the function stake() suggests that it could be used to perform some kind of staking. Consider improving the naming to something like getPositionStake() or getStakeByPosition().

• On the LiquidationPool contract, the function empty() suggests that it could be used to empty something. Consider improving the naming to something like isEmpty().

• On the SmartVaultManagerV5 contract, some functions have the onlyOwner modifier without parenthesis and some with it. Consider unifying it.

• On the SmartVaultV3 contract, the constants version and vaultType are not in uppercase. Consider changing them to: VERSION and VAULT_TYPE respectively.

• On the SmartVaultV3 contract, in the constructor, the order of the arguments and assignments is not consistent. Consider assigning first the manager and later owner.

Impact

The inconsistencies detailed above could lead to misconceptions and confusion when reading the code.

Tools Used

Manual Analysis.

Recommendations

Consider enforcing a standard coding style, such as that provided by the Solidity Style Guide, to improve the project’s overall legibility. Also consider using a linter like Solhint or Forge fmt to define a style and analyze the codebase for style deviations.