Skip to main content
Every on-chain price update costs gas. Updating too frequently wastes relayer resources and increases costs for the protocol. Updating too infrequently leaves stale data on-chain and exposes consuming protocols to risk. IFÁ Labs resolves this tension with a hybrid trigger model — combining deviation-based and time-based conditions calibrated specifically for stablecoin behavior. Understanding this model is important for anyone building protocols that consume IFÁ Labs feeds — particularly when setting staleness thresholds and designing fallback logic.

The Two Trigger Conditions

A price update is submitted on-chain when either of the following conditions is met:

Condition 1: Deviation Trigger

The new aggregated price deviates from the current on-chain value by more than the configured deviation threshold.
When this condition fires, it means the market has moved meaningfully enough to warrant an update — regardless of how recently the last update occurred.

Condition 2: Heartbeat Trigger

The time elapsed since the last on-chain update exceeds the configured heartbeat interval — the maximum allowed time between updates.
When this condition fires, it means too much time has passed without an update — even if the price hasn’t moved. This guarantees that lastUpdateTime never becomes indefinitely stale during periods of perfect market stability.

How They Work Together

The result: updates fire exactly when they should — when the price moves or when enough time has passed — and never more often than necessary.

Per-Asset Configuration

Deviation thresholds and heartbeat intervals are configured independently per asset. A single global setting would be either too tight for some assets or too loose for others.
These values represent the current configuration and may be adjusted as the network matures and empirical update data informs calibration. Follow @ifalabs for announcements of threshold changes.

Why These Thresholds Matter for Protocol Developers

Setting Your Staleness Threshold

Your protocol’s MAX_PRICE_AGE staleness check needs to account for the heartbeat interval of the assets you’re consuming. If you set MAX_PRICE_AGE tighter than the heartbeat interval, your protocol will frequently reject valid, accurate prices simply because the market hasn’t moved enough to trigger a deviation update.
The 1.5x buffer accounts for:
  • Minor delays in relayer submission during network congestion
  • Block timestamp variance
  • The time between the heartbeat condition being met and the transaction being mined
Starting at 2x the heartbeat interval and tightening based on observed update patterns in production is the safest approach.

Reading Update Cadence From On-Chain Data

Before setting staleness thresholds, observe the actual update cadence for your target asset in production. The PriceUpdated event log is the authoritative source:
Run this script against each asset you consume before finalising your staleness threshold configuration. The longest observed interval multiplied by 1.5 is a reliable starting point.

Deviation Trigger Mechanics in Detail

What Counts as a Deviation

The deviation calculation compares the new aggregated price against the current on-chain stored value — not the previous aggregation round’s result. This distinction matters:
The deviation is always measured against the last submitted on-chain value. This means small moves that individually fall below the threshold can accumulate and eventually trigger an update when the total drift from the last on-chain value exceeds the threshold.

Deviation vs. Peg

The deviation trigger fires on movement relative to the last on-chain price — not relative to the $1.00 peg. These are different things:
Protocols implementing peg deviation circuit breakers should check the price against the $1.00 peg directly — not rely on the oracle’s deviation trigger logic for that protection. See Verify Price Integrity for circuit breaker implementation.

Heartbeat Trigger Mechanics in Detail

The Purpose of the Heartbeat

Without a heartbeat trigger, a stablecoin that sits perfectly at its peg for days would never update. lastUpdateTime would grow indefinitely stale, and any protocol with a reasonable staleness check would start rejecting the price — even though the price is accurate. The heartbeat prevents this by guaranteeing a maximum gap between updates regardless of price movement.

Heartbeat Jitter

In practice, heartbeat updates do not fire at perfectly regular intervals. Several factors introduce jitter:
  • Gas price variability — relayers may delay submission slightly during high gas periods to minimise costs
  • Block time variability — the exact block in which a transaction lands varies
  • Aggregation round timing — the heartbeat condition is evaluated per aggregation round, not continuously
Jitter is typically small — seconds to a few minutes — but it is the reason your MAX_PRICE_AGE should include a buffer above the nominal heartbeat interval rather than matching it exactly.

Deviation and Heartbeat in Monitoring

When building off-chain monitoring for IFÁ Labs feeds, the trigger model informs what alert thresholds are meaningful:

Summary


Next Steps

Decimal Precision & Formatting

Learn how IFÁ Labs scales and formats price data for on-chain consumption.

Handle Stale Data

Implement staleness guards informed by the trigger model documented here.