<!-- Canonical: https://docs.linea.build/stack/deployment/core-components -->

> For the complete Linea documentation index, see [llms.txt](/llms.txt).
> Agents can fetch this page as Markdown at [https://docs.linea.build/stack/deployment/core-components.md](https://docs.linea.build/stack/deployment/core-components.md).

# Deployment components

This page describes the Lineth (formerly the Linea Stack) components. It identifies which components an operator must or may run, and describes how they are versioned or replaced. For what each component does internally, see the [Protocol architecture](/protocol/architecture).

## Core protocol components

The following components are **required**.

**Replaceability:** Versioned via protocol upgrade.

-   [Maru](/protocol/architecture#consensus-client-maru): Consensus layer client
-   [Linea Besu](/protocol/architecture#execution-client-linea-besu): Execution layer client
-   [Sequencer](/protocol/architecture/sequencer): Orders transactions and builds blocks
-   [Coordinator](/protocol/architecture/coordinator): Orchestrates batching, proof generation, and submissions
-   [Prover](/protocol/architecture/prover): Generates zero-knowledge proofs of state transitions
-   [State manager](/protocol/architecture/state-manager): Maintains a state representation for proof generation
-   [Tracer](/protocol/architecture/sequencer/traces-generator): Generates execution traces required for proofs

## Onchain system contracts

The following [smart contracts](/protocol/architecture/smart-contracts) or alternatives that offer parity are **required**.

**Replaceability:** Versioned via redeployment.

-   `AddressFilter` contract
-   Canonical token bridge
-   Finalization verifier
-   `LineaRollup` message bridge contract
-   Token bridge contracts

## Data availability

In addition to concrete components, Lineth depends on correctness-critical requirements, which may be satisfied by different implementations depending on the [deployment model](/stack/evaluate/deployment-models).

**Purpose**

-   Ensure transaction data and state transitions remain accessible
-   Enable reconstruction and verification of historical state

**Correctness requirement**

-   Without data availability, the protocol cannot be independently verified
-   Loss of data availability breaks state reconstructability

**Example implementations**

-   **Linea Public Mainnet deployment:** EIP-4844 blobs on Ethereum
-   **Private Validium deployments:** Operator-provided or outsourced data availability infrastructure

**Trust model**

-   Data availability is within the trust boundary
-   Responsibility for data availability implementation depends on deployment model

See more on [data availability considerations](/stack/deployment/data-availability-finalization).

## Auxiliary services

Auxiliary services are **not required for protocol correctness**. They are typically **optional** and **replaceable**.

Common examples include:

-   [Block explorer](/protocol/architecture#block-explorer)
-   [Archive node service](/protocol/architecture/rpc-services#archive-nodes)
-   [RPC load balancers](/protocol/architecture/rpc-services#what-do-they-do)
-   Monitoring and metrics
-   Indexer
-   API portal

**Special cases**

-   [Web3Signer](/protocol/architecture#web3signer): remote signing with integration with a large number of Key Management Solutions (KMS):
    -   Not required for correctness
    -   _In_ trust boundary (signing path)
    -   Not replaceable: currently, Web3Signer is integral
    -   Optional