Omniscia Platypus Finance Audit
Pool Static Analysis Findings
Pool Static Analysis Findings
POO-01S: Improper Unit Conversion
Type | Severity | Location |
---|---|---|
Mathematical Operations | Major | Pool.sol:L759 |
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:
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
Type | Severity | Location |
---|---|---|
Mathematical Operations | Medium | Pool.sol:L490-L494 |
Description:
Tokens are not constrained to an 18
decimal maximum limit.
Example:
490// used to convert cash and liabilities into ETH_UNIT to have equal decimals accross all assets491uint256 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.