Skip to main content
This page maps the components a RaaS provider operates against the components Polygon operates, and describes the four practical deployment modes from an operator lens. Read this before the integration flow so the runbook steps are anchored in the architecture they touch.

​
Components you run vs. components Polygon runs

An Agglayer-connected CDK chain is a shared system. The Integration Partner runs the chain-side stack: the trusted sequencer, the components that talk to Agglayer, the bridge indexer, and any mode-specific extras such as a Validium DAC. Polygon operates Agglayer itself and the L1 contracts the chain attaches to. The tables below list the operational ownership boundary. For per-mode component tables and repository link references, see the cdk-opgeth architecture page for OP Stack chains and the CDK Besu page for Besu chains; this page does not duplicate those tables.

​
You run

​
Polygon runs

The proposer-only role is the most important operational distinction at the multisig boundary: the Integration Partner can submit attachAggchainToAL proposals on the Safe, but only Polygon signers can review, approve, and execute them.

​
Deployment modes

Every Agglayer-connected CDK chain runs in one of four practical modes. Three of them share the same consensus implementation (AggchainECDSAMultisig, AGGCHAIN_TYPE = 0x0000) and differ in data availability and prover topology. The fourth, AggchainFEP (AGGCHAIN_TYPE = 0x0001), is the OP-stack fault-proof integration and is the only mode that requires the Integration Partner to operate prover infrastructure. For Sovereign, Validium, and zkRollup modes, the consensus implementation is AggchainECDSAMultisig with AGGCHAIN_TYPE = 0x0000. For OP-stack fault-proof integrations the value is AGGCHAIN_TYPE = 0x0001 (AggchainFEP). The AGGCHAIN_TYPE value selects the rollupTypeId you reference during chain attachment.

​
Sovereign (AggchainECDSAMultisig)

Sovereign is the default mode and the lowest-overhead path to Agglayer connectivity. Settlement is secured by pessimistic proofs rather than a zk validity proof, so the Integration Partner does not operate a prover. The consensus implementation is AggchainECDSAMultisig, with AGGCHAIN_TYPE = 0x0000. From an operator standpoint, you run the trusted sequencer, AggKit, and the bridge indexer; you do not need a DAC or a prover. Sovereign is the only mode available to CDK Besu chains. On a CDK Besu chain, Besu validators running QBFT consensus produce blocks, and a separate Besu RPC node serves AggKit, the bridge service, and users. The cdk-besu runbook covers the full component set, including an optional consortium configuration in which several members share block production and certificate approval.

​
Validium (AggchainECDSAMultisig)

Validium shares the sovereign consensus path (AggchainECDSAMultisig, AGGCHAIN_TYPE = 0x0000) but uses an alternative data availability layer instead of posting transaction data to Ethereum. Operationally, the difference is that the Integration Partner stands up and operates a DAC committee that signs and serves offchain data. You do not need a prover.

​
zkRollup (AggchainECDSAMultisig)

zkRollup posts transaction data onchain to Ethereum and uses the same AggchainECDSAMultisig consensus implementation (AGGCHAIN_TYPE = 0x0000). The Integration Partner does not run a prover; proving infrastructure is supplied by the existing CDK prover stack; see the cdk-opgeth architecture page for the component tables. The operator footprint is essentially sovereign plus the higher L1 cost of full onchain data.

​
AggchainFEP

AggchainFEP is the OP-stack fault-proof integration and uses a different consensus implementation: AGGCHAIN_TYPE = 0x0001. This is the only mode where the Integration Partner participates in prover operation: AggchainFEP chains run an SP1-based zkVM prover for fault-proof challenges. The Integration Partner stack includes the SP1 prover and the OP-stack components alongside the standard trusted sequencer and AggKit.

​
Where to go next