Cross-Chain Data Availability Mandates are governance-approved directives within the Pyth Network that formally activate or decommission oracle data delivery to specific target blockchains. These mandates are not merely technical deployments; they represent a binding commitment from the Pyth DAO to maintain and support the Wormhole-based message relay, price feed contracts, and keeper infrastructure required for reliable data consumption on a given chain. For protocol architects and risk teams, the official list of mandated chains defines the perimeter of trusted data availability, distinguishing between chains with DAO-backed guarantees and those with experimental or unsupported deployments.
Protocols
Cross-Chain Data Availability Mandates
Documents governance votes mandating Pyth data availability on new blockchains or decommissioning support for existing ones. Impacts multi-chain DeFi strategies, bridge dependencies, and Wormhole integration assumptions. Covers activation timelines, chain-specific constraints, and migration guidance.
introduction
CROSS-CHAIN DATA AVAILABILITY MANDATES
Introduction
Governance actions that expand or contract the set of blockchains where Pyth Network price data is officially available, directly affecting multi-chain DeFi strategies and cross-chain infrastructure assumptions.
The operational impact of these mandates is immediate and multi-faceted. An activation mandate triggers a cascade of technical requirements: deployment of Pyth receiver contracts, configuration of Wormhole guardians to verify and relay messages for the new chain, establishment of keeper networks to execute updatePriceFeeds transactions, and integration of the chain's gas token for fee estimation. Conversely, a decommissioning mandate forces all dependent protocols to migrate their oracle dependencies or risk operating on stale, unsupported data. This creates a hard dependency chain: a lending protocol on a decommissioned chain must re-architect its liquidation engine, while a cross-chain arbitrage strategy must remove the chain from its routing logic. The governance decision directly alters the risk profile of every smart contract consuming Pyth data on the affected chain.
For teams operating across multiple chains, these mandates are a critical input to deployment strategy and risk monitoring. A new mandate signals a greenfield opportunity with DAO-backed data guarantees, but also requires validation of the specific Wormhole guardian set, finality assumptions, and relayer liveness on the target chain. A decommissioning mandate is a forced migration event that demands immediate review of fallback oracle configurations, staleness tolerances, and liquidation parameters. Chainscore Labs assists integrators in assessing the impact of these governance actions, reviewing cross-chain dependency graphs, and implementing robust migration or fallback strategies to ensure continuous protocol safety.
CROSS-CHAIN DATA AVAILABILITY MANDATES
Proposal Snapshot
A structured overview of governance proposals that activate or decommission Pyth data availability on specific blockchains, highlighting the operational impact on integrators, bridge dependencies, and multi-chain deployment strategies.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
New Chain Activation | Governance vote to mandate Pyth price feed availability on a new target blockchain via Wormhole. | DeFi protocols, bridges, and wallets on the target chain; Pyth integrators planning multi-chain expansion. | Verify canonical proposal details and activation timeline; prepare integration environment and contract dependencies. |
Chain Decommissioning | Proposal to cease data delivery and deprecate on-chain contracts for a specific chain. | All protocols consuming Pyth data on the deprecated chain; liquidity providers and users of dependent markets. | Audit all contracts relying on the deprecated feed; plan migration to alternative oracle or chain before the shutdown block. |
Wormhole Dependency Update | Change in the Wormhole governance or relayer configuration required for cross-chain data delivery. | Bridge operators, Pythnet validators, and integrators relying on cross-chain message verification. | Review updated Wormhole attestation logic; test message verification in a staging environment to ensure data integrity. |
Activation Timeline | Specification of the exact block height or timestamp when data becomes available or ceases. | Node operators, relayers, and DeFi protocols with automated oracle update logic. | Coordinate contract upgrades or configuration changes to align with the precise activation boundary; monitor for first valid update. |
Chain-Specific Constraints | Mandate includes constraints like reduced update frequency, limited feed set, or different trust assumptions. | Arbitrageurs, high-frequency protocols, and lending markets sensitive to data staleness. | Assess whether the constrained feed meets the protocol's minimum staleness and confidence interval requirements; adjust risk parameters if necessary. |
Migration Guidance | Official documentation and transition period for protocols moving from a deprecated chain to a supported one. | Multi-chain DeFi protocols, treasury managers, and cross-chain asset issuers. | Execute and test the full migration path, including fallback oracle logic, before the deprecation deadline. |
Governance Vote Outcome | The DAO's final decision on a cross-chain mandate, including vote tally and rationale. | Governance delegates, token holders, and risk teams monitoring oracle decentralization. | Analyze voter participation and dissent to gauge community confidence in the new chain's security model; update internal risk assessments. |
technical-context
CROSS-CHAIN DATA DELIVERY GOVERNANCE
Technical Mechanism and Dependencies
How Pyth governance mandates oracle data availability on new blockchains and decommissions support for existing ones.
Pyth Network's cross-chain data availability is not a purely permissionless operation; it is governed by the Pyth DAO, which votes to mandate or decommission oracle support on specific blockchains. Each mandate is a directive to the core contributors and Wormhole-dependent relay infrastructure to deploy, maintain, and fund the gas costs for price feed delivery on a target chain. The technical mechanism relies on Pythnet, a purpose-built Solana-based appchain, where publishers submit price updates. These updates are aggregated and then transmitted across chains via Wormhole's generic message passing protocol, which provides attestation of the data's integrity and provenance. A governance mandate effectively authorizes the operational and economic resources required to extend this pipeline to a new execution environment.
The operational impact of a mandate is immediate for integrators on the target chain. Once activated, the canonical Pyth receiver contract becomes available, and protocols can begin consuming price feeds. However, the dependency stack is deep: integrators implicitly trust not only the Pyth publisher set and aggregation logic but also the Wormhole guardian network for cross-chain message verification. A decommissioning vote, conversely, triggers a critical migration window. The DAO may set a timeline for deprecating on-chain price updates, after which feeds will stall. DeFi protocols relying on these feeds for lending, perpetuals, or stablecoin liquidations must migrate to an alternative oracle or a new Pyth deployment before the deadline to avoid a catastrophic failure of their price-dependent mechanisms.
For risk teams and protocol architects, the key review points are the activation timeline, the specific Wormhole integration pattern used (e.g., receiver contract version), and the chain-specific constraints such as gas cost economics and block time. A mandate to a new chain often requires a separate governance action to whitelist specific price feeds for that chain, creating a two-step dependency. Chainscore Labs can assist teams in conducting an upgrade readiness review that maps the entire dependency tree—from publisher aggregation to the consuming DeFi protocol's fallback oracle logic—to ensure that a governance mandate does not introduce an unmonitored risk to their liquidation engine or pricing model.
CROSS-CHAIN MANDATE IMPACT
Affected Stakeholders
DeFi Protocols & Integrators
Protocols consuming Pyth data on newly mandated chains must integrate the on-chain price feed contracts before the activation deadline. This requires updating oracle interfaces, configuring staleness thresholds, and testing liquidation logic against the new feed availability patterns.
For chains being decommissioned, protocols face a hard migration deadline. Teams must identify all contracts reading from deprecated Pyth deployments, switch to alternative oracle sources or migrate to supported chains, and communicate changes to users. Failure to migrate before decommissioning will result in stale prices, potentially freezing liquidations, borrows, and withdrawals.
Action items:
- Audit all contracts for deprecated Pyth feed dependencies
- Test integration against target chain's specific update frequency and fee model
- Update confidence interval and staleness parameters to match new chain behavior
- Prepare fallback oracle circuits for the transition window
implementation-impact
CROSS-CHAIN MANDATE ACTIONS
Operational and Integration Impact
Governance votes to mandate or decommission Pyth data availability on a blockchain trigger a cascade of operational and integration work for node operators, relayers, and consuming protocols.
03
Decommissioning and Deprecation Migration
When a governance vote decommissions support for a chain, Pyth stops delivering new price updates to that environment. Consuming protocols must migrate to an alternative oracle or a supported chain before the deactivation block height. This requires updating smart contract oracle pointers, recalibrating staleness thresholds, and potentially unwinding complex cross-chain positions. Teams should monitor governance forums for mandatory migration timelines and test fallback oracle paths in advance.
04
Cross-Chain Staleness and Confidence Calibration
New chain mandates often inherit the same price update frequency as existing deployments, but block time differences and relayer latency can introduce chain-specific staleness profiles. Integrators must not assume identical data freshness across chains. Risk teams should recalibrate staleness thresholds, confidence interval tolerances, and liquidation parameters for the specific finality and relayer performance characteristics of the newly mandated chain to avoid stale-price exploits.
05
Bridge and Finality Dependency Risk Assessment
Pyth's cross-chain data delivery depends on Wormhole's guardian network for attestation verification. A mandate for a new chain introduces a dependency on that chain's finality mechanism and its integration with Wormhole. A chain reorganization or finality stall on the target chain can delay or invalidate price attestations. Protocol risk teams must model this transitive dependency and establish circuit breakers that account for Wormhole attestation delays specific to the new chain.
06
Publisher and Staking Requirement Re-evaluation
Expanding data availability to new chains can increase the operational cost for publishers who may need to run additional infrastructure to support the mandated environment. While governance mandates availability, it does not directly compel publishers to serve the new chain. Integrators should verify that a sufficient quorum of publishers is actively supporting the new chain to maintain data integrity and avoid reliance on a sparse publisher set that weakens the cryptoeconomic security model.
CROSS-CHAIN DATA AVAILABILITY MANDATES
Risk Matrix
Evaluates the operational, security, and integration risks introduced when governance votes mandate Pyth data availability on a new blockchain or decommission support for an existing one.
| Risk Area | Failure Mode | Severity | Affected Actors | Mitigation / Action |
|---|---|---|---|---|
Wormhole Dependency | A new chain mandate implicitly relies on Wormhole for cross-chain message passing. A Wormhole guardian set compromise, quorum failure, or contract bug on the target chain can lead to stale or forged price data. | Critical | DeFi protocols, bridges, exchanges, custodians | Verify the canonical Wormhole attestation flow for the new chain. Implement application-level staleness checks and circuit breakers independent of the Pyth relay. |
Publisher Coverage | Governance mandates data availability on a chain where no or few publishers are actively running the required infrastructure, leading to low update frequency or single points of failure. | High | DeFi protocols, liquidators, perpetual exchanges | Monitor the number of active publishers on the new chain post-mandate. Do not assume full publisher set participation without on-chain verification. |
Decommissioning Orphaned Integrations | A vote to decommission support for a chain leaves existing integrations without fresh price data, causing permanent staleness and potential lockup of user funds in lending markets or derivatives. | Critical | DeFi protocols, users, wallets, custodians | Proactively scan for all Pyth-consuming contracts on the deprecated chain. Migrate to alternative oracle solutions or force-close positions before the decommissioning block height. |
Chain-Specific Constraints | The target chain's block time, gas limits, or execution environment may prevent timely price updates, causing the oracle to lag behind the aggregate and creating arbitrage opportunities. | Medium | Arbitrageurs, DeFi protocols, market makers | Benchmark the target chain's update latency against Pyth's confidence interval. Adjust protocol risk parameters (e.g., liquidation bonuses) to account for expected staleness. |
Governance Activation Lag | A mandate is approved by governance but the technical deployment (contract deployment, relayer configuration, publisher onboarding) is delayed or incomplete, creating a false expectation of data availability. | Medium | Protocol integrators, governance delegates | Do not integrate against a mandate until the canonical Pyth contracts are deployed and verified on the target chain. Confirm with block explorers and the Pyth documentation. |
Relayer Centralization | For a new chain, the initial relayer set may be permissioned or operated by a single entity, creating a liveness and manipulation risk until the network decentralizes. | High | DeFi protocols, risk teams | Identify the relayer architecture for the new chain. If permissioned, implement a secondary oracle fallback and monitor relayer transaction activity for anomalies. |
Cross-Chain Reorganization Risk | A deep reorg on the source chain (Pythnet) or the target chain could invalidate a price update that was already consumed by a protocol, leading to inconsistent state. | Medium | DeFi protocols, bridges | Enforce a sufficient confirmation depth on both the source and target chains before consuming a price update. Align this depth with the economic value secured. |
CROSS-CHAIN DATA AVAILABILITY MANDATES
Migration and Activation Checklist
A practical checklist for protocol integrators, risk teams, and operations engineers to prepare for a governance-mandated activation or decommissioning of Pyth data on a specific blockchain. This covers technical readiness, dependency validation, and operational monitoring adjustments.
Confirm the exact parameters of the passed proposal directly from the canonical governance forum or on-chain vote record. Do not rely on social media summaries.
- What to check: The specific target chain, the activation or decommissioning timeline, any transitional grace periods, and the new contract address if deploying to a new chain.
- Why it matters: Misinterpreting the timeline or target chain can lead to premature integration attempts or failure to migrate before a critical deadline, causing oracle downtime.
- Readiness signal: The official proposal ID is documented, and the execution timestamp is confirmed against the target chain's block explorer.
resource-links
PYTH GOVERNANCE AND CROSS-CHAIN AVAILABILITY
Canonical Resources
Canonical resources for tracking Cross-Chain Data Availability Mandates in Pyth Network governance. Use these sources to verify proposal status, supported chains, feed identifiers, integration contracts, and Wormhole-dependent delivery assumptions before changing production systems.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
CROSS-CHAIN DATA AVAILABILITY MANDATES
Frequently Asked Questions
Practical answers for integrators, operators, and risk teams assessing the impact of governance decisions that mandate or decommission Pyth data availability on specific blockchains.
A governance mandate to activate Pyth on a new chain triggers a series of technical and operational steps that integrators must track:
- Contract Deployment: The core Pyth on-chain contracts must be deployed and verified on the target chain. Teams should confirm the canonical contract addresses from the official Pyth documentation, not third-party sources.
- Wormhole Integration: Data delivery depends on Wormhole relaying signed price updates from Pythnet. Verify that the target chain is supported by Wormhole's Guardian network and that the relayer infrastructure is operational.
- Publisher Commitment: Publishers must configure their infrastructure to submit data to the new chain. Initial data freshness may be suboptimal until a critical mass of publishers is active.
- SDK and Client Updates: The Pyth SDK and client libraries (e.g.,
pyth-sdk-solidity,pyth-sdk-rs) will require updates to include the new chain's contract addresses and configuration. Integrators should pin their dependencies and test against the new endpoints.
Why it matters: Premature integration before full publisher coverage and relayer stability can lead to stale prices and failed transactions. Teams should monitor the getUpdateFee and parsePriceFeedUpdates calls on the new chain to confirm live data flow before switching production systems.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.