The QuantAMM protocol's packing and unpacking mechanism in QuantAMMStorage.sol
exhibits systematic precision loss when handling decimal values. The issue occurs during the pack/unpack cycle and affects both positive and negative numbers, leading to value truncation and potential loss of funds in extreme cases.
The protocol's fixed-point arithmetic implementation in these operations:
Truncates values below certain precision thresholds
Loses precision in least significant digits
Completely drops sub-unit values in certain scenarios
This is particularly concerning because:
The loss is systematic and affects all operations
It compounds over multiple operations
It disproportionately affects smaller values
It can lead to asymmetric rounding in negative values
The precision loss has several implications for the protocol:
Value Misrepresentation
Original values are not accurately preserved after pack/unpack cycles
Example: 13.421772700000000
becomes 13.421772000000000
(loss of 0.000000700000000
)
Asymmetric Treatment of Negative Values
Negative values lose precision differently than positive ones
Example: 4.200000000
becomes 4.000000000
(loss of 0.200000000
)
Complete Loss of Sub-unit Values
Values below certain thresholds are completely lost
Example: 0.999999999
becomes 0.000000000
(complete loss)
Cumulative Effects
In token operations: 1000.123456789000000
tokens become 1000.123456000000000
Loss compounds over multiple operations
Affects pool share calculations and user balances
Running this test demonstrates the precision loss:
Consider implementing one of the following solutions:
Increase the precision of the internal representation
Add rounding mechanisms instead of truncation
Implement a compensation mechanism for lost precision
Store additional precision bits in unused bit spaces
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.