Truncated oracles
A sudden trade can move a thin market's price sharply, then the next trade can move it back. Beacon and Lighthouse pools keep an extra price history that absorbs these moves gradually. This gives market-data consumers a slower-moving record to compare with the live market.
The truncated oracle caps movement in that separate record. It does not round away decimal places, limit a token's trading price, or decide what the token is worth.
A short spike and a lasting move look different
Imagine a price jumps sharply and quickly returns. The capped history records only part of that jump at a time. If the higher price persists, the record keeps moving toward it; if the price falls back, the record follows it back instead.
The useful distinction is persistence: one short displacement cannot immediately enter this history at its full size. The tradeoff is delay. A genuine price change also takes time to enter the record, so the truncated value may lag the price at which you can actually trade.
Use live quotes for trading
Trades still execute against the live concentrated-liquidity price. A pool can have a large price move even while its truncated record moves slowly. Use the current trade quote and meaningful price limits for a swap; do not assume the capped history guarantees execution near its value.
Both histories come from the same market. Neither is an external reference price, and a sustained multi-block displacement can still move the capped record. A manipulated starting price or insufficient liquidity remains a problem.
Choose how quickly the record responds
A smaller movement cap absorbs a spike more slowly but also follows genuine price discovery more slowly. A larger cap catches up sooner while allowing more of a sudden move into the record.
The choice is fixed for each pool. The mainnet menu offers three settings, from the slowest-moving P1 to the faster-moving P3. Their labels describe the setting, not the quality of a token.
Exact mainnet settings and a tick example
A tick is a small numbered price step. If the last recorded tick is 10,000 and the live market moves to tick 11,000, a cap of 6 lets the next observation move only to 10,006. This is an illustration, not a real market event.
| Setting | Maximum recorded movement per block | Observation capacity |
|---|---|---|
| P1, blue-chip | 1 tick | 4,096 |
| P2, established-market default | 6 ticks | 4,096 |
| P3, volatile | 17 ticks | 4,096 |
These recorded settings are for Robinhood Chain mainnet, not other chains.
Check how much history actually exists
Swaps and in-range liquidity changes can add observations, at most once per block. The rolling record eventually replaces older observations. At the network's nominal 0.1-second block cadence, 4,096 observations cover roughly 6.8 minutes if qualifying activity occurs every block, not 30 minutes.
Quiet markets produce fewer observations. The record carries the last recorded state through idle time; a longer elapsed span does not mean more recent price evidence. Actual depth and maturity depend on activity and how long the pool has existed. A requested history window may be unavailable.
For builders using this data, check the pool configuration, history maturity and relevant liquidity before consuming a value. Launching a token with this history does not list it as collateral. Continue to Lending markets for the separate market requirements.