Price feeds vs reserve attestation

Who this is for: issuers and developers who need to be precise about what a given on-chain number actually proves, before a user or an integrating contract assumes it proves something else.

The distinction

A price feed answers: what is this asset worth right now, based on market activity? It is continuous, sourced from trading venues or other market data, and updated frequently by an oracle network. See Build → Oracles for the providers and integration steps.

A reserve attestation answers a completely different question: does the backing this token claims to have actually exist? It is periodic, sourced from an auditor or custodian rather than a market, and says nothing about the asset's current trading price. See Attestation models for how reserve attestation is typically performed.

Why the difference matters

These can diverge from each other in ways that matter to anyone relying on either number:

• A price feed can be live and accurate while a reserve attestation is stale or the reserve itself is impaired: the market price of a token doesn't automatically detect an insolvent backing.

• A reserve attestation can be current and clean while there's no reliable price feed for the token at all, if it's thinly traded or not yet listed anywhere a price oracle sources from.

A contract or integration that only checks a price feed is not thereby checking solvency, and a contract that only checks a reserve attestation is not thereby getting a live market price. Neither substitutes for the other; an issuer relying on both should treat them as two independent signals, not one combined health check.

Where this fits in the asset lifecycle

For issuers, reserve/backing attestation is part of the Attest stage of taking an asset through Lumia's tokenization lifecycle. See Tokenize → Attest for the task-level view of when and how attestation happens relative to issuance and distribution.