Storage Proofs

Summary

The scrvUSD oracle's price smoothing mechanism relies on standard Unix timestamps via block.timestamp, but Neon EVM uses Solana slot numbers
instead of Unix time. This causes prices to smooth approximately 2.5x faster than intended on Neon compared to other EVM chains, breaking cross-
chain consistency requirements

Vulnerability Details

the _smoothed_price function calculates the maximum allowed price change based on the time elapsed since the last update:
https://github.com/CodeHawks-Contests/2025-03-curve/blob/main/contracts/scrvusd/oracles/ScrvusdOracleV2.vy#L155-L164

this issue happens when the calculation of max_change
where the system uses the difference between the current block.timestamp and self.last_update to determine how much time has elapsed, and consequently, how much the price is allowed to change.
EVM chains Ethereum, Arbitrum etcc use Unix time where:block.timestamp returns seconds since epoch(time increments at 1 second per second)

However, Neon EVM behavess differently block.timestamp returns Solana slot numbers Solana slots increment approximately every 400ms (2.5 slots per second)
When calculating (block.timestamp - self.last_update) on Neon, the difference will be 2.5x larger than on standard EVMs for the same time period. This directly affects the max_change calculation, causing price smoothing to move significantly faster on Neon than other chains.

Impact

Inconsistent Price Smoothing - with Neon prices potentially adjusting 2.5x faster than on other chains.

Broken Cross-Chain Consistency- The primary goal of thiss oracle is to provide consistent scrvUSD pricing across chains, but this issue creates systematic differences.

Tools Used

Manual code review

Recommendations

apply a normalization factor (divide by ~2.5) for Neon timestamp calculations