The Cross-Chain Canonical Contract Deployment Registry is the authoritative source for Pendle's smart contract addresses on every supported EVM chain. As Pendle expands its yield tokenization infrastructure to new networks, each deployment includes core contracts—such as the market factory, SY wrappers, and the AMM router—whose addresses must be verified against this registry. Bridges, multi-chain aggregators, and indexers depend on this data to safely integrate PT and YT assets without interacting with unofficial or malicious contracts.
Protocols
Cross-Chain Canonical Contract Deployment Registry
A registry of the official Pendle core and periphery contract addresses deployed on new EVM chains. Covers the governance process for selecting new chains and the technical nuances of each deployment, such as wrapped native token handling.
introduction
CANONICAL DEPLOYMENT REGISTRY
Introduction
A registry of the official Pendle core and periphery contract addresses deployed on new EVM chains.
Each new chain deployment is authorized through Pendle's governance process and introduces chain-specific technical nuances. These include the handling of wrapped native tokens (e.g., WETH on non-Ethereum chains), adjustments to AMM parameterization for different gas environments, and the configuration of cross-chain vePENDLE governance bridges. A deployment on an L2 may use different oracle update frequencies or TWAP windows than mainnet, directly affecting arbitrageurs and lending protocols that consume Pendle's on-chain prices.
Operators and integrators must treat this registry as a critical dependency. Indexing an incorrect contract address can lead to mispriced assets, broken redemption flows, or failed liquidations. Before supporting a new Pendle deployment, teams should verify all contract addresses against the canonical registry and review the deployment's specific parameterization. Chainscore Labs provides deployment verification reviews to ensure your integration targets the correct contracts and correctly interprets chain-specific configuration, preventing costly integration errors before they reach production.
CROSS-CHAIN CANONICAL CONTRACT DEPLOYMENT REGISTRY
Deployment Quick Facts
Operational facts for integrators, indexers, and bridge operators to safely support new Pendle deployments on EVM chains.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
New chain deployment | Core and periphery contracts deployed to a new EVM chain | Bridges, multi-chain aggregators, indexers, wallets | Verify contract addresses against the official registry before integrating |
Wrapped native token handling | SY wrapper logic may differ for the chain's native gas token | DeFi protocols using PT/YT as collateral, arbitrageurs | Review SY wrapper implementation for native token deposit and withdrawal edge cases |
Governance process | vePENDLE holders vote to approve new chain deployments | Governance delegates, DAO tooling providers | Monitor PIP votes and timelock transactions to anticipate new chain activation |
Cross-chain vePENDLE bridge | vePENDLE voting power and reward distribution extended to new chain | Governance participants, protocols integrating vePENDLE | Verify bridge relayer and trust assumptions for the new chain path |
AMM parameterization | Chain-specific curve parameters, fee tiers, and TWAP windows activated | Liquidity providers, arbitrageurs, oracle consumers | Adjust cross-chain strategy models for new chain gas costs and block times |
Market factory deployment | Factory contract deployed with chain-specific maturity and fee logic | Protocols programmatically deploying or indexing Pendle markets | Audit factory parameters for permissioned vs. permissionless market creation |
Indexer and subgraph updates | New chain requires subgraph or indexer configuration changes | Data teams, portfolio trackers, analytics platforms | Update indexing infrastructure to ingest events from the new deployment |
Unofficial contract risk | Scam or copycat contracts may appear before or after official deployment | All integrators and users | Cross-reference all contract addresses against the canonical registry; request a deployment verification review from Chainscore Labs if uncertain |
technical-context
DEPLOYMENT VERIFICATION AND CHAIN-SPECIFIC RISK
Governance and Technical Nuances
The process for deploying Pendle's canonical contracts on new EVM chains involves governance selection, technical adaptation for wrapped native tokens, and critical verification steps for integrators.
The expansion of Pendle to a new EVM chain is not a simple copy-paste operation. It begins with a governance process, typically a vePENDLE vote, to select the target chain and ratify the deployment parameters. Once approved, the core and periphery contracts—including the MarketFactory, YieldContractFactory, and the AMM's Router—are deployed. A critical technical nuance for each deployment is the handling of the chain's native gas token. Pendle's architecture relies on wrapped native tokens (e.g., WETH, WMATIC) for its SY wrappers and AMM pools. On new chains, the official wrapped native token contract address must be canonically defined and integrated into the SY standard versioning logic to ensure PT/YT markets for the native yield-bearing asset function correctly.
The operational risk for integrators lies in the verification of these canonical addresses. Bridges, multi-chain aggregators, and indexers must not rely on third-party block explorers or community-maintained lists without independent verification. An unofficial or malicious contract deployed at a similar address could be mistaken for the canonical Pendle deployment, leading to loss of funds or corrupted indexer data. The Cross-Chain Canonical Contract Deployment Registry serves as the source of truth, but integrators must also verify the bytecode of each deployed contract against the audited, governance-approved source code. A mismatch could indicate a compromised deployer key or an unofficial fork.
Furthermore, chain-specific AMM parameterization is set during deployment. While the V2 AMM invariant remains constant, parameters like the TWAP observation window and fee tiers may be adjusted for the target chain's block times and gas costs. Integrators building cross-chain arbitrage bots or pricing oracles must query these on-chain parameters directly from the deployed contracts rather than assuming they mirror Ethereum mainnet. A deployment verification review by Chainscore Labs can provide a formal attestation of bytecode integrity, parameter correctness, and wrapped native token configuration, preventing integration with unofficial or misconfigured contracts before they cause a critical failure.
CROSS-CHAIN DEPLOYMENT IMPACT
Affected Actors
Bridge and Messaging Layer Impact
Bridges and cross-chain messaging protocols must integrate the canonical contract addresses for new Pendle deployments to enable safe asset transfers and data passing. Incorrect or unverified addresses can lead to stuck funds, failed message delivery, or integration with malicious contracts.
Action Items:
- Update address whitelists and token registry databases with the new canonical deployment addresses immediately upon governance confirmation.
- Verify the deployment's wrapped native token handling logic, as deviations from standard WETH9 interfaces can break bridge adapters.
- Review the governance process that authorized the deployment to ensure the multisig or timelock controlling the bridge adapters aligns with your risk parameters.
- Test cross-chain message passing for PT/YT transfers before enabling user-facing bridge routes.
Chainscore Labs can perform a deployment verification review to ensure your bridge integration targets the correct, governance-approved contracts and handles edge cases in the new chain's execution environment.
implementation-impact
CROSS-CHAIN DEPLOYMENT REGISTRY
Integration Impact Areas
Operational and security impact analysis for teams integrating with Pendle's canonical contract addresses on newly supported EVM chains. Covers verification risks, wrapped native token handling, and governance trust assumptions.
01
Contract Address Verification
Integrators must verify that the deployed bytecode on a new chain matches the canonical Pendle implementation. Unofficial or unverified deployments pose a significant risk of asset loss. Teams should not rely on block explorers alone; a diff check against the audited source code and official registry is required before any protocol interaction. Chainscore Labs can perform a deployment verification review to confirm bytecode integrity and initialization parameters.
02
Wrapped Native Token Handling
Deployments on chains like Arbitrum or Optimism require careful handling of the native gas token wrapper (e.g., WETH). The canonical registry specifies the exact wrapped token address used by Pendle's routers and AMM. Using an incorrect wrapper address in your integration logic will cause transaction failures and potential fund loss. An integration impact assessment should explicitly validate the wrapped native token path for each target chain.
03
Governance and Multisig Trust Assumptions
The process for selecting new chains and authorizing deployments is governed by the Pendle DAO and executed by a core team multisig. Integrators inherit the trust assumptions of this governance process. A malicious or compromised deployment key could deploy backdoored contracts. Risk teams should model the operational security of the deployer address and the timelock mechanics on each new chain before integrating.
04
Indexer and Subgraph Updates
Multi-chain aggregators, portfolio trackers, and indexers must update their configuration to include the new factory, router, and market addresses from the canonical registry. Failure to update subgraph manifests or indexing logic will result in missing or incorrect data for users on the new chain. An operational readiness review should include a checklist for updating all off-chain data pipelines to recognize the new deployment.
05
Bridge and Messaging Dependency Mapping
Cross-chain governance voting and potential future cross-chain liquidity flows depend on the bridge architecture (e.g., LayerZero) used by Pendle. The canonical registry implicitly defines the bridge endpoints for each chain. Integrators must map these dependencies to understand the liveness and security assumptions inherited from the underlying bridge. A bridge dependency review can identify systemic risks before they affect cross-chain operations.
06
AMM Parameter Variance Across Chains
The canonical deployment on a new L2 or sidechain may include different AMM parameters (e.g., fee tiers, TWAP window) compared to Ethereum mainnet, optimized for lower gas costs. Arbitrageurs and liquidity providers operating cross-chain strategies must adjust their models to account for these chain-specific configurations. An operational readiness review can help teams validate their pricing and rebalancing logic against the exact parameters in the registry.
CROSS-CHAIN DEPLOYMENT VERIFICATION
Integration Risk Matrix
Assesses the operational and security risks introduced by new canonical Pendle deployments on EVM chains, focusing on contract address verification, wrapped native token handling, and cross-chain dependency assumptions.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Contract Address Verification | New core (SY/PT/YT, AMM, Router) and periphery contract addresses are deployed on a new chain. | Bridges, multi-chain aggregators, indexers, wallets, and DeFi protocols integrating Pendle. | Verify all contract addresses against the official Pendle deployment registry and governance vote. Do not trust third-party block explorers without cross-referencing. |
Wrapped Native Token Handling | The deployment may use the chain's native wrapped token (e.g., WETH on non-Ethereum chains) as the base asset, introducing a new SY wrapper contract. | Liquidity providers, arbitrageurs, and protocols that treat the native asset and its wrapped version as interchangeable. | Audit the new SY wrapper for correct wrapping/unwrapping logic and fee accrual. Review for potential dust or donation attack vectors specific to the chain's gas mechanics. |
Oracle and TWAP Configuration | AMM parameters, including TWAP window length and oracle update frequency, are tuned for the new chain's block times and gas costs. | Lending protocols using PT as collateral, oracles consuming Pendle's on-chain price feeds, and cross-chain arbitrage bots. | Validate that the configured TWAP window is resistant to manipulation given the chain's validator set and block time. Conduct an oracle risk assessment before integrating the new feed. |
Cross-Chain Governance Bridge | The deployment may include a bridge for vePENDLE voting power, relying on a specific message-passing protocol (e.g., LayerZero) with its own trust assumptions. | Governance delegates, DAO tooling providers, and protocols integrating vePENDLE voting power across chains. | Review the bridge's security model, relayer set, and multisig control. Model the tail risk of a bridge compromise on cross-chain gauge voting and reward distribution. |
Market Factory Parameters | The Market Factory contract is deployed with chain-specific parameters, potentially including permissioned market creation or unique fee tier configurations. | Protocols that programmatically deploy new Pendle markets and indexers that track market creation events. | Verify factory parameters against the governance specification. Ensure your indexing logic correctly parses new market events and does not assume mainnet-specific fee tiers. |
Emergency Pause and Circuit Breaker Roles | The pause mechanism's multisig or governance roles are instantiated on the new chain, potentially with a different set of signers than mainnet. | Integrators, liquidation bots, and front-ends that must handle paused states gracefully. | Map the authorized pause roles and their addresses. Implement monitoring for pause events and test your system's response to a protocol-level pause on the new chain. |
Indexer and Subgraph Compatibility | The new deployment requires an updated subgraph or indexer endpoint to correctly track PT/YT markets, AMM events, and reward accrual on the new chain. | Portfolio trackers, analytics dashboards, and any off-chain service querying Pendle data. | Update your infrastructure to point to the canonical subgraph for the new chain. Validate data integrity by reconciling on-chain state with indexed data for the first few maturity cycles. |
DEPLOYMENT VERIFICATION
New Chain Integration Checklist
A technical checklist for protocol architects, bridge operators, and indexers to safely integrate Pendle's canonical contract deployments on a newly supported EVM chain. This process confirms the authenticity of deployed contracts and validates operational readiness before exposing user funds or indexing logic.
Cross-reference every deployed contract address—including the core SY/PT/YT factory, AMM router, and vePENDLE bridge components—against the official Pendle governance proposal and deployment registry. Do not rely on third-party block explorers or community lists as a primary source.
Why it matters: Unofficial or malicious contracts can be front-run on a new chain before the official deployment is widely indexed. Integrating with an incorrect address leads to total loss of funds or corrupted indexer data.
Confirmation signal: The on-chain deployment transaction must originate from the Pendle Deployer address specified in the governance vote, and the resulting contract addresses must match the canonical registry exactly.
resource-links
SOURCE CHECKLIST
Canonical Resources
Use these resources to verify official Pendle deployments before integrating new cross-chain contracts. Treat contract addresses, router entry points, market factories, and chain-specific wrapper assumptions as production-critical configuration.
05
Chain explorer verification workflow
For each registry entry, verify the deployment on the relevant chain explorer before adding it to production configuration. Check that the source is verified, constructor arguments are consistent with the expected market, factory, router, or SY wrapper role, and ownership or admin roles match the documented governance or multisig setup. This is especially important for L2 and sidechain deployments where unofficial clones can appear before integrators update allowlists.
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 DEPLOYMENT FAQ
Frequently Asked Questions
Common questions from bridge operators, multi-chain aggregators, and indexers about verifying and integrating with new canonical Pendle deployments.
What to check: Cross-reference the contract address against the canonical registry maintained in Pendle's official documentation and governance-approved deployment announcements.
Why it matters: Unofficial or malicious contracts can be deployed to impersonate Pendle markets. Integrating with an unverified address can lead to loss of funds, incorrect pricing data, or broken indexer logic.
Verification signal: The strongest confirmation comes from a governance PIP that authorizes the deployment, followed by a mainnet transaction from Pendle's known deployer address. A deployment verification review from Chainscore Labs can provide an independent third-party assessment of the deployment's authenticity and parameter correctness.
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.