L3/Appchain Development on Polygon CDK

We develop L3/appchains on Polygon CDK for projects that need full control over execution environment, gas token, and throughput. This isn't just deploying your own blockchain—it's an architectural trade-off where you gain flexibility in exchange for responsibility over sequencing, DA, and bridge security. Polygon CDK offers modular components to build ZK-validated L2/L3 chains with various configurations—from full ZK-Rollup to Validium with external DA. Our team has 10+ years in blockchain development and 5+ years with the Polygon ecosystem, having successfully launched 15+ appchain projects. We help you choose the optimal mode, configure the bridge, and launch the chain in production.

What Is Polygon CDK and Why You Need It

Polygon CDK is a modular framework for deploying your own EVM-compatible chain with a ZK-proof system. Under the hood: zkEVM (Type 1/2/3 per Vitalik's taxonomy), Sequencer, Aggregator (generates ZK-proof), and bridge contracts on L1.

An appchain is justified when:

• You need your own gas token (users pay gas with your token)
• You require specific EVM logic (precompiles for your application)
• Throughput > 1000 TPS is unachievable on a shared L2 without your own sequencer
• You need custom transaction inclusion rules (whitelist, KYC-gate at network level)
• You want isolation from noise of other applications on a shared L2

An appchain is overkill when: you're building an MVP, have < 100k users, or can deploy contracts on an existing L2.

Architecture: CDK Chain Components

zkEVM: Choosing the Type

Polygon CDK offers several modes:

Type 2 zkEVM (full EVM-compatibility) — any Solidity/EVM bytecode runs without changes. The prover generates a ZK-proof of EVM execution equivalence. This is used in Polygon zkEVM mainnet beta. Overhead: proof generation time (minutes) and L1 verification cost.

Validium mode — transaction data is stored off-chain (Data Availability Committee, not Ethereum). Cheaper L1 fees but weaker DA guarantees. For gaming/social appchains where DA is not critical, this is justified.

Sovereign chain — no bridge to Ethereum, its own consensus. Maximum independence, minimal security guarantees.

Deployment Components

L1 Ethereum (or Polygon PoS as base layer) └── Bridge Contract (LxLy bridge) └── PolygonRollupManager (manages rollups) └── Verifier Contract (ZK proof verification) L2/L3 CDK Chain ├── Sequencer Node — accepts tx, forms batches ├── Prover / Aggregator — generates ZK-proof for the batch ├── RPC Node — public JSON-RPC for users └── State DB — PostgreSQL + Merkle state tree 

How to Configure the Sequencer for Maximum Performance?

The sequencer is the central component determining transaction order. In CDK, the sequencer works in centralized mode (you control it), giving maximum performance but requiring trust. Decentralized sequencing is on the roadmap.

Key parameters in config.yaml:

sequencer: # Maximum batch size (affects latency vs throughput) maxBatchSize: 300000 # gas units # How often to close a batch (in seconds) batchSealTime: 5 # Minimum tip for transaction inclusion minGasPrice: "1000000000" # 1 Gwei # Gas token: if using your own token feeTokenAddress: "0xYourTokenAddress" # Whitelist for sequencer access (if closed network needed) enableTransactionFilter: false l1: rpcURL: "https://ethereum-rpc" chainID: 1 # How often to send batches to L1 sendBatchFrequency: 300 # 5 minutes prover: uri: "prover-service:50052" # Timeout for proof generation timeout: 600s 

Gas Token: Your Token as Gas Payment

One of the main reasons for an appchain is gas paid in your own token. CDK supports this via the GasTokenAddress parameter during deployment. Users pay gas with your ERC-20 instead of ETH/MATIC.

Important: the bridge works differently. When bridging the native token between L1 and L3 CDK, it uses a wrapped representation. You need to thoroughly test bridge + gas payment scenarios.

ZK Proof Generation: Practical Aspects

This is the most resource-intensive part. The prover (zkProver) is a separate service that generates a SNARK-proof for each batch.

Aggregator ├── Prover Node 1 (batch 1001-1050) ├── Prover Node 2 (batch 1051-1100) └── Prover Node 3 (batch 1101-1150) 

Bridge: LxLy Bridge and Customization

CDK uses the LxLy bridge — a unified bridge protocol from Polygon for L1-L2-L3 communication. Supports bridging ETH, ERC-20, ERC-721, and arbitrary data (message passing).

Standard flow deposit L1→L3:

1. User calls bridgeAsset() on L1 bridge contract
2. Event is recorded in L1 Merkle tree
3. CDK chain watches L1, claims deposit automatically (via claimAsset()) or user claims manually

Custom bridge middleware — if you need KYC checks or amount limits during bridging:

// Custom bridge wrapper with whitelist check contract KYCBridgeWrapper { IPolygonZkEVMBridge public immutable bridge; mapping(address => bool) public kycApproved; function bridgeWithKYC( address token, uint256 amount, uint32 destinationNetwork, address destinationAddress ) external { require(kycApproved[msg.sender], "KYC required"); IERC20(token).transferFrom(msg.sender, address(this), amount); IERC20(token).approve(address(bridge), amount); bridge.bridgeAsset(destinationNetwork, destinationAddress, amount, token, true, ""); } } 

How to Choose a DA Layer for Your Appchain?

In the standard configuration, transaction data is published to Ethereum (calldata or EIP-4844 blobs). This is the most secure option but expensive. EIP-4844 (Proto-Danksharding) blobs are significantly cheaper than calldata, saving 5-10x. At 1000 TPS, L1 DA costs are around $5,000 per day — acceptable for many projects.

Validium / DAC (Data Availability Committee) — data is stored with a set of trusted nodes; only a commitment (hash) is published to L1. Cheaper by 10-100x but requires trust in the DAC. For enterprise/gaming appchains it's acceptable.

Celestia or EigenDA — external DA layers. Decentralized DA with lower cost than Ethereum. CDK roadmap includes integration.

Monitoring and Operations

Metrics to track from day one:

# Prometheus alerts - alert: SequencerStuck expr: polygon_cdk_last_batch_sent_minutes > 15 annotations: summary: "Sequencer has not sent a batch for 15+ minutes" - alert: ProverQueueDepth expr: polygon_cdk_prover_pending_batches > 30 for: 5m annotations: summary: "Prover falling behind: {{ $value }} pending batches" 

How to Deploy an Appchain in 5–7 Weeks

1. Design (1 week): Choose DA mode, gas token, bridge configuration. Define genesis parameters (chainID, initial allocations). Plan infrastructure.
2. Local deployment and testing (1-2 weeks): Docker Compose with full stack: L1 (Hardhat/Anvil node), CDK sequencer, prover mock, bridge. End-to-end testing: deploy contracts, bridge, transactions.
3. Testnet deployment (1 week): Deploy on public testnet (Sepolia L1). Test with real ZK-prover. Load test the sequencer.
4. Mainnet preparation (1 week): Security review of bridge contracts, key management (admin keys, upgrade authority), monitoring, runbook for operators.
5. Mainnet deployment (3-5 days): Gradual rollout starting with bridge limits.

Key risks are proof generation time on available hardware and integration bugs in the bridge. Our engineers will prepare a runbook and conduct load testing.

What's Included in Appchain Development

• Selection and configuration of zkEVM (Type 2/Validium/Sovereign)
• Deployment and customization of LxLy bridge (including KYC proxy if needed)
• Sequencer and prover configuration
• RPC node deployment with load balancing
• DA layer integration (Ethereum, Validium, Celestia)
• AggLayer connection for liquidity
• Monitoring setup (Prometheus + Grafana) and alerts
• Operator and user documentation creation
• Team training and deployment support

Infrastructure Costs

Estimated monthly costs for production:

GPU-accelerated prover (A100/H100) yields 5-10x faster proof generation but costs from $2,000/month to rent. Our clients save up to $10,000 per month by using Validium instead of ZK-Rollup.

Order a turnkey appchain development. Contact us for a project evaluation. Get a consultation today.