Polygon's Amoy (PoS) and Cardona (zkEVM) testnets are the primary staging environments where validators, infrastructure providers, and application teams validate new client releases, governance parameter changes, and protocol upgrades before they reach mainnet. Unlike permissioned devnets, these public testnets must maintain a realistic state and transaction load to surface integration bugs, state sync failures, and performance regressions that would otherwise be discovered in production. A poorly coordinated testnet reset or regenesis event can invalidate months of integration work and delay mainnet upgrade timelines.
Protocols
Amoy and Cardona Testnet Coordination
Central operational reference for Polygon's Amoy (PoS) and Cardona (zkEVM) testnets. Tracks scheduled resets, regenesis events, faucet availability, and stability expectations so development and infrastructure teams can plan testing cycles around known periods of instability.
introduction
OPERATIONAL RISK
Why Testnet Coordination Matters
Coordinated testnet operations are a critical dependency for the Polygon ecosystem's upgrade pipeline and developer experience.
The operational surface is complex. A scheduled testnet reset requires synchronized action across Bor and Heimdall client versions for PoS, or across the zkEVM node, prover, and bridge service for Cardona. Faucet updates, bootnode configuration changes, and state sync bootstrap points must all be aligned. If a single infrastructure provider runs an incompatible client version after a reset, they can fork away from the canonical chain, causing RPC endpoints to serve stale data and breaking downstream indexers, wallets, and DeFi frontends that rely on those endpoints for testing.
For teams building on Polygon CDK, the testnet coordination cycle is even more critical. Appchain operators often mirror Amoy or Cardona configurations for their own test environments. A breaking change in the CDK stack that is not properly validated against a coordinated testnet can cascade into multiple L2 test environments, blocking development across an entire ecosystem of chains. Chainscore Labs helps operators and builders navigate these coordination points by providing testnet deployment support, compatibility testing, and upgrade readiness reviews that catch configuration drift before it causes a testnet outage or a delayed mainnet activation.
AMOY AND CARDONA OPERATIONAL STATUS
Testnet Quick Facts
Key operational parameters and coordination touchpoints for developers and infrastructure providers running Polygon testnet environments.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Network Lifecycle | Amoy and Cardona are subject to scheduled resets, regenesis events, and potential state wipes that are not coordinated with mainnet stability guarantees. | Smart contract developers, wallet teams, dApp frontends, indexers, and integration testers. | Subscribe to Polygon release channels and testnet coordination forums. Do not treat testnet state as persistent for production staging. |
Faucet Availability | Native testnet token faucets may be rate-limited, drained, or replaced with new authenticated distribution mechanisms during resets. | Developers, QA engineers, and automated CI/CD pipelines that require testnet tokens for gas. | Verify faucet endpoint and authentication requirements against the canonical Polygon developer docs before each testing cycle. Maintain fallback token sources. |
Client Compatibility | Bor, Heimdall, and zkEVM node/prover releases may introduce breaking changes that require re-synchronization from genesis on testnet before mainnet activation. | Node operators, validators, sequencer operators, and RPC providers running testnet infrastructure. | Audit client release notes for minimum version requirements and re-sync flags before each testnet reset. Test upgrade paths in isolated environments. |
RPC and API Behavior | Canonical JSON-RPC methods may change behavior, deprecate, or introduce new endpoints on testnet ahead of mainnet deployment. | Exchange integration teams, wallet backends, data indexers, and block explorers. | Run integration test suites against testnet endpoints after each client upgrade. Monitor API changelogs for deprecation notices and method signature changes. |
State Sync and Bridge Testing | Heimdall state sync events and bridge deposit processing on testnet may be paused, replayed, or reset during regenesis, breaking assumptions about cross-chain message finality. | Bridge operators, cross-chain application developers, and custody teams testing deposit/withdrawal flows. | Do not rely on testnet bridge finality for production simulation. Verify state sync health after each network event and replay test vectors against fresh state. |
Validator and Sequencer Coordination | Testnet validator sets and sequencer roles may be permissioned, rotated, or reset without the governance process used on mainnet. | Staking operators testing validator workflows, sequencer failover scripts, and MEV infrastructure. | Confirm the active validator and sequencer configuration for each testnet phase. Test failover and key management procedures against the current authorized set. |
Prover Infrastructure | zkEVM prover requirements on Cardona may change with proof system upgrades, altering hardware profiles, proving costs, and batch submission timing. | Rollup operators, proving service providers, and CDK appchain teams. | Benchmark prover performance against updated testnet parameters. Validate that proving capacity can keep pace with sequencer batch production under new proof types. |
Data Availability Committee | CDK Validium DAC membership and liveness requirements on testnet may differ from mainnet configurations, with reduced thresholds or simulated failure modes. | Appchain operators, DAC node runners, and data availability service providers. | Test DAC node failover and data recovery procedures under the specific testnet configuration. Do not assume mainnet DAC parameters apply. |
technical-context
PLANNED IMPERMANENCE
Testnet Lifecycle and Instability Model
Polygon's Amoy and Cardona testnets operate under a model of planned instability, including scheduled resets and regenesis events, requiring developers and infrastructure operators to build testing workflows that anticipate state loss.
Polygon's testnet strategy for the PoS and zkEVM ecosystems relies on a lifecycle model where state is explicitly not permanent. The Amoy testnet for the PoS chain and the Cardona testnet for the zkEVM rollup are subject to scheduled resets, regenesis events, and coordinated faucet updates. This is a deliberate design choice to allow the core development teams to test major state transitions, network upgrades, and migration tooling in a low-stakes environment before mainnet activation. For application developers, this means that deployed contracts, account balances, and accumulated state will be wiped according to a communicated schedule, and any reliance on long-lived testnet environments for persistent staging or demonstration purposes is fundamentally misaligned with the network's operational intent.
The operational impact of this model falls most heavily on continuous integration pipelines, automated testing frameworks, and infrastructure providers who must treat testnet nodes as ephemeral. A regenesis event, for example, involves exporting the network's social consensus state—such as account balances and validator sets—and restarting the chain from a new genesis block, discarding all historical block data. For node operators, this requires a full re-sync from the new genesis, and for developers, it necessitates re-deploying all smart contracts and re-funding test accounts via the updated faucet. Teams that do not automate these steps risk significant downtime in their testing cycles. Monitoring systems must be configured to distinguish between a genuine network halt and a planned reset to avoid false-positive alerts.
Chainscore Labs provides testnet deployment support and compatibility testing services for teams that need to maintain reliable testing environments across these instability events. This includes designing infrastructure-as-code templates that can re-deploy a full application stack to a fresh testnet genesis, verifying that contract migration scripts function correctly against the new state, and auditing CI/CD pipelines to ensure they correctly handle faucet authentication changes and RPC endpoint updates. For infrastructure providers running persistent testnet nodes, Chainscore can build automated reset detection and re-sync playbooks to minimize manual intervention during scheduled regenesis events.
IMPACT ANALYSIS
Who Is Affected by Testnet Changes
Infrastructure Operators
Testnet resets and regenesis events require operators to destroy old chain data and bootstrap new nodes from genesis. This is not a simple restart.
Immediate actions:
- Monitor the official Amoy/Cardona documentation for the exact reset block height and new genesis file.
- Prepare to wipe Bor and Heimdall data directories completely. A partial reset will cause consensus failures.
- Re-initialize Heimdall with the new genesis, then start Bor with the updated
borgenesis and static node list. - Verify peering with the new bootnodes immediately after restart.
Operational risk: Failure to reset correctly results in a node stranded on an abandoned fork, unable to sync or process state sync events. Validators risk extended downtime and missed checkpoint signing windows.
implementation-impact
TESTNET COORDINATION
Operational Impact Areas
Amoy and Cardona testnets are subject to scheduled resets, regenesis events, and faucet changes that directly impact development and testing lifecycles. Teams must plan around these instability windows to avoid stalled CI/CD pipelines and broken integration environments.
01
Scheduled Testnet Resets
Amoy and Cardona testnets undergo periodic regenesis events that wipe state and reset chain history. Infrastructure teams must rebuild archive nodes from new genesis files and re-sync all dependent services. Smart contract deployments, token balances, and on-chain configurations are not preserved across resets. Development teams should automate contract redeployment and state seeding to minimize downtime during these windows.
02
Faucet Availability and Rate Limiting
Testnet faucets for Amoy and Cardona distribute native tokens required for gas and testing. Faucet availability can degrade during high-demand periods or reset transitions. Teams relying on automated faucet drips in CI/CD pipelines should implement fallback funding sources or maintain a reserve of testnet tokens. Monitor official faucet endpoints for rate-limit changes that could block automated test execution.
03
RPC and Bootnode Connectivity
After resets or regenesis events, canonical bootnode lists and RPC endpoints may change. Nodes configured with stale peer lists will fail to sync with the new network. Operators should verify bootnode configurations against official sources before each reset window. Chainscore can audit node peering configurations and validate RPC endpoint compatibility to prevent connectivity gaps during testnet transitions.
04
Contract Redeployment and State Seeding
All smart contracts deployed on Amoy or Cardona must be redeployed after a regenesis event. Teams with complex multi-contract systems and protocol dependencies need automated deployment scripts and state initialization tooling. Without preparation, integration tests will fail against empty state. Chainscore provides deployment pipeline reviews and compatibility testing to ensure test environments recover quickly after resets.
05
Cross-Team Coordination Windows
Testnet resets affect all teams building on Polygon simultaneously. Indexers, wallets, bridges, and DeFi protocols all need to coordinate their recovery procedures. Misaligned recovery timelines create false-positive integration failures. Teams should participate in pre-announced coordination channels and maintain shared runbooks for post-reset validation steps.
06
Monitoring and Alerting for Testnet Health
Testnet instability can manifest as reduced validator participation, stalled state sync, or gas price anomalies. Proactive monitoring of block production, peer counts, and faucet balances helps teams distinguish between local configuration issues and network-wide problems. Chainscore builds custom testnet monitoring dashboards and alerting configurations to reduce debugging time during instability windows.
AMOY AND CARDONA OPERATIONAL RISKS
Testnet Instability Risk Matrix
Evaluates failure modes for teams relying on Polygon testnets, covering planned resets, faucet reliability, and regenesis events that disrupt testing cycles.
| Risk Area | Failure Mode | Affected Actors | Severity | Mitigation Action |
|---|---|---|---|---|
Scheduled Testnet Reset | State wipe invalidates all deployed contracts, account balances, and transaction history without persistent archival. | Smart contract developers, QA teams, integration testers | High | Align deployment scripts with reset calendar; automate contract redeployment; verify RPC endpoint compatibility post-reset. |
Unplanned Regenesis | Consensus failure or critical bug forces an emergency chain restart with a new genesis block, potentially altering chain ID. | Infrastructure providers, wallet teams, block explorers | Critical | Monitor Polygon governance channels for emergency proposals; test node failover to new genesis configuration. |
Faucet Unavailability | Rate-limiting, funding depletion, or API downtime prevents developers from obtaining testnet tokens. | dApp developers, automated test suites, CI/CD pipelines | Medium | Maintain a private reserve of testnet tokens; integrate multiple faucet providers; monitor faucet health endpoints. |
Client Version Incompatibility | Testnet nodes running mismatched Bor or Heimdall versions fork away from the canonical chain during upgrades. | Node operators, validators, RPC providers | High | Pin client versions to those specified in upgrade announcements; run a staging node to validate sync before upgrading production endpoints. |
State Sync Bridge Stall | Heimdall state sync mechanism halts, preventing deposit events from Ethereum from being relayed to the testnet. | Bridge operators, DeFi protocol testers, cross-chain application developers | High | Implement monitoring for Heimdall event nonce progression; set alerts for stalled state syncs to trigger manual intervention. |
RPC Endpoint Deprecation | Critical JSON-RPC methods are deprecated or change behavior in a new client release without sufficient notice. | Exchange integration teams, wallet backends, data indexers | Medium | Run integration tests against testnet RPC canary nodes; subscribe to client release notes for API changelogs. |
Proof Generation Lag (Cardona) | zkEVM prover infrastructure cannot keep pace with sequencer batch production, delaying L1 settlement finality. | Rollup operators, L2 application developers, bridge security monitors | High | Right-size prover hardware based on network throughput benchmarks; monitor batch-to-verify latency and set alerts on proof gaps. |
AMOY AND CARDONA COORDINATION
Testnet Reset Readiness Checklist
A structured checklist for infrastructure operators, development teams, and validators to verify operational readiness before a scheduled Amoy or Cardona testnet reset. Completing these checks minimizes downtime and ensures services are correctly aligned with the new genesis state.
Confirm the exact block height and expected timestamp for the regenesis event from the canonical coordination channel (e.g., Polygon Governance Forum or official Discord).
- Why it matters: All downstream actions (snapshotting, client upgrades, service shutdowns) are timed against this specific block. A mismatch leads to operating on the wrong fork.
- Readiness signal: The target block number and date are pinned in your team's operational calendar and match the official announcement exactly.
resource-links
TESTNET COORDINATION
Canonical Resources and Monitoring Channels
Use these channels to track Amoy and Cardona testnet changes before scheduling integration tests, faucet-dependent workflows, bridge tests, or node maintenance. Treat testnet endpoints as operationally unstable unless confirmed against Polygon-maintained sources.
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.
TESTNET OPERATIONS
Frequently Asked Questions
Common questions from infrastructure teams and developers coordinating testing cycles around Amoy and Cardona testnet resets, faucet updates, and regenesis events.
What to check: Monitor official Polygon communication channels, including the Polygon blog, developer Discord, and GitHub repositories for the maticnetwork organization. Look for announcements tagged with "testnet," "Amoy," or "Cardona."
Why it matters: A scheduled reset or regenesis will wipe state, requiring all infrastructure to be reprovisioned from a new genesis file. Missing the announcement means your test environment will be incompatible with the canonical network.
Confirmation signal: A governance post or developer announcement specifying a target block height, a new genesis file hash, and a timeline for the faucet and block explorer updates.
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.