> ## 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

> How Alterscope categorizes a market's price-feed configuration, scores it for manipulation and staleness risk, and what each category means.

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.

<Note>
  Oracle classification today covers Morpho-style Chainlink oracle adapters (`MorphoChainlinkOracleV2`). Coverage for other oracle architectures is rolling out — see [Coverage & gaps](/trust/data/coverage-and-gaps).
</Note>

## 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).     |

Category matters because it bounds how manipulable a price is: a `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.        |

Roles let Alterscope reason about coverage — for example, flagging when a collateral or loan asset's price leg is missing — rather than treating the oracle as an opaque box.

## 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. |

**Composite discipline:** in a multi-feed oracle, if *any* leg is `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](/trust/data/freshness-and-quality).

<Note>
  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](/develop/concepts/freshness-and-staleness). The envelope tells you how fresh the *response* is; this tells you how fresh the *underlying price feed* is.
</Note>

## 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   |

<Note>
  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.
</Note>

Downstream, the oracle category and staleness status feed the [oracle factor](/trust/methodology/risk-factors) in the composite score and surface directly on the oracle-health and market endpoints in the [API reference](/api-reference/overview).

## 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](/trust/data/freshness-and-quality). What this model does not yet cover is on the [Limitations](/trust/methodology/limitations) page.