Fetching a price is one line of code. Using that price safely in production is a different responsibility entirely. Before any price feed data touches critical logic — liquidations, collateral valuations, minting, settlement — your contract needs to verify three things: the asset is supported, the price is recent, and the value is within a reasonable range. Skipping any of these is a security vulnerability, not a minor oversight. This page covers each check individually, then puts them together into a single production-ready verification function.Documentation Index
Fetch the complete documentation index at: https://docs.ifalabs.com/llms.txt
Use this file to discover all available pages before exploring further.
Check 1: Asset Existence
Always confirm the feed exists before using the returned data. A non-existent asset returns zero values withexists = false. If you skip this check and proceed, you’re executing logic against a price of zero.
Check 2: Staleness
Price data has alastUpdateTime timestamp. If that timestamp is too far in the past, the price may no longer reflect current market conditions — a depeg could have occurred and your contract wouldn’t know.
| Use Case | Recommended Threshold | Reasoning |
|---|---|---|
| Stablecoin lending / liquidations | 30 – 60 minutes | High stakes, needs freshness |
| Stablecoin swaps | 1 – 2 hours | Moderate risk tolerance |
| Analytics and dashboards | 4 – 6 hours | Read-only, lower risk |
| General stablecoin protocols | 2 hours | Safe starting point |
IFÁ Labs updates feeds on a hybrid deviation + time trigger model. During calm markets, stablecoins near their peg will update less frequently — this is by design, not an outage. Set your threshold based on your protocol’s actual risk tolerance, not the tightest possible value. Starting at 2 hours and tightening based on observed update patterns is the right approach.
Check 3: Peg Deviation
For stablecoin feeds, you know roughly what the price should be — close to $1.00. A circuit breaker that rejects prices beyond a reasonable deviation band protects your protocol against oracle manipulation, source failures, or genuine depeg events that require human intervention before automated logic runs.| Asset Type | Suggested Max Deviation | Notes |
|---|---|---|
| USD stablecoins (USDT, USDC) | 1 – 2% | Tight — these rarely move |
| Emerging market stablecoins | 3 – 5% | Slightly wider for local volatility |
| Reference assets (ETH) | Not applicable | Don’t use a peg check for non-pegged assets |
Full Verification Function
Combining all three checks into a single internal function you can call from anywhere in your protocol:Additional Recommendations
Fail closed, not open. If any check fails, revert. Do not fall through to a default value or proceed with stale data. A paused protocol is recoverable. A protocol that executed liquidations at a manipulated price is not. Make thresholds configurable. Hard-coded constants are fine for initial deployment, but consider a governance-controlled mapping of per-asset thresholds as your protocol matures. Different assets have different risk profiles. Implement a multi-oracle fallback. For high-value protocols, combining IFÁ Labs with a secondary oracle and taking the median eliminates single-oracle risk entirely. See Building Fallback Strategies for a production implementation. Monitor off-chain as well. On-chain checks protect your contracts. Off-chain monitoring alerts your team before a situation reaches the point of a revert. See Running Price Monitoring for a ready-to-use monitoring script.Next Steps
EVM Integration Guide
Build a complete production integration into your smart contracts.
Building Fallback Strategies
Layer IFÁ Labs with a secondary oracle for maximum protocol resilience.

