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; this page does not duplicate those tables.
You run
| Component | Description |
|---|
| Trusted sequencer | The L2 sequencer that orders transactions and proposes certificates to Agglayer. |
| AggKit (aggsender) | Sends signed certificates from the chain to the Agglayer node. The trusted sequencer acts as the aggsender proposer. |
| AggKit (aggoracle) | Updates the Global Exit Root (GER) onchain so the chain stays in sync with Agglayer state. |
| RPC | Public read/write endpoint for your chain. |
| Bridge service indexer | Indexes L1 and L2 bridge events to serve claim and deposit data to applications. |
| DAC committee (Validium only) | The data availability committee that signs and serves offchain transaction data. |
Polygon runs
| Component | Description |
|---|
| Agglayer node | The core Agglayer service that aggregates certificates from connected chains. |
AgglayerManager and rollup contracts on L1 | The L1 contracts (formerly RollupManager) that your chain attaches to and that the Agglayer settles against. |
| Signer infrastructure for the chain-attachment multisig | The full-signer role on the Safe that executes attachAggchainToAL. The Integration Partner has the proposer-only role. |
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.
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
