Trust model

This page describes the trust model in a 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. deployment: what each component can do, what participants can verify, privileged contract roles, and how to recover when a dependency fails.

For protocol guarantees and operator-controlled security measures, see Security and assurance.

Trust assumptions

In a public deployment and 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., the 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. runs the deployment components. In both deployment models, the components can take these actions:

• The sequencerSequencer The set of Linea Besu plugins responsible for ordering, building, and executing blocks in a way that allows the subsequent ZK proof to be made, including the tracer. The sequencer is a plugin set rather than a standalone process; a node that runs it alongside a Maru validator is a sequencer node. can order, delay, or omit transactions within a block.
• The 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. can stall proof generation, which halts finalization.
• The 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. can stall the pipeline that conflates blocks, requests proofs, and submits them to 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..
• The system contractsSystem contracts The onchain contracts Lineth deploys on the finalization layer and on the network. They include the finalization contract, which calls a verifier to check proofs and records the finalized state, and the message service and token bridge contracts, which move messages and tokens between the two chains. can pause subsystems, change the verifier address, change rate limits, and upgrade contracts through the proxy upgrade path (and, on a 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., pause and upgrade contract roles).

In both models, the components cannot:

• Forge state. Invalid blocks fail proof verification.
• Produce a valid proof for an invalid state transition.
• Modify state independently of the sequencer or prover.
• Process canonical bridge messages that are not tied to a verified state commitment, unless a privileged role upgrades or reconfigures the contracts.
• Bypass the contract roles in the deployed implementation. Privileged functions require the matching role.

Each participant can read state visible to them and broadcast transactions. They cannot modify network state. What a participant can see through the operator's RPC depends on the deployment's access control configuration. Access control does not hide data already posted onchain.

When the deployment uses QBFTQuorum Byzantine Fault Tolerance (QBFT) The Byzantine-fault-tolerant consensus algorithm that Maru implements to let a set of Maru validators produce and finalize blocks. A QBFT validator set requires at least 3f+1 validators to tolerate up to f faulty validators., block production depends on the validator set: with 3f+1 validators, at most f can fail or deviate. See Multi-validator consensus.

What participants can verify

In every deployment, participants can check that a proof was accepted by reading the finalization contract on the finalization layer. They can also read submission events, contract role assignments, contract state, proxy admin, implementation addresses, and canonical bridge events on that layer.

In a public deployment, transaction data is posted onchain to the finalization layer. While that data remains available, the operator cannot withhold data availability. When the finalization layer is Ethereum, transaction data is posted as EIP-4844 blobs. Participants can reconstruct state from those blobs while they are retained; long-term reconstruction needs independent archival. Participants can also verify public rollup block contents and ordering by running a full nodeFull node A node that runs Maru paired with at least one execution client and validates the chain block by block, executing and verifying every block it imports. A full node keeps recent state and prunes older data, which it can regenerate on demand; an archive node is a full node that retains state at every block from genesis. Running a full node is independent of consensus role: a full node can run a Maru validator or a Maru non-validator, and may or may not serve JSON-RPC., and can verify their own observed state from that public data.

In 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., transaction data stays offchain. Data availability (DA) is operated by archive nodesArchive node A full node that retains state at every block from genesis, alongside the blocks and transactions themselves, so it can reconstruct chain state at any past block height. Archive nodes trade minimal latency and modest storage requirements for completeness, supporting auditing, forensics, and analytics. or a DA committee. Those providers can withhold data, which halts recovery, but they cannot forge state, because proofs still verify on the finalization layer. Participants can verify data and state claims they are authorized to access, including checks with Merkle proofs against posted state roots. A Merkle proof can support inclusion of authorized data. It does not by itself establish global transaction ordering for participants who do not have the full ordered data set.

Trusted bridge

A deployment's operator and a trusted relayer may operate a bridge to a private or non-anchored chain. The operator holds the contract roles that can pause or upgrade the bridge. The relayer can withhold or delay messages. In the normal relayer path, the bridge cannot process messages that are not signed over source-chain events. Participants can verify bridge events on each side. There is no shared proof, so verifiability depends on trust in the relayer, its keys, and those pause and upgrade roles.

Finalization layer

A deployment inherits its finalization layer's finality. The deployment carries its own sequencer, prover, contract role, and verifier assumptions.

If the finalization layer is Linea Mainnet, the deployment also depends on Linea Mainnet operating the same component stack, plus Linea's Security Council and its bridge to Ethereum. Verifying the chain end-to-end requires verifying both the deployment's proof on Linea Mainnet and Linea Mainnet's proofs on Ethereum. See Linea Mainnet risk disclosures.

System contract roles

The system contractsSystem contracts The onchain contracts Lineth deploys on the finalization layer and on the network. They include the finalization contract, which calls a verifier to check proofs and records the finalized state, and the message service and token bridge contracts, which move messages and tokens between the two chains. use onchain roles to gate privileged functions: pause, finalize, change the verifier, and grant other roles. The protocol defines what each role can do. The operator chooses which addresses hold them at deploy time.

Replacing the contract implementation is a separate power. It belongs to whoever controls the proxy admin, not automatically to DEFAULT_ADMIN_ROLE.

In production deployments, both role holders and proxy admin control should sit behind a multisig, governance contract, or timelock, and may involve multiple independent parties.

Role	What it can do	Recommended holder
DEFAULT_ADMIN_ROLE	Grant or revoke other 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. The Linea Security Council transaction record shows a public Linea example of multisig-governed role and upgrade operations.

warning

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.

Role constants are defined on the smart contract reference pages, including LineaRollup, ZkEvmV2 (OPERATOR_ROLE), LineaRollupPauseManager, and RateLimiter (RATE_LIMIT_SETTER_ROLE). Linea Mainnet deployed addresses are on Contracts.

Failures and recovery

If the sequencer, prover, or coordinator stalls, the operator restarts the affected service or fails over to redundant infrastructure. See High availability.

Each failure has the following effect on participants:

• Sequencer halt: Block production stops, and pending transactions are not included. In a multi-validator deployment, restore quorum as described in Set up distributed sequencing.
• Prover stall: Proofs are not generated and finalization stops. Soft-finalized blocks remain on the Lineth network.
• Coordinator stall: Submission to the finalization layer stops, with the same downstream effect as a prover stall.
• Finalization layer reorg: Wait for the required finality depth on the finalization layer.
• Admin key compromise: The compromised role can act within its scope until revoked. DEFAULT_ADMIN_ROLE compromise affects all roles. Revoke or rotate authority through the deployment's governance or multisig process, and use emergency pause roles where available.
• Data availability (DA) withheld in a private validium: Participants without the required DA or access control permissions cannot reconstruct or verify affected private data. Operators define a wind-down procedure (this depends on a consortium agreement and is not enforced by the Lineth protocol).

See also

• Security and assurance: Protocol guarantees, operator controls, and published assurance evidence.
• Deployment models: Comparison and tradeoffs between a public deployment and private validium.