Storage Proofs
Curve
DeFiLayer 1Layer 2
14,723 OP
View results
Previous Next
Submission Details
Severity: low
Invalid

Inconsistent Price Precision Standards

maze

1. Summary

  • Severity: Low

  • Category: Data Validation/Precision

  • Impact: Integration complexity and potential calculation errors

  • Likelihood: Medium

2. Affected Code

MAX_BPS_EXTENDED: constant(uint256) = 1_000_000_000_000 # 10^12
# vs
max_price_increment: public(uint256) # precision 10^18

  • Contract: ScrvusdOracleV2.vy

  • Variables: MAX_BPS_EXTENDED, max_price_increment

  • Lines: 42, 73

3. Vulnerability Details

Root Cause

The contract uses different precision standards across its calculations:

  • MAX_BPS_EXTENDED uses 10^12 precision (1e12)

  • max_price_increment uses 10^18 precision (1e18)

  • Price calculations mix these precisions in various functions

Impact Scenarios

  1. Integration errors when other contracts assume consistent precision

  2. Potential for calculation errors in price adjustments

  3. Increased complexity in contract maintenance

  4. Higher gas costs due to additional precision conversions

4. Proof of Concept (PoC)

def test_price_precision_inconsistency(soracle):
# Calculate unlocked shares using MAX_BPS_EXTENDED (10^12)
unlocked = soracle._unlocked_shares(
full_profit_unlock_date=1000,
profit_unlocking_rate=10**12, # 1.0 in 10^12
last_profit_update=0,
balance_of_self=10**18, # 1.0 in 10^18
ts=500
)
# Calculate price change with max_price_increment (10^18)
price_change = soracle._smoothed_price(
10**18, # 1.0 in 10^18
2 * 10**18 # 2.0 in 10^18
)
# Demonstrates mixing of precisions
print(f"Unlocked shares precision: {len(str(unlocked))} digits")
print(f"Price change precision: {len(str(price_change))} digits")

5. Recommended Fix

Option 1: Standardize to 18 Decimals

MAX_BPS_EXTENDED: constant(uint256) = 1_000_000_000_000_000_000 # 10^18

Option 2: Add Precision Constants

PRECISION_BPS: constant(uint256) = 10**12
PRECISION_PRICE: constant(uint256) = 10**18
​
@view
def _normalize_precision(_value: uint256, _from: uint256, _to: uint256) -> uint256:
if _from == _to:
return _value
elif _from > _to:
return _value // (_from // _to)
else:
return _value * (_to // _from)

6. Severity Justification

Rated as Low severity because:

  1. No direct security vulnerability

  2. Calculations remain mathematically correct

  3. Impact limited to integration complexity

  4. Documentation notes precision differences

However, standardization would improve:

  • Code maintainability

  • Integration reliability

  • Gas efficiency

  • Readability

7. Recommended Best Practices

  1. Use consistent precision throughout the system

  2. Document precision requirements clearly

  3. Add helper functions for precision conversions

  4. Include precision checks in tests

  5. Consider standard industry practices (18 decimals)

Updates

Lead Judging Commences

0xnevi Lead Judge
3 months ago
0xnevi Lead Judge 3 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.