Pyth Network 🔮 (@PythNetwork): HIP-3.1: Expanding Oracle Flexibility for Traditional Markets

HIP-3.1: Expanding Oracle Flexibility for Traditional Markets Proposed amendments to enable equities, indices, and high-speed markets on HIP-3 Proposed by the Pyth Data Association and SEDA With the launch of HIP-3, permissionless deployment of perpetual markets for any asset on Hyperliquid has been enabled. Deployers can now launch markets for S&P 500 futures, gold, rare metals, funding rates, and others that haven’t existed before. But as deployers begin building markets for traditional assets, a constraint has emerged: HIP-3's oracle parameters, not for the demands of equities, private equities, and other novel instruments like prediction markets. Equity indices can move several percentage points during market events and corporate actions. Interest rate products shift rapidly during central bank announcements. Private markets could move 20-30% with release of new data. The existing oracle framework—with its hardcoded 1% price change caps and immediate slashing mechanisms—creates friction for these use cases. That's why the Pyth Data Association and @sedaprotocol are proposing HIP-3.1: targeted amendments to expand oracle flexibility while maintaining security and user protections. The Current Constraints HIP-3's oracle framework has three limitations for traditional markets: 1. Validator Verification Gap Many TradFi instruments rely on proprietary pricing that validators cannot independently verify. Private equity, structured products, or certain OTC derivatives don't trade on public exchanges. Validators must either trust the deployer's oracle blindly or slash based on indirect signals—neither is ideal. 2. Fixed Price Update Caps The hardcoded 1% price change limit creates problems for fast-moving markets. The S&P 500 can move 2-3% in minutes during major announcements. Interest rate products can shift several percentage points during Fed decisions. Forex pairs swing sharply during geopolitical events. Current constraints would require multiple sequential updates to reflect reality, creating temporary mispricing windows. 3. Single-Address Oracle Control The oracle updater accepting a single address introduces operational risk. If that key is compromised, the entire market's oracle becomes vulnerable. For institutional deployers managing significant volume, single-address control is unacceptable. Proposed Amendments Amendment 1: Replace Immediate Slashing with Halt Mechanism Current: Validators can immediately slash a deployer's stake for oracle failures. Proposed: Validators can halt a market via 66% consensus if they suspect oracle issues. A mandatory 7-day investigation period follows, during which validators can determine if behavior was accidental (no slash or partial penalty), negligent (partial slash), or malicious (full slash). Why: This aligns incentives more effectively. Deployers are responsible for sourcing reliable data. Validators protect users by halting suspicious markets. But they're not forced to make immediate, irreversible decisions about proprietary data they cannot verify. The deliberation period allows the community to assess whether failures were accidental, negligent, or malicious. Amendment 2: Configurable Price Update Caps Current: Price updates capped at 1% per call. Proposed: Deployers can set maxPriceDeviation from 0.01% to 5%, adjustable post-deployment based on their market's characteristics. Why: Different asset classes have different volatility profiles. A stablecoin perpetual might warrant a 0.1% cap. An equity index during earnings might need 3%. Interest rate products during Fed announcements might require 5%. Prediction market perps might require even >5%. This flexibility enables deployers to optimize for their specific use case without requiring protocol-level changes for each asset class. Amendment 3: Multi-Signature Oracle Updaters Current: Oracle updater accepts a single address. Proposed: Require oracle updater to be an array of addresses, enabling multi-signature setups (e.g., 2-of-3 threshold). Why: Institutional deployers require operational redundancy. Multi-sig provides key rotation capabilities, provider migration without downtime, distributed trust, and compliance with regulatory requirements. This also enables more sophisticated oracle architectures with multiple relay nodes operating independently. Why This Matters These amendments remove friction preventing institutional-grade TradFi markets from scaling on HIP-3 while also introducing further security measures to safe guard markets: For Deployers: Greater flexibility in oracle configuration, clearer accountability for data quality, and operational security through multi-sig. For Validators: Better tools to protect users without requiring independent verification of proprietary data, plus deliberation time to assess oracle issues properly. For Traders: Access to a wider range of markets with oracle infrastructure designed for each asset class's characteristics. For the Ecosystem: Proof that onchain derivatives can meet institutional standards across all financial markets, not just crypto. What Happens Next This proposal represents a collaboration between oracle infrastructure providers and the Hyperliquid community to expand what's possible with builder-deployed perpetuals. It moves forward only if the community and validators support it. HIP-3 can become the standard infrastructure for onchain derivatives across all financial markets—not just crypto. These amendments remove the technical barriers. Now it's up to the community to decide if the vision of truly permissionless, multi-asset derivative markets should move forward. Pythliquid.