Refactor "Trust model" page

docs/protocol/architecture/prover/trusted-setup.mdx

@@ -59,4 +59,4 @@ That ceremony is complete and does not require ongoing MPC participation during
 ## See also
 
 - [Trace expansion and proving](./index.mdx)
-- [Trust and responsibilities](/stack/evaluate/trust-model)
+- [Trust model](/stack/evaluate/trust-model)

docs/protocol/architecture/smart-contracts.mdx

@@ -22,7 +22,7 @@ is the network's onchain root of trust: nothing the network claims about its own
 until this contract has recorded it.
 The finalization contract:
 
-- Verifies the <GlossaryTerm term="zk-SNARK" /> proof submitted for each range of blocks, and records the
+- Calls a verifier contract to check the <GlossaryTerm term="zk-SNARK" /> proof submitted for each range of blocks, and records the
   resulting finalized state.
 - Accepts the transaction data the network publishes, through whichever
   [data submission model](./index.mdx#transaction-lifecycle) the deployment uses.
@@ -66,7 +66,7 @@ Lineth's upgradeable contracts, including the finalization contract, message ser
 pattern (v4.x): state lives in a proxy, and an upgrade replaces the implementation the proxy delegates to.
 
 Who holds upgrade authority is a deployment decision, not a protocol one.
-See [Trust and responsibilities](../../stack/evaluate/trust-model.mdx) for how that authority is scoped.
+See [Trust model](../../stack/evaluate/trust-model.mdx) for how that authority is scoped.
 
 :::note Linea Mainnet
 

docs/protocol/reference/security-audits.mdx

@@ -32,4 +32,4 @@ Each report identifies the component and code revision reviewed at the time of t
 - [Prover architecture](../architecture/prover)
 - [Smart contracts](../architecture/smart-contracts)
 - [Security and assurance](/stack/evaluate/security)
-- [Trust and responsibilities](/stack/evaluate/trust-model)
+- [Trust model](/stack/evaluate/trust-model)

docs/protocol/reference/zero-knowledge-glossary.mdx

@@ -245,6 +245,10 @@ The point at which a block is confirmed and committed on the L2 itself, before i
 
 The Lineth component that maintains the network's state representation for proof generation and recovery. It consists of a Besu node with the Shomei plugin and a Shomei node that uses sparse Merkle trees to track state changes block by block, generate Merkle proofs for state transitions, and serve `linea_getProof` RPC requests.
 
+### System contracts
+
+The onchain contracts Lineth deploys on the finalization layer and on the network. They include the finalization contract, which verifies proofs and records state, and the message service and token bridge contracts, which move messages and tokens between the two chains.
+
 ### Tracer
 
 The Linea Besu plugin, part of the sequencer, that generates the execution traces the prover needs to create zero-knowledge proofs. The tracer provides trace counts for batch-size calculations and produces conflated trace files as prover input.

docs/stack/deployment/access-control.mdx

@@ -171,5 +171,3 @@ They do not receive a view of private contracts or transaction data.
   communicate with each other, and how an access controlled destination authorizes calls.
 - [Privacy and data visibility](../evaluate/validium.mdx): How private validium deployments use offchain
   data availability and controlled access.
-- [Trust and responsibilities](../evaluate/trust-model.mdx): What participants can verify when access and
-  data availability are restricted.

docs/stack/deployment/distributed-sequencing.mdx

@@ -175,6 +175,5 @@ consensus overhead) so transactions of typical complexity have room to execute.
 
 ## See also
 
-- [Trust and responsibilities](../evaluate/trust-model.mdx)
 - [Finality design](./fast-finality.mdx)
 - [Set up distributed sequencing](../how-to/set-up-distributed-sequencing.mdx)

docs/stack/deployment/index.mdx

@@ -133,5 +133,5 @@ The example architecture flows as follows:
    [canonical token bridge and message service](../../protocol/architecture/interoperability/index.mdx).
    This example also shows validium message relayers to other enterprise or public chains.
 
-See [Trust and responsibilities](../evaluate/trust-model.mdx) for who operates each component, what it
-can do, and what participants can verify.
+See [Trust model](../evaluate/trust-model.mdx) to understand what each deployment component can do and
+what participants can verify.

docs/stack/deployment/key-management.mdx

@@ -45,7 +45,7 @@ Do not reuse one key across roles.
       </td>
       <td>
         Submission from that address stalls or can be issued by an attacker until
-        <a href="../evaluate/trust-model#admin-keys-and-upgrade-authority"><code>OPERATOR_ROLE</code></a> is revoked
+        <a href="../evaluate/trust-model#system-contract-roles"><code>OPERATOR_ROLE</code></a> is revoked
       </td>
     </tr>
     <tr>
@@ -59,7 +59,7 @@ Do not reuse one key across roles.
       </td>
       <td>
         Finalization from that address stalls or can be issued by an attacker until
-        <a href="../evaluate/trust-model#admin-keys-and-upgrade-authority"><code>OPERATOR_ROLE</code></a> is revoked
+        <a href="../evaluate/trust-model#system-contract-roles"><code>OPERATOR_ROLE</code></a> is revoked
       </td>
     </tr>
     <tr>
@@ -136,10 +136,10 @@ Do not reuse one key across roles.
 </table>
 
 Coordinator blob and aggregation signers must use an Ethereum address that
-holds the rollup contracts' [`OPERATOR_ROLE`](../evaluate/trust-model.mdx#admin-keys-and-upgrade-authority).
+holds the rollup contracts' [`OPERATOR_ROLE`](../evaluate/trust-model.mdx#system-contract-roles).
 Custody (how the key is stored) does not grant that role.
 Keep signer addresses aligned with the role holders in
-[Admin keys and upgrade authority](../evaluate/trust-model.mdx#admin-keys-and-upgrade-authority).
+[System contract roles](../evaluate/trust-model.mdx#system-contract-roles).
 
 ## Key custody options
 
@@ -239,7 +239,7 @@ Operators own the following controls:
   (IAM) policies or a signer access control list (ACL), network isolation, and
   credential rotation for anyone allowed to sign.
 - **Onchain authorization**: Grant the signer address the role it needs
-  ([`OPERATOR_ROLE`](../evaluate/trust-model.mdx#admin-keys-and-upgrade-authority) for coordinator submission),
+  ([`OPERATOR_ROLE`](../evaluate/trust-model.mdx#system-contract-roles) for coordinator submission),
   and revoke it when the key is retired.
 - **Access review and audit**: Review who can use the KMS key, Web3Signer API,
   and onchain roles. Retain and review signer and KMS audit logs against your
@@ -250,25 +250,24 @@ Operators own the following controls:
   - **Operational signers** (coordinator, Postman, sequencer liveness plugin) sign as a
     specific Ethereum address. Changing the key changes the sender unless the new
     material is the same key pair. If you change the address, update the matching
-    onchain role (for example, [`OPERATOR_ROLE`](../evaluate/trust-model.mdx#admin-keys-and-upgrade-authority)
+    onchain role (for example, [`OPERATOR_ROLE`](../evaluate/trust-model.mdx#system-contract-roles)
     for coordinator submission) before the old key is retired, or submission reverts.
     Web3Signer can load a replacement key in its store while components keep calling the same endpoint.
   - In the open-source stack, **Maru validator keys** are mounted as files.
     Changing that validator key or the validator set requires a
     [coordinated genesis update](../how-to/set-up-distributed-sequencing.mdx#manage-the-validator-set).
     When Lineth supplies AWS KMS signing for an enterprise deployment, the
     validator key lives in the KMS. The local key file is still used for P2P identity.
-  - **Contract admin keys** ([`DEFAULT_ADMIN_ROLE`](../evaluate/trust-model.mdx#admin-keys-and-upgrade-authority)
+  - **Contract admin keys** ([`DEFAULT_ADMIN_ROLE`](../evaluate/trust-model.mdx#system-contract-roles)
     and related roles) are rotated by
     granting a new holder and revoking the old one through the deployment's
-    governance or multisig process. See
-    [Failure modes and recovery](../evaluate/trust-model.mdx#failure-modes-and-recovery).
+    governance or multisig process.
 
 For [high availability](high-availability.mdx) placement, hardware-backed keys that stay in an HSM
 boundary can be used from more than one region without a new key ceremony.
 
 ## See also
 
 - [Access control](./access-control.mdx): How to restrict access to JSON-RPC, APIs, and tooling.
-- [Trust and responsibilities](../evaluate/trust-model.mdx): Onchain roles and
+- [Trust model](../evaluate/trust-model.mdx): Onchain roles and
   component trust boundaries.

docs/stack/evaluate/compliance.mdx

@@ -39,7 +39,7 @@ compliance design:
 
 What participants can verify depends on the deployment model. For the trust and
 verification boundaries, see
-[Trust and responsibilities](./trust-model.mdx). For where data is
+[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
@@ -74,7 +74,7 @@ provides mechanisms operators can configure, but does not own the program:
 
 | Question                                                    | Page                                                                                     |
 | ----------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
-| Who operates what, and what can each component do?          | [Trust and responsibilities](./trust-model.mdx)                            |
+| 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)                                                             |

docs/stack/evaluate/deployment-models.mdx

@@ -99,7 +99,7 @@ what is not claimed.
 
 ## See also
 
-- [Trust and responsibilities](./trust-model.mdx): Trust assumptions and guarantees for each deployment model
+- [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
 - [Data availability and finalization](../deployment/data-availability-finalization.mdx): Where transaction
   data is stored in each deployment model, and where proofs settle

docs/stack/evaluate/index.mdx

@@ -23,9 +23,9 @@ your use case.
       href: "/stack/evaluate/deployment-models",
     },
     {
-      text: "Trust and responsibilities",
+      text: "Trust model",
       description:
-        "Learn who operates each component, what each component can do, and what participants can verify.",
+        "Understand what each deployment component can do, what participants can verify, and privileged contract roles.",
       href: "/stack/evaluate/trust-model",
     },
     {

docs/stack/evaluate/security.mdx

@@ -48,16 +48,17 @@ Under the configured deployment model, Lineth provides:
   tied to verified state transitions in the normal protocol path.
 
 For the trust boundaries behind each of these, see
-[Trust and responsibilities](./trust-model.mdx).
+[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
+- Infrastructure isolation and network security controls.
 - [Access control](../deployment/access-control.mdx) for JSON-RPC, APIs, and tooling.
+- Offchain data availability and access, in a <GlossaryTerm term="Validium">private validium</GlossaryTerm>.
 - [Key management](../deployment/key-management.mdx) via KMS-backed signing and
   remote signing through
   [Web3Signer](../../protocol/architecture/index.mdx#web3signer).
@@ -93,7 +94,7 @@ The following public materials are the available assurance evidence for the Line
   computation (MPC) ceremonies and structured reference strings used by the proving system
 - [Security audits](../../protocol/reference/security-audits.mdx): The published audit reports
   for reviewed components and revisions
-- [Trust and responsibilities](./trust-model.mdx): Component-level trust boundaries and
+- [Trust model](./trust-model.mdx): Component-level trust boundaries and
   failure modes
 - [Smart contracts](../../protocol/architecture/smart-contracts.mdx): The onchain contracts a
   deployment uses