> 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.md](https://docs.linea.build/stack/evaluate.md). # Evaluate Lineth This page describes Lineth capabilities that matter when evaluating a deployment, and points to the pages that go deeper on each one. For design choices and operator responsibilities, continue to [deployment architecture](/stack/deployment). ## What Lineth provides Lineth is a ZK-rollup stack. A deployment combines a consensus layer, an execution layer, a Prover, a Coordinator, and a set of onchain contracts on a finalization layer. Operators choose the deployment model, data availability arrangement, finalization layer, and access controls. The following capabilities depend on the deployment model chosen. ## Deployment model capabilities Using Lineth, an operator can deploy: - Public networks, such as Linea Mainnet, with onchain data availability - Private validium networks, with offchain data availability and controlled access For the trade-offs between these models, see [Deployment models](/stack/evaluate/deployment-models). ## Protocol capabilities ### State transition correctness Lineth uses zk-SNARK proofs to verify that state transitions are valid. A valid proof means the operator cannot finalize an invalid state transition through the normal proof path. Proofs do not by themselves make transaction contents private; data visibility depends on the deployment's data availability and access model. For the data-visibility distinction, see [Privacy and data visibility](/stack/evaluate/validium). ### EVM-compatible execution Lineth runs EVM-compatible contract execution, so existing Solidity contracts and Ethereum tooling generally work. Compatibility is constrained by the deployment's configuration and by the differences between any chain and Ethereum. For the differences between Linea and Ethereum, see [Linea and Ethereum](/network/overview/ethereum-differences). ### Quorum-Based Byzantine Fault Tolerance consensus For deployments that use multi-validator consensus, Lineth supports Quorum-Based Byzantine Fault Tolerance (QBFT), which provides: - Fault tolerance with `3f+1` validators, tolerating `f` faulty validators - Single-slot finality under the deployment's QBFT safety assumptions - Distributed block production when enough validators participate Single-validator deployments do not use QBFT and rely on the operator trust model instead. For design trade-offs, topology, and latency, see [Multi-validator consensus](/stack/deployment/distributed-sequencing). For trust assumptions per model, see [Trust and responsibilities](/stack/evaluate/trust-model). ### Dual-layer architecture Lineth separates consensus and execution. This lets operators choose different client configurations and scale consensus and execution independently. It does not by itself provide client diversity or network resilience; those depend on the operator's deployment. ## Where to go next | Question | Page | | --- | --- | | Who operates what, and what can each component do? | [Trust and responsibilities](/stack/evaluate/trust-model) | | Who can see what data? | [Privacy and data visibility](/stack/evaluate/validium) | | What does the protocol guarantee, and what evidence exists? | [Security and assurance](/stack/evaluate/security) | | What protocol evidence can operators use for compliance design? | [Compliance](/stack/evaluate/compliance) |