Stale or manipulable price feeds are the single largest category of DeFi loss. Before Alterscope can reason about a lending market’s risk, it has to understand how that market gets its prices — how many feeds, in what arrangement, and how fresh. This page describes how Alterscope classifies an oracle configuration and turns it into a risk signal.
Oracle classification today covers Morpho-style Chainlink oracle adapters (MorphoChainlinkOracleV2). Coverage for other oracle architectures is rolling out — see Coverage & gaps. Oracle category
Alterscope assigns each market’s oracle a category based on the structure of its feeds and vaults. The category is decided purely by how many active price feeds the adapter uses and whether it includes exchange-rate vaults:
| Category | Meaning |
|---|
fixed_price | No live feeds — the price is a hard-coded scale factor. |
simple_feed | Exactly one live price feed. |
multi_feed | Two or more live feeds combined. |
vault_feed | One or more feeds plus one or more exchange-rate vaults. |
vault_only | No feeds — price derived purely from vault exchange rates. |
custom | An adapter shape Alterscope does not yet model. |
no_oracle | The market declares no oracle at all (a zero address). |
multi_feed configuration with redundant sources is harder to attack than a fixed_price or vault_only one, and no_oracle is treated as a hard failure.
Feed roles
Within a multi-leg oracle, each individual feed is tagged with the role it plays in deriving the final price:
| Role | Position in the price calculation |
|---|
base_feed_1, base_feed_2 | The base-asset legs. |
quote_feed_1, quote_feed_2 | The quote-asset legs. |
exchange_rate | A vault exchange-rate leg. |
Staleness vocabulary
Every feed is checked against its expected update cadence (its heartbeat). Alterscope reports an oracle-specific staleness status:
| Status | Meaning |
|---|
fresh | Updated within one heartbeat. |
approaching_stale | Older than one heartbeat but within two — usable, watch it. |
stale | Older than two heartbeats — treat with caution. |
unknown | Freshness cannot be determined for this leg. |
not_applicable | A fixed-price oracle, where freshness does not apply. |
unverifiable | A real adapter Alterscope cannot yet model — surfaced honestly, never masked as fresh. |
unknown, the whole oracle is escalated to unknown. The platform never reports a composite as fresh when one of its inputs cannot be verified — a direct application of the freshness-first principle.
This is the oracle-feed staleness vocabulary. It is distinct from the response-envelope freshness status (realtime / fresh / stale / unknown) that every API response carries — see Freshness & staleness. The envelope tells you how fresh the response is; this tells you how fresh the underlying price feed is. From classification to a risk score
Classification feeds a rule-based oracle risk scorecard. The score starts at 100 and applies deductions for structural and freshness weaknesses — for example, a fixed-price configuration, uncovered collateral or loan legs, a stale or approaching-stale feed, admin-controlled parameters, or an unknown aggregator. Configurations that cannot price the market at all (a scale-factor mismatch, or no_oracle) score zero. The result maps to a plain risk band:
| Band | Score |
|---|
green | 80–100 |
yellow | 50–79 |
red | 0–49 |
The oracle risk scorecard is a rule-based expert scorecard — the deductions encode domain judgment about which configurations are riskier. It is not a statistically calibrated probability model; read the band as a structured risk indicator, not a likelihood.
Where this shows up
Oracle classification, feed roles, staleness, and the risk band are returned by the oracle and market endpoints. As always, results carry freshness and quality metadata. What this model does not yet cover is on the Limitations page. 
