Pool Static Analysis Findings

POO-01S: Improper Unit Conversion

Description:

The liquidity evaluation in the initial asset's decimal precision can cause rounding to occur and thus cause non-zero liquidity to be removed from an asset by burning zero liquidity from the other.

Example:

Copy
759uint256 liquidityInInitialAssetDP = (liquidity * 10**initialAsset.decimals()) / (10**wantedAsset.decimals());

Recommendation:

We a proper require check to be introduced mandating the liquidityInInitialAssetDP to be non-zero as otherwise liquidity can be removed from the system without actually reducing the liquidity of the initial asset.

Alleviation:

Liquidity conversion removal is now properly evaluated to be non-zero to prevent dust-liquidity withdrawals that result in no units being burned.

POO-02S: Improper Offset Evaluation

Description:

Tokens are not constrained to an 18 decimal maximum limit.

Example:

Copy
490// used to convert cash and liabilities into ETH_UNIT to have equal decimals accross all assets
491uint256 offset = 10**(18 - _getAsset(assetAddress).decimals());
492
493totalCash += (_getAsset(assetAddress).cash() * offset * tokenPrice);
494totalLiability += (_getAsset(assetAddress).liability() * offset * tokenPrice);

Recommendation:

We advise the offset to either properly evaluate an inverse offset value or the codebase to disallow tokens with more than 18 decimal places as otherwise the ratio system will cease functioning, affecting the protocol significantly.

Alleviation:

The Asset contract of the system mandates that the underlying token has at most 18 decimals, thereby preventing non-standard tokens from being accepted as valid trading pairs into the system and alleviating this exhibit.