> ## Documentation Index > Fetch the complete documentation index at: https://docs.polygon.technology/llms.txt > Use this file to discover all available pages before exploring further. # Components Overview > The 7 AggKit components, their roles, dependencies, and which combinations are appropriate for different deployment scenarios ## Modular Design AggKit consists of 7 specialized components. Rather than a single monolithic service, each component handles a specific responsibility. This means you deploy only the components your use case requires. * **Basic Agglayer connectivity**: 2 components (AggSender + AggOracle) * **Full bridge infrastructure**: 5 components (add BridgeSync, L1InfoTreeSync, L2GERSync) * **Bridge API services**: 4 components (BridgeSync, L1InfoTreeSync, L2GERSync, Bridge Service) * **Advanced state transition proofs**: Add AggchainProofGen ## Communication Components These two components are required for any chain connecting to Agglayer. ### AggSender AggSender packages L2 state transitions into cryptographically signed certificates and submits them to Agglayer. On each Agglayer epoch, it collects bridge events from BridgeSync and L1 verification data from L1InfoTreeSync, builds a certificate containing bridge exits and imported bridge exits, signs it, and submits it to Agglayer for Pessimistic Proof generation. Without AggSender, a chain cannot participate in Agglayer's security guarantees or cross-chain coordination. ### AggOracle AggOracle monitors the Global Exit Root contract on Ethereum L1, detects new GER updates, and injects those updates into the L2 chain's Global Exit Root Manager contract. This keeps the chain's local copy of global state current, which is required for verifying incoming cross-chain claims. In v0.3.5, AggOracle operates in committee mode: multiple independent instances must agree on a new GER before it is injected into the L2 contract, eliminating the single-address vulnerability of earlier versions. ## Synchronization Components These components maintain the data that AggSender and AggOracle depend on. ### L1InfoTreeSync L1InfoTreeSync monitors Ethereum L1 and maintains two Merkle trees locally: * **L1 Info Tree**: An append-only tree of historical Global Exit Roots, sourced from `UpdateL1InfoTree` events on the Global Exit Root contract * **Rollup Exit Tree**: A tree of L2 Local Exit Roots, sourced from `VerifyBatches` events on the Rollup Manager contract These trees provide the Merkle proofs that AggSender includes in certificates and that AggOracle uses for GER detection. ### L2GERSync L2GERSync indexes GER injections on the L2 side. When AggOracle writes a new GER to the L2 Global Exit Root Manager contract, L2GERSync captures the event and stores it locally. This local index enables fast GER lookups during claim verification and API responses without requiring onchain queries. ### BridgeSync BridgeSync monitors bridge contracts on both L1 and L2, captures every `BridgeEvent` and `ClaimEvent`, and organizes them into a local database. It provides the bridge exit and imported bridge exit data that AggSender uses for certificate construction, and the transaction history that Bridge Service exposes through its API. ## Service Components These components extend AggKit with external-facing capabilities. ### Bridge Service Bridge Service exposes a REST API over BridgeSync's data. It provides endpoints for bridge transaction status, token mappings, and Merkle proof generation. Applications such as wallets, block explorers, and DeFi protocols use Bridge Service to query bridge data without running the full AggKit infrastructure. ### AggchainProofGen AggchainProofGen generates state transition proofs for chains that require mathematical verification of internal operations rather than simple ECDSA signature authorization. It verifies the chain's consensus (either ECDSA signature or validity proof), verifies bridge constraints, and produces an Aggchain Proof that AggSender includes in its certificate. See [State Transition Proof](/interoperability/agglayer/core-concepts/state-transition-proof/) for the full context of when this is needed. ## Component Dependencies ## Individual component pages Certificate generation, epoch-based operation, and the certificate lifecycle. GER propagation, direct injection vs. committee mode, and the v0.3.5 security change. Bridge event monitoring, data indexing, event types, and integration with AggSender and Bridge Service. The two Merkle trees maintained, event sources, Merkle proof generation, and integration with AggSender and AggOracle. Local GER state management on the L2 side, indexing workflow, and how it supports claim verification. State transition proof generation for chains requiring mathematical verification of internal operations.