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 thecdk-opgeth architecture page; 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 isAggchainECDSAMultisig, 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.
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 sameAggchainECDSAMultisig 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
- Overview for the section framing, the responsibility matrix, and the Jira intake fields.
- Environments and contract addresses for the public endpoints and L1 addresses you will configure tooling against.
- Integration flow for the end-to-end journey from Jira intake to a live chain.