Consensys-Incorporated · alexandratran · Sep 17, 2026 · Sep 18, 2026 · Sep 28, 2026 · Sep 29, 2026
diff --git a/docs/stack/deployment/access-control.mdx b/docs/stack/deployment/access-control.mdx
@@ -158,5 +158,3 @@ They do not receive a view of private contracts or transaction data.
 
 - [Native interoperability](./interoperability.mdx): How two access controlled Lineth networks communicate
   with each other using the Cross Ledger Interoperability Protocol (CLIP).
-- [Privacy and data visibility](../evaluate/validium.mdx): How private validium deployments use offchain
-  data availability and controlled access.
diff --git a/docs/stack/evaluate/compliance.mdx b/docs/stack/evaluate/compliance.mdx
@@ -1,82 +1,43 @@
 ---
 title: Compliance
 description: >-
-  Protocol evidence operators can use in a compliance program, and what Lineth
-  does not claim
+  How to use a Lineth deployment's protocol evidence in your own compliance
+  program
 sidebar_position: 1
 image: /img/socialCards/compliance.jpg
 ---
 
 import GlossaryTerm from '@theme/GlossaryTerm';
 
-This page describes what protocol evidence a <GlossaryTerm term="Lineth" /> deployment produces that operators can use in their own compliance
-program, and what Lineth does not claim.
+This page describes how to use a <GlossaryTerm term="Lineth" /> deployment's protocol evidence in your own
+compliance program.
+<GlossaryTerm term="Operator">Operators</GlossaryTerm> design the program and map its controls to their own obligations.
+Lineth does not certify a deployment against a regulatory framework.
 
-This page does **not** include:
+For protocol guarantees, operator-controlled surfaces, cryptographic primitives, and assurance evidence,
+see [Security and assurance](./security.mdx).
 
-- Mapping to specific regulatory frameworks.
-- A certification or attestation that a deployment is compliant.
-- Data retention or deletion product features. Operators implement retention and
-  disclosure against their own policy using the deployment's data availability
-  and access controls.
+## Deployment evidence
 
-## zk-SNARK proofs are not a compliance program
-
-<GlossaryTerm term="zk-SNARK" /> proofs verify state-transition correctness. They do not by themselves
-provide a complete compliance program. A compliance program needs controls,
-evidence, retention, disclosure, and ownership that go beyond proof
-verification.
-
-## Protocol evidence a deployment produces
-
-A Lineth deployment produces the following evidence that operators can use in a
-compliance design:
+A Lineth deployment produces evidence you can cite in your compliance program:
 
 - State commitments posted to the <GlossaryTerm term="Finalization layer">finalization layer</GlossaryTerm>
-- zk-SNARK proof verification records on the finalization layer
+- <GlossaryTerm term="zk-SNARK" /> proof verification records on the finalization layer
 - Finalization records on the finalization layer
 - Transaction history retained by the deployment's data availability model
 
-What participants can verify depends on the deployment model. For the trust and
-verification boundaries, see
-[Trust model](./trust-model.mdx). For where data is
-stored and who can see it, see [Privacy and data visibility](./validium.mdx).
-
-## Operator-owned compliance controls
-
-<GlossaryTerm term="Operator">Operators</GlossaryTerm> are responsible for the controls a compliance program requires. Lineth
-provides mechanisms operators can configure, but does not own the program:
-
-- Access policy: [RBAC](../deployment/access-control.mdx) on RPC endpoints and API surfaces controls
-  who can read or submit
-- Data availability arrangement: operators choose where transaction data is
-  stored and who can reconstruct it; see
-  [Data availability and finalization](../deployment/data-availability-finalization.mdx)
-- [Key management](../deployment/key-management.mdx): remote signing backed by
-  HSM or KMS via [Web3Signer](../../protocol/architecture/index.mdx#web3signer)
-- Governance and upgrade authority: multisig, governance contract, or timelock
-  for privileged roles; see [Security and assurance](./security.mdx)
-- External integrations: operators connect external compliance, monitoring, and
-  logging systems to their deployment
+What participants can reconstruct or verify from that evidence depends on the
+[deployment model](./deployment-models.mdx).
+See [Trust model](./trust-model.mdx) for trust and verification boundaries.
 
-## What Lineth does not claim
+## Retention and disclosure
 
-- Lineth does not certify a deployment as compliant with any specific
-  regulation.
-- Lineth does not publish a control-to-framework mapping.
-- <GlossaryTerm term="Validium">Private validium</GlossaryTerm> (offchain data) and
-  [access control](../deployment/access-control.mdx) (RPC gating) are not
-  cryptographic private execution or ZK privacy. Do not infer regulatory
-  compliance from them.
-- Lineth does not own data retention or disclosure policy. Operators implement
-  it.
+Operators implement retention and disclosure against their own policy, using the deployment's
+[data availability](../deployment/data-availability-finalization.mdx) and
+[access control](../deployment/access-control.mdx) configuration.
+They connect their own compliance, monitoring, and logging systems to the deployment.
 
-## Where to go next
+## See also
 
-| Question                                                    | Page                                                                                     |
-| ----------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
-| What can each component do, and what can participants verify? | [Trust model](./trust-model.mdx)                            |
-| Who can see what data?                                      | [Privacy and data visibility](./validium.mdx)                                            |
-| What is protocol versus operator, and what evidence exists? | [Security and assurance](./security.mdx)                                                 |
-| How is access to RPC and APIs controlled?                   | [Access control](../deployment/access-control.mdx)                                                             |
-| How do data availability and finalization choices interact? | [Data availability and finalization](../deployment/data-availability-finalization.mdx) |
+- [Security and assurance](./security.mdx): Protocol guarantees and published assurance evidence.
+- [Trust model](./trust-model.mdx): What each component can do, and what participants can verify.
diff --git a/docs/stack/evaluate/deployment-models.mdx b/docs/stack/evaluate/deployment-models.mdx
@@ -1,103 +1,118 @@
 ---
 title: Deployment models
-description: >-
-  How to compare Lineth public and private validium deployment models and their
-  trade-offs
-sidebar_position: 2
+description: Compare rollups and validiums, and their trade-offs
 image: /img/socialCards/deployment-models.jpg
 ---
 
 import GlossaryTerm from '@theme/GlossaryTerm';
 
-<GlossaryTerm term="Lineth" /> supports two deployment models: **public deployments**, such as
-[Linea Mainnet](/network), with onchain data availability and open access; and **private validium deployments**,
-with offchain data availability and controlled access.
+<GlossaryTerm term="Lineth" /> supports two deployment models: **rollups**, in which transaction data is
+posted to the <GlossaryTerm term="Finalization layer">finalization layer</GlossaryTerm>, and
+**validiums**, in which only state commitments and proofs are posted to the finalization layer.
+A validium can be **public** or **private**, depending on who can read that network's transaction data.
 
-Consider these questions when choosing a deployment model:
+The following table compares how rollups and validiums address key deployment questions.
+Choose the model that aligns with your requirements.
 
-- [Privacy](validium.mdx) requirements: Should transaction data remain private to authorized participants?
-- Regulatory and [compliance](./compliance.mdx) obligations: What controls does your program
-  require, and who owns them?
-- [Data availability](../deployment/data-availability-finalization.mdx) guarantees: How important is onchain data availability for
-  your participants?
-- Network topology: Do you need a private network with controlled membership?
-- [Access control](../deployment/access-control.mdx): Do you need role-based access control (RBAC) on RPC endpoints and
-  APIs?
+| Questions | Rollup | Public validium | Private validium |
+| --- | --- | --- | --- |
+| Where is transaction data stored? | On the finalization layer as [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) blobs | On the Lineth network's nodes | On the Lineth network's nodes |
+| What is posted to the finalization layer? | State commitments, proofs, and transaction data | State commitments and proofs only | State commitments and proofs only |
+| Who can reconstruct history? | Anyone with blob data, while it is retained | Anyone who can reach the network's nodes | Authorized participants only |
+| What is the network topology and access policy? | Open network and RPC access | Open network and RPC access | Restricted node set and [RBAC](../deployment/access-control.mdx) permissions on RPC |
 
-The following table compares how characteristics differ between public deployments and private validium deployments.
-Choose the deployment model that aligns with your requirements.
+The following sections provide more details about each model.
 
-| Characteristic | Public deployments | Private validium |
-| --- | --- | --- |
-| Data availability | Transaction data is posted onchain via EIP-4844 blobs | Transaction data can be stored offchain in a private node set |
-| Access control | Public RPC endpoint | RPC endpoints protected by RBAC |
-| What is posted to the <GlossaryTerm term="Finalization layer">finalization layer</GlossaryTerm> | State commitments, proofs, and transaction data | State commitments and proofs; transaction details stay offchain |
-| Who can reconstruct history | Anyone with the blob data, while it is retained | Participants the operator authorizes through DA access and RBAC |
-| Network topology | Open access | Controlled node membership |
+## Rollups
 
-The following sections provide more details about use cases and security considerations for each model.
-
-## Public deployments
-
-Public deployments such as Linea Mainnet are open networks with onchain data availability.
-Transaction data is posted as EIP-4844 blobs, so state commitments, proofs, and transaction data all appear on
-the finalization layer.
-Anyone with the blob data can reconstruct history while those blobs are retained.
+In a rollup, the <GlossaryTerm term="Coordinator">coordinator</GlossaryTerm> posts
+transaction data to the finalization layer using [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) blobs.
+State commitments, proofs, and transaction data appear on the finalization layer.
+Anyone who can read that data can reconstruct history while it remains available.
 RPC access is public, and node membership is not restricted.
 
 ### Use cases
 
-- Networks requiring maximum transparency
+- Applications that require maximum transparency
 - Applications that benefit from onchain data availability
-- Networks that prioritize open access over transaction privacy
+- Applications that prioritize open access over transaction privacy
 
 ### Security considerations
 
-- Validator topology: if the deployment uses a
-  [multi-validator QBFT design](../deployment/multi-validator-consensus.mdx), at least 4
-  Maru validators are required to tolerate one faulty validator
-- [Key management](../deployment/key-management.mdx): remote
-  signing backed by a hardware security module (HSM) or key management service
-  (KMS)
+The following operator choices affect how you secure a rollup:
 
-## Private validium
+- Validator topology: If the deployment uses a
+  [multi-validator QBFT design](../deployment/multi-validator-consensus.mdx), at least 4 Maru validators
+  are required to tolerate one faulty validator.
+- [Key management](../deployment/key-management.mdx): Remote signing backed by a hardware security
+  module (HSM) or key management service (KMS)
 
-A private validium keeps transaction data offchain, using <GlossaryTerm term="zk-SNARK" /> proofs
-to support state-transition correctness and finalization.
-RPC endpoints are protected by [access control](../deployment/access-control.mdx), and node membership is controlled.
+## Validiums
 
-Whether this model
-suits a regulated environment depends on the operator's own compliance, privacy,
-and access-control design; Lineth does not certify a deployment as compliant.
+In a validium, the <GlossaryTerm term="Coordinator">coordinator</GlossaryTerm> submits state
+commitments and proofs to the finalization layer.
+Transaction data is not posted there.
+Typically that data lives on the validium's <GlossaryTerm term="Archive node">archive nodes</GlossaryTerm>.
 
-### Use cases
+### Public validiums
 
-- Workflows where transaction data should not be public
-- Multi-party workflows where participants should not see all transaction
-  details
-- Operators who accept the validium trade-off: state-transition correctness is
-  proven onchain, but data reconstruction without the operator depends on the
-  deployment's data availability arrangement
+A public validium makes the Lineth network's data publicly readable.
+A public L3 that finalizes to Linea Mainnet uses this model: the coordinator submits state commitments and proofs to
+Linea, and transaction data stays on the L3's nodes because Linea cannot store it as blobs.
+RPC access is open, so anyone who can reach a node can reconstruct history from the network.
 
-Operators with regulatory or compliance obligations are responsible for
-designing their own compliance program. See
-[Compliance](./compliance.mdx) for what protocol evidence exists and
-what is not claimed.
+#### Use cases
 
-### Security considerations
+- Applications that need the lower finalization cost and faster settlement on Linea Mainnet, while keeping open access
+- Applications that do not require transaction data on the finalization layer
+
+#### Security considerations
+
+The following operator choices affect how you secure a public validium:
+
+- Validator topology: If the deployment uses a
+  [multi-validator QBFT design](../deployment/multi-validator-consensus.mdx), at least 4 Maru validators
+  are required to tolerate one faulty validator.
+- [Key management](../deployment/key-management.mdx): Remote signing backed by a hardware security
+  module (HSM) or key management service (KMS)
+
+### Private validiums
+
+A private validium keeps transaction data in a restricted node set and
+[controls RPC access](../deployment/access-control.mdx).
+Authorized participants who can reach those nodes can reconstruct history.
+A third party without that access cannot.
+
+:::warning Private validium is not cryptographic privacy
+A private validium does not make transactions cryptographically private.
+Anyone authorized to see the offchain data can read the transactions.
+The zk-SNARK proofs confirm that state transitions are correct; they do not hide that data.
+:::
+
+#### Use cases
+
+- Applications where transaction data should not be public
+- Multi-party workflows where participants should not see all transaction details
+- Applications that accept the private validium trade-off: state-transition correctness is proven onchain, but
+  reconstructing history requires authorized access to the operator's offchain data
+
+#### Security considerations
+
+The following operator choices affect how you secure a private validium:
+
+- Validator topology: If the deployment uses a
+  [multi-validator QBFT design](../deployment/multi-validator-consensus.mdx), at least 4 Maru validators
+  are required to tolerate one faulty validator.
+- [Access control](../deployment/access-control.mdx): RBAC permissions on JSON-RPC, APIs, and tooling
+- [Key management](../deployment/key-management.mdx): Remote signing backed by a hardware security
+  module (HSM) or key management service (KMS)
+- Network isolation: Private network topology with controlled peering
 
-- Validator topology: at least 4 Maru validators are required for a
-  [QBFT design](../deployment/multi-validator-consensus.mdx) that tolerates one faulty
-  validator
-- [Access control](../deployment/access-control.mdx): RBAC on RPC endpoints and API portal
-- [Key management](../deployment/key-management.mdx): remote
-  signing backed by a hardware security module (HSM) or key management service
-  (KMS)
-- Network isolation: private network topology with controlled peering
+For an illustrative topology, see the
+[example private validium architecture](../deployment/index.mdx#example-architecture).
 
 ## See also
 
-- [Trust model](./trust-model.mdx): Trust assumptions for each deployment model
-- [Privacy and data visibility](./validium.mdx): What a private validium publishes and who can see it
+- [Trust model](./trust-model.mdx): Trust assumptions for each deployment model, and what participants can verify
 - [Data availability and finalization](../deployment/data-availability-finalization.mdx): Where transaction
   data is stored in each deployment model, and where proofs settle
diff --git a/docs/stack/evaluate/index.mdx b/docs/stack/evaluate/index.mdx
@@ -28,12 +28,6 @@ your use case.
         "Understand what each deployment component can do, what participants can verify, and privileged contract roles.",
       href: "/stack/evaluate/trust-model",
     },
-    {
-      text: "Privacy and data visibility",
-      description:
-        "Learn what a private validium publishes, keeps offchain, and allows participants to verify.",
-      href: "/stack/evaluate/validium",
-    },
     {
       text: "Security and assurance",
       description:
@@ -43,7 +37,7 @@ your use case.
     {
       text: "Compliance",
       description:
-        "See what protocol evidence a deployment produces, to use in your own compliance program.",
+        "Use a deployment's protocol evidence in your own compliance program.",
       href: "/stack/evaluate/compliance",
     },
   ]}

diff --git a/docs/stack/evaluate/security.mdx b/docs/stack/evaluate/security.mdx
@@ -47,13 +47,11 @@ Under the configured deployment model, Lineth provides:
 - 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 model](./trust-model.mdx).
+For the trust assumptions in a Lineth deployment, see [Trust model](./trust-model.mdx).
 
 ## Operator-controlled security surfaces
 
 <GlossaryTerm term="Operator">Operators</GlossaryTerm> 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.
@@ -139,3 +137,7 @@ conclusions for custom deployments.
 
 Organizations evaluating a deployment must assess the applicable software versions,
 configuration, infrastructure, governance, and operational controls separately.
+
+## See also
+
+- [Compliance](./compliance.mdx): How to use protocol evidence in a compliance program.