> For the complete Linea documentation index, see [llms.txt](/llms.txt). > Agents can fetch this page as Markdown at [https://docs.linea.build/stack/evaluate/security.md](https://docs.linea.build/stack/evaluate/security.md). # Security and assurance This page describes [Lineth](/protocol/reference/zero-knowledge-glossary#lineth)**Lineth** (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](https://github.com/LFDT-Lineth/lineth-monorepo/blob/main/docs/security.md): send a private report to [security-report@linea.build](mailto:security-report@linea.build), or report a Linea Mainnet issue through the [Linea bug bounty on Immunefi](https://immunefi.com/bounty/linea/). The policy lists what to include in the report. ## Protocol-level guarantees Under the configured deployment model, Lineth provides: - State-transition correctness through [zk-SNARK](/protocol/reference/zero-knowledge-glossary#zk-snark)**zk-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 layer](/protocol/reference/zero-knowledge-glossary#finalization-layer)**Finalization 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 [QBFT](/protocol/reference/zero-knowledge-glossary#quorum-byzantine-fault-tolerance-qbft)**Quorum 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. with `3f+1` validators. Single-validator deployments do not use QBFT and rely on the operator trust model. See [Multi-validator consensus](/stack/deployment/distributed-sequencing). - 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](/stack/evaluate/trust-model). ## Operator-controlled security surfaces [Operators](/protocol/reference/zero-knowledge-glossary#operator)**Operator** 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 - [Access control](/stack/deployment/access-control) for JSON-RPC, APIs, and tooling. - Key management via KMS-backed signing and remote signing through [Web3Signer](/protocol/architecture#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](/protocol/architecture/smart-contracts#contract-versioning). ## 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. | Primitive | Where the stack uses it | Standard | | --- | --- | --- | | ECDSA over secp256k1 | Transaction signing and Maru validator signing | Ethereum-standard curve. | | ECDSA over secp256r1 (P-256) | Available to smart contracts through the `P256VERIFY` precompile ([RIP-7212](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md)) | Curve approved under [FIPS 186-5](https://csrc.nist.gov/pubs/fips/186-5/final) | | Keccak-256 | EVM hashing, state commitments, and role identifiers | Based on the Keccak permutation standardized in [FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) (SHA-3 family). Ethereum uses the pre-standardization Keccak-256 padding, not the FIPS 202 SHA3-256 output. | | TLS | Service-to-service and RPC endpoints | Standard TLS. Configuration is per deployment. | | Key custody | Remote signing through [Web3Signer](/protocol/architecture#web3signer), with optional AWS KMS-backed secp256k1 signing | AWS 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: - [Prover architecture](/protocol/architecture/prover): The documented current proof path - [Trusted setup](/protocol/architecture/prover/trusted-setup): The public multi-party computation (MPC) ceremonies and structured reference strings used by the proving system - [Security audits](/protocol/reference/security-audits): The published audit reports for reviewed components and revisions - [Trust and responsibilities](/stack/evaluate/trust-model): Component-level trust boundaries and failure modes - [Smart contracts](/protocol/architecture/smart-contracts): The onchain contracts a deployment uses - [Source repositories](/protocol/reference/repos): The public Lineth source Linea Mainnet assurance evidence is listed in [Linea Mainnet-specific evidence](#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](/protocol/architecture/prover). - The [trusted setup](/protocol/architecture/prover/trusted-setup) and its security assumptions. - The prover implementation published in the [Lineth monorepo](https://github.com/LFDT-Lineth/lineth-monorepo/tree/main/prover). - [Audit reports](/protocol/reference/security-audits) for the prover, proving libraries, and cryptographic primitives, which apply to the revisions named in each report. [RISC-V proving](/protocol/architecture/prover/risc-v-overview) 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. - [Risk disclosures](/network/risk-disclosures) - [Security Council transaction record](/changelog/security-council-record) - [Deployed contract addresses](/network/build/contracts) - Linea Mainnet operational history and the [Immunefi bug bounty](https://immunefi.com/bug-bounty/linea/information/) ## 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.