# Inconsistent Precision of Percentage Variables Low/Info · Three Sigma · RWA perpetuals DEX · 19th February, 2024 Finding 3S-OS-N04 of the Ostium security review. - Protocol: https://www.ostium.com/ - Report: /reports/ostium - Source: https://cdn.sanity.io/files/qoqld077/production/a95b9c69e0f65d1d6b0e649f0d62a362358ca8ce.pdf --- ### Description Throughout the codebase, variables representing percentages maintain a precision of 2 decimal places. However, there are instances where this precision is not consistently applied: - The MAX_GAIN_P variable on [L31](https://github.com/0xOstium/smart-contracts-threeSigma/blob/1b70cffbac621d39e321c159e45c048b703add92/src/OstiumTradingCallbacks.sol#L31) in OstiumTradingCallbacks. - The maxSl_P variable on [L47](https://github.com/0xOstium/smart-contracts-threeSigma/blob/1b70cffbac621d39e321c159e45c048b703add92/src/OstiumTradingCallbacks.sol#L47) in OstiumTradingCallbacks. - The liqThresholdP variable in OstiumPairInfos. - The liqFeeP variable of the Fee struct in OstiumPairsStorage. ### Recommendation It is advisable to review the contracts and ensure that variables representing percentages consistently adhere to a precision of two decimal places. ### Status Acknowledged --- Related findings: - [`FluidLocker::_getUnlockingPercentage()` divides before multiplying, suffering a significant precision error](https://0xsimao.com/findings/superfluid-locker-system-unlocking-multiplying-suffering-precision): Superfluid Locker System