Trust and responsibilities
This page describes who operates each LinethLineth (Formerly the Linea Stack) The open-source ZK-rollup stack, codebase, and technical protocol that's the foundation of Linea Mainnet. Operators can deploy this stack to launch their own Ethereum-compatible L2 or L3 networks. component, what each component can do, what participants can verify, what happens when dependencies fail, and how trust assumptions change across deployment models.
For more information on deployment topology, see Deployment components and Deployment models.
Trust assumptions per component
| Component | Operated by | Can do unilaterally | Cannot do | Independently verifiable by participants |
|---|---|---|---|---|
| SequencerSequencer The component of the Lineth execution client responsible for ordering, building, and executing blocks in a way that allows the subsequent ZK proof to be made. It's implemented as a set of plugins extending Linea Besu, including the tracer. There's typically one sequencer per network. | OperatorOperator The entity or consortium responsible for deploying, administering, and running the network infrastructure, contracts, keys, access controls, and operational procedures for a network built on Lineth. | Order, delay, or omit transactions within a block | Forge state, since invalid blocks fail proof verification | Public rollup block contents and ordering by running a full or archive node; in validiumValidium A deployment model in which a Lineth network proves state transitions with zk-SNARKs but keeps transaction data in a private data availability layer instead of publishing it to the finalization layer. Only state commitments and proofs are posted onchain, so participants without access to the offchain data can't independently reconstruct or verify the full transaction history. or RBAC deployments, transactions or blocks only to the extent participants have the relevant data and access |
| ProverProver The Lineth component that generates ZK proofs of state transitions, handling proof-generation requests from the coordinator and Linea Besu. The prover produces three types of proofs (execution, compression, and aggregation) and combines them into a zk-SNARK that the finalization layer verifies. Provers may be scaled horizontally to meet throughput requirements. | Operator | Stall proof generation, halting finalization | Produce a valid proof for an invalid state transition | Proof verification by reading the verifier contract on the finalization layerFinalization layer The blockchain where a Lineth deployment submits proofs and state commitments for verification and hard finality. If the finalization layer is Ethereum (an L1), the deployment is an L2. If the finalization layer is Linea (an L2), the deployment is an L3. |
| CoordinatorCoordinator Lineth's coordination module for batching, proof generation, and finality submission. The coordinator monitors block production, manages conflation deadlines, batches blocks, combines batches into blobs, orchestrates execution, compression, and aggregation proofs, and submits proofs and data to the finalization layer. | Operator | Stall the pipeline that conflates blocks, requests proofs, and submits them to the finalization layer | Modify state independently of the sequencer or prover | Submission events on the finalization layer |
| Data availability (rollup) | Ethereum | N/A | Withhold data, since DA is on L1 as EIP-4844 blobs | State reconstruction from L1 blobs |
| Data availability (validium) | Operator-run archive nodes or DA committee | Withhold data, halting recovery | Forge state, since proofs still verify on the finalization layer | Data and state claims that participants are authorized to access, including checks with Merkle proofs against posted state roots |
| Canonical bridgeCanonical token bridge The pair of "lock and mint" contracts that let any ERC-20 token bridge between a Lineth network and its finalization layer, which for Linea Mainnet means between Linea and Ethereum. It relies on the canonical message service for its cross-chain interactions. (to Ethereum / Linea-anchored chain) | Operator (admin keys) + protocol (proofs) | Pause bridging via pause roles; upgrade contracts through the proxy upgrade path | In the normal protocol path, process unproved messages, since messages are tied to verified state transitions | Bridge events, proof verification, role assignments, proxy admin, and implementation addresses on the finalization layer |
| Trusted bridge (to private or non-anchored chain) | Operator (admin keys) + trusted relayer | Pause bridging; relayer can withhold or delay messages | In the normal relayer path, process messages that are not signed over source-chain events | Bridge events on each side; no shared proof, so verifiability depends on trust in the relayer, its keys, and the bridge upgrade/admin model |
| System contracts | Operator (role holders) + proxy upgrade authority | Pause, change verifier address, change rate limits, and upgrade contracts through the proxy upgrade path | Bypass role gating in the deployed implementation, since privileged functions are role-gated | Role assignments, contract state, proxy admin, and implementation addresses on the finalization layer |
| Participant nodes | Each participant | Read state visible to them, broadcast transactions | Modify network state | Their own observed state, subject to the deployment's data access model; not every participant in a validium or RBAC deployment necessarily runs a full or archive node |
Admin keys and upgrade authority
The Stack contracts ship with a fixed set of roles. Holders are decided by the operator at deploy time. A governance contract is the high-security onchain control path that can hold privileged roles or proxy admin authority for a deployment. In production-oriented deployments, governance and upgrade authority should sit behind an appropriately secured multisig, governance contract, or timelock, and may involve multiple independent parties.
| Role | What it can do | Recommended holder |
|---|---|---|
DEFAULT_ADMIN_ROLE | Grant or revoke AccessControl roles | High-security multisig or governance contract; initial holder set during initialization |
OPERATOR_ROLE | Submit blobs/calldata, finalize blocks | Day-to-day operator address |
SECURITY_COUNCIL_ROLE | Reserved for governance pause/upgrade authority | High-security governance contract or multisig |
PAUSE_*_ROLE / UNPAUSE_*_ROLE | Pause and unpause specific subsystems (L1↔L2, L2→L1, finalization, state submission, etc.) | Split between operator (pause) and governance (unpause) for fast incident containment |
VERIFIER_SETTER_ROLE | Change the verifier contract for a given proof type | Governance contract |
RATE_LIMIT_SETTER_ROLE | Change L2→L1 withdrawal rate limits | Governance contract |
Contracts are upgradeable via the OpenZeppelin Transparent Upgradeable Proxy pattern. Proxy upgrade authority is separate from DEFAULT_ADMIN_ROLE and depends on who controls the proxy admin or governance contract for the deployment. Operators should place upgrade authority behind an appropriate multisig, governance contract, or timelock. The Linea Security Council transaction record shows a public Linea example of multisig-governed security and upgrade operations.
DEFAULT_ADMIN_ROLE cannot be assigned through __Permissions_init. The initial holder is set via the explicit defaultAdmin initializer field. Plan the initial holder before initialization.
For the full list of roles, see LineaRollup contracts reference.
Trust assumptions per deployment model
| Trust dimension | Public rollup on Ethereum | Private validium on Ethereum | Private validium on Linea Mainnet |
|---|---|---|---|
| Data availability provided by | Ethereum (EIP-4844 blobs) | Operator-run archive nodes or DA committee | Operator-run archive nodes or DA committee |
| Finalization layer | Ethereum | Ethereum | Linea Mainnet (which itself anchors to Ethereum) |
| Bridge trust to the finalization layer | Canonical bridge: ZK proofsZero-knowledge proof A cryptographic method that allows an individual to prove that a statement is true without conveying any additional information. This is useful for scaling blockchain networks through rollups, because it reduces the amount of information you have to provide to lower layers., plus admin and upgrade authority for pauses, verifier configuration, and contract upgrades | Same as rollup | Canonical bridge to Linea Mainnet (proofs plus admin and upgrade authority), plus Linea Mainnet's own bridge and governance assumptions |
| Inherited trust assumptions | Ethereum L1 finality, plus the deployment's sequencer, prover, admin key, verifier configuration, and upgrade-authority assumptions | Ethereum L1 finality, plus the deployment's sequencer, prover, admin key, verifier, upgrade, and DA assumptions | Ethereum L1 + Linea Mainnet finality, plus Linea Mainnet sequencer, prover, Security Council, admin key, verifier, upgrade, and bridge assumptions |
| State reconstruction without operator | Yes, while L1 blob data is available; long-term reconstruction requires independent archival of EIP-4844 blob data | No, depends on operator-run DA and the deployment's data access model | No, depends on operator-run DA and the deployment's data access model |
A private validiumValidium A deployment model in which a Lineth network proves state transitions with zk-SNARKs but keeps transaction data in a private data availability layer instead of publishing it to the finalization layer. Only state commitments and proofs are posted onchain, so participants without access to the offchain data can't independently reconstruct or verify the full transaction history. on Linea Mainnet inherits Linea Mainnet's trust assumptions in addition to its own. See Linea Mainnet risk disclosures for those.
Failure modes and recovery
| Failure | Participant impact | Recovery path |
|---|---|---|
| Sequencer halt | Block production stops; pending transactions not included | Operator restart or failover to redundant sequencer infrastructure. In distributed sequencing or validator consensus deployments, recovery follows the configured QBFT or validator process. |
| Prover stall | Proofs not generated; finalization stops; soft-finalized blocks remain on L2 but not finalized to the finalization layer | Operator restart or failover to an alternate prover instance where deployed |
| Coordinator stall | Submission to the finalization layer stops; same effect as prover stall downstream | Operator restart or failover to an alternate coordinator instance where deployed |
| DA withhold (validium) | Participants without the required DA or RBAC access cannot reconstruct or verify affected private data | Operator-defined wind-down procedure; depends on consortium agreement and is not protocol-enforced |
| Finality layer reorg | Affects depth of finality on the selected finalization layer | Wait for the required finality depth on the selected finalization layer |
| Admin key compromise | Compromised role can act within its scope until revoked; DEFAULT_ADMIN_ROLE compromise affects all roles | Revoke or rotate compromised authority through the deployment's governance or multisig process; use emergency pause roles where available |
What participants can independently verify
The set of guarantees a participant can verify without trusting the operator depends on the deployment model.
Public rollup on Ethereum
- Proof validity and state-transition correctness, by reading the verifier contract on L1. A valid proof means the operator cannot finalize an invalid state transition through the normal proof path.
- Full transaction history while L1 blobs are retained, by reading L1 blobs and reconstructing L2 state. After EIP-4844 blob expiry, long-term reconstruction depends on independent archival of blob data.
- Bridge events and message status, on L1.
- Contract role assignments and admin actions, on L1.
Private validiumValidium A deployment model in which a Lineth network proves state transitions with zk-SNARKs but keeps transaction data in a private data availability layer instead of publishing it to the finalization layer. Only state commitments and proofs are posted onchain, so participants without access to the offchain data can't independently reconstruct or verify the full transaction history. on Ethereum
- Proof validity and state-transition correctness, by reading the verifier contract on L1. A valid proof means the operator cannot finalize an invalid state transition through the normal proof path.
- That a state transition was proved, even if its transaction contents are private.
- Transactions or blocks they are authorized to access, using the relevant data and Merkle proofs against posted state roots. This does not by itself establish global transaction ordering for participants who do not have access to the full ordered data set.
- Bridge events on L1.
- Their own observed state, by running a node or using an authorized interface where the deployment grants access.
- They cannot reconstruct full state or history without the required operator DA access. This is the validium trade-off, and RBAC settings may further limit which data each participant can observe.
Private validiumValidium A deployment model in which a Lineth network proves state transitions with zk-SNARKs but keeps transaction data in a private data availability layer instead of publishing it to the finalization layer. Only state commitments and proofs are posted onchain, so participants without access to the offchain data can't independently reconstruct or verify the full transaction history. on Linea Mainnet
- Proof validity and state-transition correctness, by reading the verifier contract on Linea Mainnet. A valid proof means the operator cannot finalize an invalid state transition through the normal proof path.
- Same validium and RBAC caveats as private validium on Ethereum, but proofs are verified on Linea Mainnet (which is itself proved to Ethereum).
- Verifying the chain end-to-end requires verifying both the private validium proof on Linea Mainnet and Linea Mainnet's proofs on Ethereum.
See also
- Linea Mainnet risk disclosures: applies when finalizing to Linea Mainnet
- Core components
- Deployment models
- Security and assurance
- LineaRollup contracts reference
- Merkle trees
- Linea Security Council transaction record