🕐Inconsistent or Absent Price Data Fetching/Updating Intervals

Book an audit with Zokyo

Description: Protocols relying on the latest price data for various operations might be at risk if they do not consistently update their price oracles or if they set the price without regular checks. Inaccurate or outdated price information can be maliciously exploited to gain undue advantage, leading to potential losses.

Illustrative Vulnerabilities and Mitigations:

1. Outdated Price Per Share

   • Vulnerability: If a protocol relies on an externally run function to update its pricePerShare, and for some reason that function doesn't run (e.g., network issues, bugs, etc.), the contract's pricePerShare remains outdated. Malicious users can mint tokens at this outdated price and then burn them at the updated price for risk-free profit.

   • Mitigation: It's advised to implement a threshold for the maximum time elapsed since the last price update. Introduce two versions of transfer functions: one that checks for the staleness of the price and another that updates the price if it's stale. This ensures that the price is always updated, and transfers based on stale prices can be reverted or corrected.

2. Static Update Period in TWAP Oracles

   • Vulnerability: Time-Weighted Average Price (TWAP) oracles that update at fixed intervals might not accurately reflect the price of volatile assets. If the update period is constant and cannot be changed post-deployment, it might expose the protocol to price manipulations or mispricings.

   • Mitigation: Allow the owner or governance mechanism to update the updatePeriod. This provides flexibility in adjusting the update frequency based on the volatility or risk profile of an asset. However, it's crucial to implement checks ensuring that the update period doesn't become too short, exposing the protocol to manipulation, or too long, causing outdated prices.

General Recommendations:

• Regular Price Checks: Always ensure that price oracles or external data sources are checked and updated at regular intervals. The frequency should be balanced based on the asset's volatility and the operational needs of the protocol.

• Fallback Mechanisms: In case primary price-fetching mechanisms fail, consider having secondary or fallback methods to ensure continued access to updated price data.

• Thresholds and Alerts: Implement thresholds for data staleness. If data isn't updated within a specific timeframe, either revert the operation or trigger alerts for manual intervention.

• Governance Mechanisms: For protocols that rely heavily on price data, consider incorporating governance mechanisms that allow parameter adjustments, like update intervals, based on real-time requirements.

• Audit and Monitor: Continuously audit and monitor price-fetching mechanisms. Anomalies in price updates can provide early warnings about potential vulnerabilities or attacks.

By ensuring that the protocols have the most recent and accurate price data and by adding the ability to adjust parameters based on real-world conditions, vulnerabilities and potential exploits can be significantly reduced.