Data sources

Milky's oracle does not invent prices. Every quote is grounded in real-world market data from a professional pricing provider, passed through a gate that refuses rather than guesses.

The source: Alt.xyz

The production data source is Alt.xyz, a graded-card analytics platform with deep coverage of cert-level pricing data.

For each price request, the Milky backend asks Alt for:

The current value of the specific card at the specific grade, expressed in USD.
A confidence band (lower bound, upper bound) reflecting recent sale dispersion.
The graded-population statistics for the card (how many copies exist at each grade), which feeds into a confidence tier.
Recent sale history that the backend can use for sanity checks.

Alt's data is cert-resolved end-to-end: a PSA cert number maps to a specific canonical asset, and pricing is grade-specific. This is the exact granularity Milky needs for loan-by-loan pricing.

There is no second source

Milky has no second pricing provider. That is a real limitation, and it is worth being precise about what the protocol therefore cannot do:

It cannot detect that Alt's price for a specific card is wrong by comparing it against an independent opinion.
It cannot fall back to another provider when Alt is unavailable — an outage means no new loans against affected cards, not degraded ones.

What the gate in front of Alt does instead, on every request:

Honours the circuit breaker. If Alt's responses start failing schema validation above a small threshold, the client stops answering and the quote path refuses.
Bounds the call. A fetch that exceeds five seconds is abandoned and treated as no price.
Rejects stale reads. A cached price older than one hour is refused and evicted rather than reused.
Requires a real signal. A response with no confidence metric, or with a confidence or graded-population below the floor, is refused outright rather than priced at the lowest tier.

Every one of those outcomes is the same: no quote. The protocol will not issue a loan against a price it cannot stand behind.

How the fair market value (FMV) is chosen

Within Alt's response, the protocol could in principle anchor the signed FMV on different points of the confidence band:

The headline value (Alt's best-estimate current price).
The lower bound of Alt's confidence band (more conservative).
A moving average of recent values (smoother but more lagged).

Today's production behavior signs the headline value. The architecture supports anchoring on the lower bound and applying additional sanity bands; those are roadmap items as the protocol's risk tooling matures. The launch-tightened LTV table below is what gives headroom in the meantime, regardless of which point on the band the FMV is anchored to.

What is not a data source today

For clarity:

eBay sold listings are referenced indirectly through Alt's data pipeline, but the protocol does not scrape eBay directly.
General Pyth / Switchboard feeds are not consulted for card prices. They are not a meaningful pricing surface for graded cards.
Manual price overrides are not part of the production quote path.

How LTV is determined

In addition to the FMV, the oracle picks an LTV in basis points (a hundredth of a percent; 10,000 = 100%) for each quote. The quote gets the lowest of three independent ceilings:

The global maximum LTV (currently 80%).
The pool's max_ltv_bps (often 80% in production pools).
The confidence tier Alt's data earns for that specific card.

In practice the confidence tier binds on standard and long-tail cards. The live table is:

Confidence tier	Min confidence	Min population	Max LTV
Blue chip	70	500	80%
Standard	50	100	60%
Long tail	30	50	40%

Below the long-tail floor the oracle refuses to quote at all. The borrower sees the chosen LTV in the quote and can decide whether to proceed at that level.

When pricing is unavailable

If Alt returns no usable data — it is offline, the cert lookup fails, the cached price is stale, or the confidence is too low to safely lend against — the backend returns a PRICING_UNAVAILABLE error and the loan request is rejected at the off-chain layer. The chain never sees the request.

This is by design. The protocol prefers a clean rejection at the quote step over a degraded, possibly-incorrect signed price reaching the chain.