> For the complete documentation index, see [llms.txt](https://docs.metric.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.metric.xyz/how-pools-work/freshness-and-ordering.md).

# Freshness and ordering

How a trade meets the maker's latest price update on each chain.

A trade can **pick off** an outdated quote before the maker's new quote reaches the oracle.

**Freshness limits** reject old feed data. **Ordering** decides whether the new update happens before the trade that uses it.

Update-independent pools don't need the update pipeline, though ordering can still affect their onchain sources.

## Staleness bound

Off-the-shelf Price Providers revert when a required update is older than their limit, which halts trading until a fresh update lands. Custom providers set their own checks.

A freshness limit bounds how old the feed data behind a quote can be. See [Pool tiers](/use-metric/provide-and-manage-liquidity/pool-tiers.md) for required limits.

**Keeping prices updated is the pool curator's job**, which in a public pool means the curator: running the updater, or making sure a shared one keeps the feed fresh. Metric doesn't guarantee that updates are published or delivered on time, even when they're sent through Metric.

## How each chain orders an update against a trade

Metric works closely with block builders and the foundations of every chain it operates on. The builder commitments below are the builders' own service policies, not onchain rules.

| Regime                       | Where                                                                   | How it works                                                                                                                                                                                                                          | What you can rely on                                                                                                                    |
| ---------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| **Conditional updates**      | Ethereum, participating builders                                        | Market makers stream updates to Metric's endpoint, which forwards them to participating builders. A participating builder includes your update only in a block that contains a trade against your pool. Priority tips change nothing. | In blocks it builds, the builder commits to placing the latest update it has received from you before the trade.                        |
| **Protected execution lane** | BSC, participating builders                                             | You submit updates to Metric's endpoint, which forwards them to 48Club and, when the update carries a `maxTimestamp`, to BlockRazor.                                                                                                  | In blocks these builders build, they commit to placing your update before trades against your pool.                                     |
| **Builder auction**          | Ethereum outside participating builders; BSC outside the protected lane | Builders order transactions for block profit.                                                                                                                                                                                         | No ordering commitment. An ordinary update may land before the trade or after it, and a bundle that pays the builder more can go first. |
| **Arrival order**            | Robinhood Chain                                                         | The sequencer orders by arrival, not priority fee.                                                                                                                                                                                    | Nothing beyond arrival time.                                                                                                            |

Chain setup: [Ethereum](/run-a-pool/chain-specific-guides/ethereum.md) · [BSC](/run-a-pool/chain-specific-guides/bsc.md) · [Robinhood](/run-a-pool/chain-specific-guides/robinhood.md). Where Metric is live: [Deployments](/reference/supported-chains-and-deployments.md). Pipeline engineering: [Best practices](/run-a-pool/chain-specific-guides.md).

## What ordering doesn't solve

* **Your latency.** At best, ordering puts your latest update first; it can't make it newer. A taker who knows something your latest update doesn't reflect can still trade against it.
* **Trades without an ordering commitment.** A trade in another builder's block or on an arrival-order chain meets whichever update is onchain when it executes. It is priced from that update if the update is within the staleness limits, and reverts if it isn't.
* Metric's oracles use **monotonic timestamps**: an older update cannot overwrite a newer one.

## For integrators

For conditional updates:\
\
For takers, quote from Metric's API, which serves the latest streamed quotes; onchain reads are unreliable because of lag.\
\
For makers, submit quote updates through Metric's API, which forwards them to participating builders, or directly to those builders.

Metric also follows Titan's [propAMM interface](https://docs.titanbuilder.xyz/propamms/takers), so integrations built on it reach Metric pools as well. See [Integrate Metric liquidity](/integrate/integrate-metric-liquidity.md).