L3/appchain development on Polygon CDK

L3/Appchain Development with Polygon CDK

Your own appchain is not just "your own blockchain". This is choosing an architectural tradeoff: you get full control over execution environment, gas policy and throughput in exchange for responsibility for sequencing, DA and bridge security. Polygon CDK (Chain Development Kit) — set of components for building ZK-validated L2/L3. Let's see what this actually means in practice.

What is Polygon CDK and why do you need it

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

When appchain is justified:

• Need own gas token (users pay gas in your token)
• Require specific EVM logic (precompiles for your app)
• Throughput > 1000 TPS unachievable on L2 without own sequencer
• Custom transaction inclusion rules (whitelist, KYC-gate at network level)
• Isolation from noise of other apps on shared L2

When appchain is overkill: MVP, projects with < 100k users, when L2 deployed contracts suffice.

Architecture: CDK-chain components

zkEVM: Choice of type

Polygon CDK offers several modes:

Type 2 zkEVM (full EVM compatibility) — any Solidity/EVM bytecode works unchanged. Prover generates ZK-proof of EVM execution equivalence. This is what Polygon zkEVM mainnet beta uses. Overhead: proof generation time (minutes) and verification cost on L1.

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

Sovereign chain — no bridge to Ethereum, own consensus. Maximum independence, minimum 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 batch
    ├── RPC Node — public JSON-RPC for users
    └── State DB — PostgreSQL + Merkle state tree

Setting up own sequencer

Sequencer — central component determining transaction order. In CDK, sequencer runs in centralized mode (you control), giving max performance but requiring trust. Decentralized sequencing — roadmap.

Sequencer configuration

Key parameters in config.yaml:

sequencer:
  # Max batch size (affects latency vs throughput)
  maxBatchSize: 300000  # gas units
  # How often to close batch (seconds)
  batchSealTime: 5
  # Minimum tip for transaction inclusion
  minGasPrice: "1000000000"  # 1 Gwei

  # Gas token: if using your own
  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 main reasons for appchain — gas in own token. CDK supports this via GasTokenAddress parameter on deployment. Users pay gas in your ERC-20 instead of ETH/MATIC.

Important: bridge works differently then. When bridging native token between L1 and L3, CDK uses wrapped representation. Need careful testing of bridge + gas payment scenarios.

ZK Proof generation: Practical aspects

This is the most resource-heavy part. Prover (zkProver) — separate service, generates SNARK-proof for each batch.

Requirements for prover hardware:

• Minimum: 32 CPU cores, 128 GB RAM, no GPU (CPU-based prover)
• Recommended: 64+ cores or GPU (CUDA-accelerated prover)
• Proof generation time: 30 seconds — 5 minutes per batch depending on hardware

Horizontal scaling: multiple prover nodes with Aggregator coordinator. Aggregator distributes batches among prover nodes and aggregates proofs.

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 LxLy bridge — unified Polygon bridge protocol for L1-L2-L3 communication. Supports bridge 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 recorded in L1 Merkle tree
3. CDK chain watches L1, claims deposit automatically (via claimAsset()) or user claims manually

Custom bridge middleware — if KYC-check needed on bridge or amount limits:

// 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, "");
    }
}

Data Availability: Choosing DA layer

In standard CDK config, transaction data published on Ethereum (calldata or EIP-4844 blobs). This is the most secure option, but expensive.

EIP-4844 (Proto-Danksharding) — blob transactions significantly cheaper than calldata. CDK supports blob posting. Savings: 5-10x vs calldata.

Validium / DAC (Data Availability Committee) — data stored with trusted nodes, L1 publishes only commitment (hash). 10-100x cheaper, but requires DAC trust. For enterprise/gaming appchain — 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"

Development and Deployment Process

Phase 1 (1 week): Design. Choose DA mode, gas token, bridge configuration. Define genesis parameters (chainID, initial allocations). Plan infrastructure.

Phase 2 (1-2 weeks): Local deploy and testing. Docker Compose with full stack: L1 (Hardhat/Anvil node), CDK sequencer, prover mock, bridge. End-to-end testing: contract deploy, bridge, transactions.

Phase 3 (1 week): Testnet deploy. Deploy to public testnet (Sepolia L1). Test with real ZK-prover. Load test sequencer.

Phase 4 (1 week): Mainnet prep. Security review of bridge contracts, key management (admin keys, upgrade authority), monitoring, runbook for operators.

Phase 5 (3-5 days): Mainnet deploy. Gradual rollout starting with limited bridge limits.

Total: 5-7 weeks from start to mainnet. Main risks — proof generation time on available hardware and bridge integration bugs.

Infrastructure Cost

Approximate monthly costs for production:

GPU-accelerated prover (A100/H100) gives 5-10x proof generation speedup, but costs $2000-5000/month for rental.