Liquidation Engine Design with Pull Oracles

The foundational pattern for pull-oracle liquidations. Keepers must bundle a call to Pyth's updatePriceFeeds with the liquidation call in a single atomic transaction. This prevents a front-runner from using the freshly updated price to perform the liquidation first. Protocol engineers must ensure their liquidation interface accepts a price update payload (the VAA) as a parameter, which is forwarded to the Pyth contract for verification before the health check. Without this atomicity, keepers face a 'just-in-time' race condition where their gas expenditure to update the price benefits a competitor.

Keepers should only update the minimal set of price feeds required to validate a specific liquidation, rather than updating all feeds for a market. This requires off-chain simulation: the keeper bot queries the Pyth Hermes endpoint for the latest price and confidence interval, simulates the updatePriceFeeds + liquidate transaction locally, and checks if the position is underwater. If profitable, it submits the transaction with a tightly scoped price update payload. This reduces calldata costs and avoids wasting gas on updating collateral asset prices that are not needed for the health calculation.

On EVM chains, keepers should use services like Flashbots Protect or direct eth_sendBundle to submit liquidation bundles privately. This prevents the transaction from being observed in the public mempool and front-run by a generalized MEV searcher. The bundle should include the updatePriceFeeds and liquidate calls, and the keeper should simulate the bundle against the latest block state to confirm profitability. For chains without a private mempool, keepers must use high priority fees and accept a higher rate of reverted transactions as a cost of doing business.

Use the official Pyth Price Feeds documentation as the starting point for liquidation-engine design. For pull-oracle liquidations, the key implementation question is not only how to read a price, but how the liquidation transaction obtains, pays for, and verifies a fresh update before calculating account health. Teams should map the exact sequence: keeper fetches update data, estimates the update fee, submits the update and liquidation atomically where supported, then reads the price with an explicit staleness bound.

Hermes is the canonical Pyth price service used by many integrations to fetch signed price updates for pull delivery. Liquidation keepers should treat Hermes integration as production infrastructure: implement retries, provider redundancy where available, response validation, per-feed caching, and profitability simulation that includes both gas and Pyth update fees. Risk teams should monitor whether missed liquidations correlate with unavailable, delayed, or stale update data rather than only on-chain oracle reads.

For EVM liquidation engines, review the official Solidity SDK and IPyth interface before writing custom oracle adapters. The liquidation path should explicitly handle update fee payment, stale-price reverts, confidence interval usage, exponent normalization, and failure behavior when the submitted update data is invalid or insufficient. Smart contract tests should cover underpaid update fees, old prices, missing feeds, extreme confidence values, and atomic update-plus-liquidate execution.

Liquidation engines should pin feed IDs from the official Pyth registry and treat feed selection as a risk-control decision, not a UI configuration task. Before enabling a market, verify the base asset, quote asset, exponent handling, symbol mapping, and whether the feed has sufficient operational history for the liquidation threshold being used. For long-tail collateral, pair feed-ID onboarding with stricter staleness limits, confidence-based discounts, caps, or guarded launch parameters.

Use the official contract-address documentation when deploying or migrating a liquidation module across chains. Hardcoding the wrong Pyth contract address can cause liquidations to fail, read from an unintended deployment, or bypass expected verification behavior. Deployment runbooks should include address verification, chain-specific fee behavior, adapter initialization checks, and test transactions that exercise both the price-update call and the liquidation call before enabling production keeper permissions.

Pyth price updates are delivered cross-chain using Wormhole infrastructure, so liquidation-risk analysis should include cross-chain message availability and verification assumptions. A lending or perps protocol may have correct liquidation math and still suffer delayed liquidations if update delivery is congested, unavailable, or incorrectly integrated on the target chain. Operators should monitor both the Pyth price-update path and the destination-chain transaction path when diagnosing stale prices or keeper failures.