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.Documentation Index
Fetch the complete documentation index at: https://docs.alterscope.org/llms.txt
Use this file to discover all available pages before exploring further.
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, orno_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.