Skip to main content
Pyth
Every price-sensitive operation in Kimia reads a Pyth Hermes Pull Oracle.
Pull oracles are fundamentally different from the old “push” model: the PriceUpdateV2 account lands on-chain in the same transaction that uses it.

The flow

1

Off-chain: fetch a signed update

2

Build a postPriceUpdate instruction

3

Prepend it to your Kimia instruction

The resulting price_update account becomes the oracle argument to place_order, liquidate, update_funding_rate, etc.
4

Atomic consumption

Post + consume happen in the same tx. No window for staleness. No chance of a front-run replacing the price you expected.

On-chain validation

Kimia’s perps-common::validate_pyth_oracle enforces five checks before any price is used: Any failure short-circuits the instruction with a clear error code (6000..6002).

Normalization

Pyth feeds typically report with expo = -8 (eight decimals). Kimia normalizes to six decimals internally: target_price=pyth_price×10pyth_expotarget_expo106\text{target\_price} = \frac{\text{pyth\_price} \times 10^{\text{pyth\_expo} - \text{target\_expo}}}{10^6} Example: SOL at 130.00000000 (pyth_price = 13_000_000_000, expo = -8) becomes 130_000_000 at expo = -6.

Where oracles are used

Perpetuals

Where oracle reads feed into margin and liquidation.

Error codes

Oracle error codes and how to handle them.