Skip to content

Latest commit

 

History

History
30 lines (20 loc) · 2.27 KB

051.md

File metadata and controls

30 lines (20 loc) · 2.27 KB

Cheerful Taffy Dolphin

Medium

Strict Oracle Timestamp Equality Check Triggers Unnecessary VaultCurrentOutOfSyncError Due to Network Latency

Summary

The Vault contract implements strict timestamp equality checks to ensure synchronized oracle data across all registered markets. While synchronization is necessary for security, the current implementation's rigid requirements create operational challenges in real-world distributed environments. This analysis examines how excessive timestamp matching requirements lead to system failures and proposes architectural improvements to balance security with operational reliability.

The vulnerability arises from an overly rigid timestamp equality check in the vault's _loadContext function:

https://github.com/sherlock-audit/2025-01-perennial-v2-4-update/blob/main/perennial-v2/packages/vault/contracts/Vault.sol#L512

if (context.currentTimestamp == type(uint256).max) context.currentTimestamp = currentTimestamp;
else if (currentTimestamp != context.currentTimestamp) revert VaultCurrentOutOfSyncError();

This implementation requires exact timestamp matching across all oracle status calls. When processing oracle data through registration.market.oracle().status(), even minimal timestamp variations trigger a VaultCurrentOutOfSyncError, halting vault operations.

The issue manifests in distributed oracle networks where update propagation isn't instantaneous. Consider a scenario where Market A receives an oracle update at t=1000000 and Market B at t=1000001 - a mere 1ms difference causes the entire transaction to revert. This strict synchronization requirement fails to account for inherent network latency and blockchain-specific timing variations.

The problem compounds in cross-chain environments where clock drift becomes inevitable:

(OracleVersion memory oracleVersion, uint256 currentTimestamp) = registration.market.oracle().status();

Each oracle call may encounter slightly different network conditions or blockchain timestamps, creating race conditions during near-simultaneous updates. The first oracle sets currentTimestamp, but subsequent reads within the same block may capture newer timestamps, forcing unnecessary reverts despite prices being current and valid.

Fix

Incorporate timestamp tolerance.