Why Data Integrity Requires Multiple Layers
A single protection layer creates a single point of failure. If IFÁ Labs relied only on source diversity, a coordinated multi-source attack could corrupt the feed. If it relied only on outlier filtering, a slow price drift from corrupted sources could pass undetected. If it relied only on on-chain validation, bad data signed by relayers would be accepted without question. The defense-in-depth model ensures that compromising the feed requires simultaneously defeating every layer — a significantly higher bar than defeating any one of them.Layer 1: Source Diversity
What it does: Distributes the trust surface across multiple independent data providers. No single source can determine the final aggregated price. How it works:- Prices are collected from multiple independent source categories — CEXs, DEXs, forex providers, and regional exchanges
- Sources are required to be genuinely independent — shared infrastructure or common ownership disqualifies sources from being counted separately
- A minimum number of independent sources must contribute to any submitted update
| Threat | Protection |
|---|---|
| Single source failure or outage | Remaining sources maintain feed continuity |
| Single source manipulation | One corrupted source cannot move the weighted median significantly |
| CEX-specific events | DEX and forex sources provide independent reference points |
| Global market vs. regional market divergence | Regional sources for emerging market assets reflect local reality |
Layer 2: Source-Level Validation
What it does: Validates every individual data point before it enters the aggregation pipeline. Bad data is rejected at the source level — it never reaches the aggregation stage. Checks applied per data point:| Threat | Protection |
|---|---|
| Stale API responses from a slow or degraded source | Timestamp check rejects data outside the aggregation window |
| Zero or negative price from a source error | Strict positive price guard rejects before aggregation |
| Malformed API response from a source outage | Format validation rejects incomplete data |
| Low-volume manipulated prices | Volume threshold prevents thin-market manipulation |
Layer 3: Outlier Detection and Removal
What it does: Identifies and removes data points that deviate significantly from the preliminary consensus — even if they passed source-level validation individually. How it works: A preliminary median is calculated from all validated data points. Any data point deviating beyond the configured threshold from this preliminary median is flagged as an outlier and removed from the final aggregation. Thresholds are calibrated per asset class:| Asset Class | Outlier Threshold | Rationale |
|---|---|---|
| USD global stablecoins (USDT, USDC) | Tight — 0.15–0.25% | Rarely move — any significant deviation is suspicious |
| Emerging market stablecoins (CNGN, ZARP, BRZ) | Moderate — 0.5–1.0% | Natural micro-fluctuations require slightly wider tolerance |
| Reference assets (ETH) | Wider — 1.0–2.0% | Non-pegged asset — wider range is appropriate |
| Threat | Protection |
|---|---|
| Single corrupt source reporting extreme price | Excluded as outlier before weighted median |
| Flash loan attack creating temporary price spike | Flash event filter removes sub-duration spikes |
| Coordinated manipulation from a minority of sources | Weighted median resists minority outliers by design |
Layer 4: Consensus Algorithm
What it does: Reduces the cleaned, validated data set to a single authoritative price using a manipulation-resistant algorithm. Weighted median — the primary mechanism: The weighted median is the central value in a distribution when data points are sorted by price and weighted by source quality. Unlike a simple average, the median is inherently resistant to extreme values — even if several sources report a manipulated price, the median remains anchored to the majority honest data as long as honest sources represent more than 50% of the total weight.Layer 5: Pre-Submission Validation
What it does: Applies a final validation gate to the aggregated price before it is passed to relayers for signing and submission. Checks applied: Zero-price guard (post-audit fix): The aggregated price must be strictly greater than zero. A zero aggregated price — which could occur if all valid sources reported zero due to a catastrophic data failure — is rejected. This prevents division-by-zero errors in derived pair calculations that consume the feed. Peg bounds check: For stablecoin feeds, the aggregated price must fall within a configured range of the expected peg. A price outside this range is flagged and withheld from submission pending investigation — it may represent a genuine depeg event requiring human review before automated submission resumes.| Threat | Protection |
|---|---|
| Catastrophic data failure producing zero price | Zero-price guard rejects before submission |
| Genuine depeg event triggering automated liquidations | Peg bounds check withholds submission for human review |
| Insufficient source diversity in a given round | Minimum source threshold prevents underpowered submissions |
Layer 6: Decentralized Relay
What it does: Ensures no single entity controls price submission to the on-chain contract. How it works:- Multiple independent relayers receive the validated aggregated price
- Each relayer independently verifies the price against its own data before signing
- Signed updates are submitted to the oracle contract by the decentralized relayer set
- All submissions are attributed on-chain — the submitting relayer address is recorded for every update
| Threat | Protection |
|---|---|
| Single relayer going offline | Other relayers maintain submission continuity |
| Single relayer submitting a manipulated price | Independent relayer verification catches discrepancies |
| Centralized control of price updates | No single entity has unilateral submission authority |
Layer 7: On-Chain Storage Integrity
What it does: Ensures that once a verified price is stored on-chain, it cannot be altered, deleted, or manipulated by any party — including IFÁ Labs. Properties of the on-chain storage model: Immutable contracts: The oracle contracts have no upgrade mechanism, no proxy pattern, and no admin keys with the ability to modify stored prices. Once a price is written to contract storage by an authorized relayer, it remains there until the next legitimate update. No privileged write access: Only authorized relayers can submit price updates. There is no owner function, no emergency override, and no backdoor that allows arbitrary price writes. Full audit trail: Every price update is permanently recorded on-chain with the block timestamp, the submitting relayer address, and the price value. The complete history of every feed is publicly verifiable by anyone — no data is ever deleted or overwritten without a correspondingPriceUpdated event.
Public read access: All price data is readable by any address via public view functions. There is no access control on reads — no API key, no whitelist, no fee gate.
Combined Defense Analysis
The seven layers work together to create compounding protection:| Attack Vector | Layers That Defend |
|---|---|
| Single source compromise | Layer 1 (diversity), Layer 3 (outlier removal), Layer 4 (median) |
| Flash loan price attack | Layer 2 (volume threshold), Layer 3 (flash event filter) |
| Coordinated multi-source attack | Layer 4 (weighted median requires >50% weight), Layer 5 (peg bounds) |
| Relayer compromise | Layer 6 (decentralized relay, independent verification) |
| Depeg event triggering cascade | Layer 5 (peg bounds check withholds submission) |
| Zero-price data failure | Layer 2 (positive price guard), Layer 5 (zero-price guard) |
| On-chain price tampering | Layer 7 (immutable contract, no admin keys) |
| Historical data manipulation | Layer 7 (permanent audit trail, public event log) |
Next Steps
Verification Proofs
Tools and methods for independently verifying IFÁ Labs price accuracy.
AdForensics Audit Summary
The full audit results covering the contracts these mechanisms protect.