How price oracles work in Solana DeFi

Why an onchain program needs price information

A lending program can read token quantities from accounts, but a quantity alone does not tell it how valuable the collateral is relative to debt. It needs a defined valuation input to apply its rules.

An oracle provides information about an asset pair or reference under a particular method. The source may aggregate market observations or provide another type of rate. A redemption conversion, a USD reference and a DEX execution quote are different inputs.

For example, a protocol can value an LST using an underlying conversion rate while a market quotes its immediate sale price differently. Identify the valuation the protocol actually consumes.

This is the starting question in a liquidation investigation: which feed, aggregation path and timestamp did the program use, rather than which unrelated price a user saw later?

Follow the path from provider to consumer

A provider constructs a price update under its data model. An integration can verify or process it, and the consuming application applies the accepted value to its own operation.

There can be an intermediate aggregation program. Kamino's documentation describes Scope, which processes provider data and publishes state consumed by its applications. Reading only the upstream provider's latest website value can miss the actual accepted intermediate state.

Identify feed IDs, asset pair, quote unit and any conversion path. For a combined rate, each component and update condition matters. Several named providers are not proof of independent failure modes without examining the architecture.

Read the actual program and product version. A field or SDK method from one provider's model is not a universal Solana oracle interface.

Decode fixed-point prices and confidence

Price APIs often encode decimal values using an integer and exponent. For a teaching payload with price 250,000,000 and exponent −6, multiply by 10 to the power of −6 to obtain 250.

If its confidence integer is 500,000 with the same exponent, the decoded value is 0.5. The units follow the feed, such as quote currency per unit of the base asset.

Pyth Pro's documentation specifies a common exponent for its price and confidence fields. Its confidence describes provider-defined price uncertainty or dispersion; it is not a guarantee that a future trade fills inside a fixed interval.

Maintain integer precision and use the supported parser. A wrong exponent can turn a sensible price into one a million times too large or small, contaminating every subsequent health calculation.

Decode fixed-point values before using them

Verification and freshness are distinct checks

A signed update can be authentic while describing an earlier market state. The consumer needs an age policy and any required ordering or session condition in addition to origin verification.

Timestamp units matter. Pyth Pro documents microsecond fields, including feed-update timestamps, and distinguishes them from seconds-based environments. Comparing raw values in different units can make age calculations meaningless.

For a teaching difference of 5,000,000 microseconds, elapsed time is five seconds. Convert both timestamps to the same unit before comparing. Whether five seconds is acceptable depends on the actual action and policy; it is not a universal setting.

Market sessions can also matter for assets whose reference market closes. A last available price during a closed session needs its own interpretation. Network or provider outages can leave a formerly fresh value stale.

A valid reference price is not available trade liquidity

An oracle value can be appropriate for a protocol's defined calculation while a large sale executes at another average price. The sale consumes actual market depth and can include fees and impact.

This distinction becomes important when collateral must be sold. An account's reference valuation does not guarantee that every unit can be liquidated at that price in a stressed market.

A confidence field and a pool's depth describe different properties. Reading a narrow provider confidence value does not establish enough liquidity for a large exit.

Keep price-source, market-depth and execution assumptions separately named in a scenario. The swap price guide explains the trading comparison.

Make invalid-data behaviour part of the design

A consumer should define what happens when a feed is missing, too old, in an unsuitable session or outside its accepted confidence or deviation condition. It may reject or limit a price-dependent action under its documented rules.

Fallback sources need their own identity and validation. Switching from one stale feed to another stale feed does not create a current price. Record which source supplied the value the program accepted.

Test age conversion, source interruption and recovery as specific cases. Preserve input timestamps, selection and resulting action so an incident can be reconstructed.

For a user reviewing a position event, collect the consumed price and state at the relevant time. Then compare them with the program's valuation rule. This turns an apparent price discrepancy into a question that the evidence can answer.

Common questions