Skip to main content

Security and assurance

This page describes 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. protocol guarantees, operator-controlled security measures, and available assurance evidence.

This page does not include commercial support or SLA commitments, or certify that any custom deployment is secure.

Report a security issue

If you encounter a security vulnerability, do not open a public GitHub issue.

Follow the Lineth and Linea security policy: send a private report to security-report@linea.build, or report a Linea Mainnet issue through the Linea bug bounty on Immunefi. The policy lists what to include in the report.

Protocol-level guarantees​

Under the configured deployment model, Lineth provides:

  • State-transition correctness through zk-SNARKzk-SNARK (Zero-Knowledge Succinct Non-interactive Argument of Knowledge) A type of ZK proof where the prover and verifier don't have to interact. With zk-SNARKs, you can verify 1 transaction or 1 billion transactions in the same amount of time. proof verification 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.. A valid proof means the operator cannot finalize an invalid state transition through the normal proof path.
  • Byzantine fault tolerant consensus for deployments that use QBFTQuorum Byzantine Fault Tolerance (QBFT) The Byzantine-fault-tolerant consensus algorithm that Maru implements to let a validator set produce and finalize blocks. A QBFT validator set requires at least 3f+1 validators to tolerate up to f faulty validators. with 3f+1 validators. Single-validator deployments do not use QBFT and rely on the operator trust model. See Multi-validator consensus.
  • Settlement finality on the selected finalization layer, scoped to that layer's own finality assumptions. A deployment finalizing to Ethereum inherits Ethereum L1 finality; a deployment finalizing to Linea Mainnet inherits Linea Mainnet's finality, which itself anchors to Ethereum.
  • Bridge and message execution gated by verified state commitments. Messages are tied to verified state transitions in the normal protocol path.

For the trust boundaries behind each of these, see Trust and responsibilities.

Operator-controlled security surfaces​

OperatorsOperator 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. define and operate their own security boundary. Lineth does not ship a production security operations program. Operators are responsible for:

  • Infrastructure isolation and network security controls
  • Role-based access control (RBAC) for APIs and services.
  • Key management via KMS-backed signing and remote signing through Web3Signer.
  • Governance contracts or multisig controls for privileged roles, proxy administration, and upgrades.
  • Monitoring and incident response tooling.

Governance contracts and multisig controls should be treated as critical security infrastructure. They can hold privileged roles, coordinate emergency response, or control upgrade authority depending on the deployment. For upgrade mechanics, see the OpenZeppelin Transparent Upgradeable Proxy pattern.

Cryptographic primitives​

The following table outlines the cryptographic primitives Lineth relies on, where they are used in the stack, and what standards they correspond to.

PrimitiveWhere the stack uses itStandard
ECDSA over secp256k1Transaction signing and validator signingEthereum-standard curve.
ECDSA over secp256r1 (P-256)Available to smart contracts through the P256VERIFY precompile (RIP-7212)Curve approved under FIPS 186-5
Keccak-256EVM hashing, state commitments, and role identifiersBased on the Keccak permutation standardized in FIPS 202 (SHA-3 family). Ethereum uses the pre-standardization Keccak-256 padding, not the FIPS 202 SHA3-256 output.
TLSService-to-service and RPC endpointsStandard TLS. Configuration is per deployment.
Key custodyRemote signing through Web3Signer, with optional AWS KMS-backed secp256k1 signingAWS KMS uses FIPS 140-2 and FIPS 140-3 validated HSMs (validations held by AWS). Key custody is a deployment choice.

Available evidence​

The following public materials are the available assurance evidence for the Lineth stack:

Linea Mainnet assurance evidence is listed in Linea Mainnet-specific evidence.

Proof system status​

Lineth does not publish a single proof system maturity rating. Available maturity evidence includes:

  • The documented current proof path: execution, compression, and aggregation proofs. See Prover architecture.
  • The trusted setup and its security assumptions.
  • The prover implementation published in the Lineth monorepo.
  • Audit reports for the prover, proving libraries, and cryptographic primitives, which apply to the revisions named in each report.

RISC-V proving is under development and is not part of any current Lineth deployment.

Linea Mainnet-specific evidence​

The following materials apply to Linea Mainnet. Linea Mainnet is built on Lineth, so these materials can help you evaluate the Lineth stack. They do not certify the security of custom Lineth deployments.

What is not published​

Lineth does not currently publish a consolidated findings disposition, a mapping from every current release to its applicable audits, a proof system maturity rating, or assurance conclusions for custom deployments.

Organizations evaluating a deployment must assess the applicable software versions, configuration, infrastructure, governance, and operational controls separately.

Was this page helpful?