> 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/run-a-pool/chain-specific-guides.md).

# Best practices

## Operating a feed

For an update-dependent pool, a delayed feed update is a loss for liquidity providers. This page is about minimizing delays, minimizing the losses from delays, and protecting liquidity providers.

There are three components:

* What your Price Provider does (Price Provider)
* How the chain orders transactions (Chain rules)
* How your update gets onchain (Update pipeline)

Update-independent pools, whose providers read onchain state and push nothing, need only the first part.

## Price Provider

**Freshness.** Set the provider's freshness limit and revert when the data is older than it.

**Toxicity protection.** On fee-sorted chains, cap the priority fee a swap may pay and pay above the cap on updates (see fees below). Use other heuristics, such as widening or halting, when your feed is at risk of going stale.

**Halting.** Halt by reverting from `getQuote()`.

**Cross-checks.** Compare against an independent source, such as Chainlink, Pyth or another market's TWAP, and halt on divergence.

**Reference honesty.** Report the reference as the geometric mid or your best fair price. It sets the fee split and the displayed LP earnings; misreporting can lead to pool deprioritization.

**Caller independence.** `getQuote()` returns identical values regardless of `msg.sender` and `tx.origin`, and does not revert when `tx.origin` is the zero address. Otherwise simulation breaks and the pool is deprioritized in routing.

**Rounding.** Bid rounds down, ask rounds up.

## Chain rules

Chains differ in how transaction order is built and whether your update can be placed before the trades that use it. The regimes are described in [Freshness and ordering](/how-pools-work/freshness-and-ordering.md); find your chain's row there before building. Chain specifics: [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).

Rules that hold on every chain:

1. Learn your chain's transaction ordering before anything else: block time, sub-block batches if any. Confirm the supported submission route before deploying.
2. Optimize delivery of your quotes: pick a location that minimizes the delay of your transaction. Information-source location, sequencer location and a direct endpoint are essential.
3. Submit writes to the sequencer or builder endpoint; use a private RPC for reads. Sequencer endpoints usually accept submissions only.

## Update pipeline

### Sending

1. Sign once locally; submit raw bytes with `eth_sendRawTransaction` over warm connections to several endpoints. Send identical bytes to all of them concurrently.
2. Read receipts (`status`, `gasUsed`, `effectiveGasPrice`) asynchronously through the read RPC. Never block the next send on a receipt.
3. Timestamps are monotonic on every Metric oracle: an older update cannot overwrite a newer one. Send freshest first.

### Fees

1. Never wait for a fee RPC or gas estimation on the send path. Refresh `baseFeePerGas` and `eth_gasPrice` in the background into a cache.
2. On fee-sorted chains, cap the priority fee a swap may pay (a `beforeSwap` extension) and pay above the cap on updates. Your update is then selected ahead of any capped swap pending at the same time. A swap selected before your update arrives stays ahead, so delivery time still matters.
3. Estimate the update call's gas cost before launch and leave 20-30% headroom.
4. Where an additional fee buys no ordering, keep it at zero.

### Nonces and wallets

For your own feed, keep the **administration key separate from the online process** and delegate only update permissions.

1. Use many wallets for updates: at least 50. Refill them before they run dry. A balance must cover fee headroom; a small gas balance leads to irregular updates and can lead to a loss of funds.
2. Reserve each wallet's nonce locally before signing.
3. `replacement transaction underpriced`: another transaction holds the nonce. Handle it separately from nonce sync.

### Measuring

1. Time each stage separately: trigger → send, construction, signing, RPC call, endpoint response - and measure execution separately.