Root + Impact

Impact

Medium

• Stale oracle prices may remain trusted longer than intended

• Valid oracle responses may incorrectly revert

• Collateral valuation can become inaccurate

• Liquidation timing may become unreliable

---

Likelihood

Medium–High

• Different Chainlink feeds naturally use different heartbeat intervals

• The issue occurs during normal operation

• No attacker permissions or special setup required

Description

The protocol validates oracle freshness using a single globally fixed timeout:

Whenever price data is requested, the protocol checks:

If the timeout is exceeded, the transaction reverts and the price is considered stale.

The issue is that all collateral assets share the same timeout assumption, despite different oracle feeds having different heartbeat/update expectations.

Some Chainlink feeds update more frequently than others depending on:

• asset volatility

• liquidity profile

• feed configuration

• heartbeat settings

Using one hardcoded timeout for every asset introduces inconsistent oracle validation behavior.

---

Vulnerability Details

Current implementation:

applies equally to:

However, oracle feeds are not standardized to a single update cadence.

As a result:

Scenario A — Stale prices trusted too long

A feed intended to update frequently experiences delayed updates.

The protocol still accepts pricing data for up to 72 hours, even though the feed may already be economically stale.

During volatile markets:

This can distort:

• health factor calculations

• liquidation eligibility

• minting limits

---

Scenario B — Valid prices incorrectly rejected

A slower-updating collateral feed behaves according to its intended heartbeat.

However, if its normal update cadence exceeds protocol expectations, the system unnecessarily reverts:

This can interrupt:

• deposits

• minting

• liquidation

• redemption

even when the oracle behaves correctly.

Risk

Likelihood

• Different Chainlink feeds inherently have different heartbeat configurations

• The protocol explicitly supports replacing collateral assets

• Forked deployments increase the probability of incompatible timeout assumptions

Impact

• Stale pricing may remain trusted

• Correct oracle updates may be rejected

• Liquidation timing becomes unreliable

• Protocol risk assumptions degrade

Proof of Concept

Assume the protocol is forked to support multiple collateral assets with different Chainlink feed configurations.

Asset A updates every hour.

Asset B updates every 24 hours.

Both assets are forced into:

Case 1 — High-volatility asset

Asset A experiences rapid price movement, but oracle updates stop.

The protocol continues accepting the last known price for up to 72 hours.

During this period:

1. User deposits collateral

2. Asset price drops significantly

3. Health factor still uses stale valuation

4. User remains solvent longer than intended

5. Liquidation occurs too late

---

Case 2 — Different feed cadence

Asset B follows a slower heartbeat design.

The protocol incorrectly treats expected feed timing as stale:

This unnecessarily blocks protocol functionality despite valid oracle behavior.

Recommended Mitigation

Replace the global timeout constant with per-feed configurable heartbeat validation.

Instead of:

store timeout values per collateral asset:

and validate each oracle using its expected heartbeat configuration.

Example approach:

• WETH/USD → shorter timeout

• WBTC/USD → asset-specific timeout

• future collateral → configurable at deployment

Additionally:

• validate feed heartbeat during deployment

• emit events when stale thresholds are exceeded

• include tests for mixed-feed timing behavior

This ensures oracle freshness assumptions match actual feed design rather than relying on a universal constant.