Polygon CDK deployment model
A practical component and operational-boundary guide for Polygon CDK rollups.
Polygon CDK deployments are not a single node. They combine an L2 execution and sequencing path, proof and batch-processing services, L1 settlement contracts, bridge infrastructure, data-availability services, and independently operated RPC or synchronizer nodes. This guide turns the architecture used in the RAAS deployment material into the ownership and operating decisions that matter for a long-lived chain.
The accompanying POL-RAAS repository contains the implementation and source deployment material behind this model.
The diagram separates the services controlled by the chain operator from the systems that users and independent participants must be able to verify. Exact component names and combinations differ by CDK release, DA mode, and sequencer implementation, so use it as an ownership model rather than a deployment manifest.
Source architecture variants
The source deployment material also includes both CDK Erigon and legacy zkEVM node component views. They are useful when choosing which service owns sequencing, execution, proof work, and public RPC responsibilities.
Component responsibilities
| Component | Responsibility | Operational concern |
|---|---|---|
| Sequencer | Admits, orders, and executes L2 transactions. | Availability, ordering policy, key custody, and backpressure. |
| Sequence sender | Publishes batches or their commitments to the settlement layer. | L1 fee funding, publication delay, and retry behavior. |
| Aggregator and prover | Produce and coordinate validity-proof work. | Capacity, proof queue latency, circuit compatibility, and durable job state. |
| Settlement contracts | Accept batches and proofs, and enforce the finality rules. | Upgrade authority, contract addresses, and L1 confirmation policy. |
| Bridge | Relays deposits, withdrawals, and cross-chain messages. | Finality, message reconciliation, pause authority, and user communication. |
| DA layer | Retains the transaction data needed to reconstruct rollup state. | Retrieval tests, retention, fallback policy, and publication backlog. |
| RPC and synchronizer nodes | Serve applications and independently reconstruct or verify state. | State-sync health, data correctness, capacity, and public access controls. |
Rollup and validium are different operating commitments
The existing CDK material distinguishes two availability modes. In rollup mode, transaction data is published to L1. In validium mode, transaction data is held outside L1 through a dedicated availability layer or committee. The latter can improve cost and throughput, but it adds an availability dependency that must be described clearly to users and tested as a recovery path.
Do not treat the choice as a simple performance setting. It changes which parties must be reachable for independent reconstruction, how a withdrawal or dispute can be resolved, and what evidence operators must retain during an incident. See Data availability for the common policy and test requirements.
Separate trusted control from public verification
The control environment contains services that can change the chain's behavior or submit state to L1. Protect the sequencer, sequence sender, prover controls, and contract administration with separate identities, least-privilege access, and an auditable change path. A restart permission for a public RPC node should not confer authority over a bridge, a batch-submission wallet, or contract upgrades.
The permissionless side should be able to follow the chain without trusting the operator's RPC alone. Run or test independent synchronizers and RPC nodes against the actual DA and settlement paths. Track their batch height, state-root agreement, and lag relative to the sequencer. A successful HTTP health check is insufficient if the node cannot retrieve batch data or follow finalized state.
What to verify before launch
- Submit a transaction through a public RPC endpoint and trace it through sequencing, batch publication, and settlement.
- Confirm that the sequence sender can pay L1 fees and recovers safely from a transient L1 or DA failure.
- Reconstruct a known state range with an independent synchronizer and compare its state root to the committed result.
- Deposit and withdraw an asset through the bridge, recording the normal and worst-case finality timings.
- Exercise the bridge pause and recovery procedure in a non-production environment without duplicating a message.
- Measure proof generation and verification latency under load. Alert before the proof or batch backlog approaches a user-visible delay.
Monitoring priorities
Monitor the complete pipeline: accepted L2 transactions, sequenced blocks, batches awaiting publication, L1 submission success, proof queue age, verified-batch progression, DA retrieval success, bridge-message age, and synchronizer lag. A local L2 that continues producing blocks while verified batches or data publication stop advancing is degraded, even when its RPC endpoint appears healthy.
The source deployment material also treats explorers, monitoring, and permissionless nodes as separate services. That separation is useful operationally: keep their failure domains distinct from the sequencer and settlement path, and document what each user-facing status signal actually proves.
For broader principles that apply across frameworks, continue with Bridging assets, Monitoring, and Upgrading rollups.