> For the complete documentation index, see [llms.txt](https://docs.zetrix.com/zetrix-l2-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zetrix.com/zetrix-l2-documentation/architecture/trust-model.md).

# Trust Model

Z2 is an **AnyTrust optimistic rollup** (DA Committee + L1 calldata fallback), with the escape-hatch and fail-closed guarantees described below.

## Security Assumptions

Z2 inherits its ultimate security guarantees from Zetrix L1 and relies on an **optimistic** trust model with **committee-based data availability**. The assumptions are:

1. **At least one honest verifier** — The system is safe as long as **at least one honest Watcher** re-executes state transitions and is able to submit a fraud proof to L1 within the challenge window. This is the classic "1-of-N honest" liveness-of-verification assumption of optimistic systems.
2. **L1 availability and censorship-resistance** — Zetrix L1 accepts commitments, assertions, and fraud-proof transactions within bounded time.
3. **Data availability via the DAC, with L1 calldata fallback (AnyTrust)** — Normally the batch data is held off-chain and the **Data Availability Committee (DAC, 5 members)** attests that it is stored and retrievable. **If the committee cannot reach its attestation threshold, the Sequencer falls back to posting the full batch as L1 calldata.** Consequently data can never *silently* disappear: either the DAC serves it, or it is on L1. This is a **stronger** DA guarantee than a pure Validium and is the reason Z2 is described as an AnyTrust rollup.
4. **Committee threshold for soft confirmation (liveness, not final safety)** — The Committee runs **5 members (committee bundles) and requires 3-of-5** to soft-confirm a proposed assertion and attest data availability. Soft confirmations improve UX but do **not** replace L1 final confirmation for safety-critical operations.
5. **Fail-closed operation** — The pipeline **halts on uncertain L1 reads** rather than proceeding on possibly-stale state, preventing the system from acting on an inconsistent view of L1.
6. **Censorship resistance (escape hatch)** — If the Sequencer censors a user, the user can **force-include** their transaction directly via the L1 Sequencer Inbox.
7. **Cryptographic soundness** — Signature schemes and hash functions used for commitments, batch signing, aggregation, and assertions are secure.

> \[!WARNING] Soft confirmations are a UX convenience backed by the Committee's economic and reputational stake. Funds and high-value operations should be considered **settled only after final confirmation on L1**, once the challenge window has elapsed without a successful dispute.

## Roles in the Trust Model

<figure><img src="/files/ULDVzys1zvgqf5bPy4jX" alt=""><figcaption></figcaption></figure>

| Role           | Function                                                                                                                    | Trust contribution                                                    |
| -------------- | --------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| **Committee**  | Validators + Reexecutors (**5 members**) that verify and sign the Proposer's assertion at **3-of-5** and manage the **DAC** | Fast soft confirmation + data availability under the 3-of-5 threshold |
| **Aggregator** | Collects and aggregates Committee signatures into a compact proof                                                           | Efficiency; reduces L1 signature footprint                            |
| **Proposer**   | Proposes assertions (state commitments) to L1; also runs a Watcher role                                                     | Bridges L2 state to L1 settlement                                     |
| **Watchers**   | Fetch data from DAC, independently re-execute, and challenge invalid assertions; earn rewards for honest disputes           | Safety (1-of-N honest)                                                |

## Committee

The **Committee** is the set of active Validators (each paired with a Reexecutor) responsible for verifying and signing the **assertion created by the Proposer**, producing the signatures that constitute a **soft confirmation**, and managing the **DAC**. The Committee:

* Runs **5 members (committee bundles)** and requires **3-of-5** signatures to soft-confirm.
* Fetches transaction data from the DAC and re-executes it (via the Reexecutor) to independently verify the Proposer's proposed assertion.
* Each member independently signs the assertion; the Aggregator combines the 3-of-5 signatures.
* Manages the temporary L2 **data availability (DAC)**, mapped to the commitment the Sequencer posts to the L1 inbox.
* Provides a fast, high-confidence signal to users and applications ahead of L1 finality.

The Committee's 3-of-5 threshold governs *liveness of soft confirmation and data availability*, not the safety of final settlement — safety is protected by Watchers and L1.

### Data Availability Committee (DAC) — AnyTrust

Z2 uses an **AnyTrust** data-availability model. In the normal path the Sequencer posts the ordered batch to the L1 **Sequencer Inbox** and the **DAC (5 members)** attests that the batch data is stored and retrievable; the full data stays **off-chain**, keeping cost low. Validators and Watchers **fetch data from the DAC** to re-execute and verify assertions.

> \[!IMPORTANT] **No silent DA loss.** If the committee **cannot reach its attestation threshold**, the Sequencer **falls back to posting the full batch as L1 calldata**. So data availability degrades gracefully to on-chain rather than failing: either the DAC serves the data, or it is available on L1. This is why Z2 is an **AnyTrust rollup** (comparable to Arbitrum Nova), not a pure Validium/Optimium — the DA trust assumption is meaningfully **safer** than committee-only DA.

## Aggregator

The **Aggregator** collects individual Committee member signatures and aggregates them into a single compact cryptographic artifact. This:

* Minimizes the data footprint of Committee attestations.
* Reduces L1 verification cost when attestations are referenced.
* Provides a single verifiable object representing Committee consensus on a batch.

If the Aggregator is unavailable, the Committee can fall back to submitting individual signatures; the Aggregator is an efficiency optimization, not a safety-critical single point.

## Proposer

The **Main Proposer Validator** (the Proposer) is responsible for **proposing assertions** to Zetrix L1. An assertion is a claim about the resulting L2 state after applying a batch (or sequence of batches). The Proposer:

* Reads the batch commitment from the L1 inbox and the corresponding data from the DAC.
* Proposes the assertion (state claim) to the L1 contracts, opening the challenge window.
* Also runs a **Watcher** role itself — it independently re-executes and can dispute, acting as the first always-on watcher.

The Committee then **verifies and signs** the proposed assertion (3-of-5) for soft confirmation. There is a single active Proposer in the current deployment (see [Main Proposer Validator](/zetrix-l2-documentation/architecture/system-components.md#main-proposer-validator)); the Proposer role is replaceable and does not hold unilateral power to finalize invalid state, because a proposed assertion is soft-confirmed by the Committee and subject to dispute by any Watcher.

## Soft Confirmation

**Soft confirmation** is the fast, pre-L1 acknowledgement that a transaction has been included in a batch and validated by the Committee.

```mermaid
sequenceDiagram
    participant Prop as Proposer
    participant Comm as Committee
    participant DAC as DAC
    participant Agg as Aggregator
    participant User
    Prop->>Comm: proposed assertion
    Comm->>DAC: fetch data & re-execute
    Comm->>Comm: verify assertion
    Comm->>Agg: signatures (3-of-5)
    Agg-->>User: soft confirmation (aggregated)
```

* **Latency:** sub-second to seconds (well ahead of L1 finality).
* **Guarantee:** the Committee (at 3-of-5) attests the Proposer's assertion is correct and data is available.
* **Use:** UX responsiveness, low-value/reversible flows, optimistic UI updates.

## Final Confirmation

**Final confirmation** occurs after the Proposer's assertion has been submitted to L1 and the challenge window has elapsed **without a successful dispute**.

* **Latency:** governed by the challenge window (dispute period).
* **Guarantee:** L1-enforced; safe against Committee misbehavior given ≥1 honest Watcher.
* **Use:** withdrawals, high-value settlement, irreversible operations.

| Property          | Soft Confirmation         | Final Confirmation      |
| ----------------- | ------------------------- | ----------------------- |
| Latency           | Fast (seconds)            | Slow (challenge window) |
| Enforced by       | Committee                 | Zetrix L1               |
| Safety assumption | Honest-majority Committee | 1-of-N honest Watcher   |
| Recommended for   | UX, low value             | Withdrawals, high value |

## Fraud Detection

Fraud detection is performed by **Watchers** and **Reexecutors**, which **fetch the transaction data from the DAC**, independently re-execute it, and compare the resulting state root against the Proposer's soft-confirmed assertion.

```mermaid
flowchart TD
    A["Proposer's<br/>soft-confirmed assertion"] --> B["Watcher fetches<br/>data from DAC"]
    B --> C{"Re-execute:<br/>state root matches?"}
    C -->|matches| D["No action —<br/>assertion valid"]
    C -->|differs| E["Fraud detected"]
    E --> F["Watcher initiates<br/>dispute on L1"]
```

Detection is deterministic: given the same data from the DAC and the same EVM rules, honest re-execution must produce the same state root. Any divergence indicates an invalid assertion (or unavailable/invalid data). Honest Watchers that raise a valid dispute earn a reward (see [Dispute Process](#dispute-process)).

## Assertion Process

```mermaid
sequenceDiagram
    participant Seq as Sequencer
    participant L1 as Zetrix L1
    participant DAC as DAC
    participant Prop as Proposer
    participant Comm as Committee
    Seq->>L1: post batch commitment (inbox)
    Seq->>DAC: publish tx data
    Prop->>L1: propose assertion (state root + commitment ref)
    Comm->>DAC: fetch data, re-execute
    Comm->>L1: sign assertion (3-of-5) → soft confirmation
    L1->>L1: record assertion, start challenge window
```

An **assertion** binds a batch (or range) to a resulting state root and is anchored on L1, referencing the commitment posted to the inbox. Once soft-confirmed and recorded, the assertion enters the challenge window. If unchallenged, it becomes final.

## Dispute Process

If a Watcher detects fraud, it initiates a **dispute** against the assertion on L1. The dispute is resolved by an on-chain adjudication (fraud-proof / dispute game) that establishes which party's claimed state transition is correct.

```mermaid
sequenceDiagram
    participant Watch as Watcher
    participant L1 as Zetrix L1
    participant Prop as Proposer
    Watch->>L1: open dispute against assertion
    L1->>Prop: notify challenge
    Note over L1: Interactive / single-step verification
    L1->>L1: evaluate contested state transition
    alt Assertion invalid
        L1-->>Watch: dispute upheld — assertion rejected
        L1->>Prop: penalize / discard invalid assertion
    else Assertion valid
        L1-->>Prop: dispute rejected — assertion stands
    end
```

**Outcome guarantees:**

* An **invalid assertion** is rejected before it can finalize, protecting user funds and state integrity.
* A **frivolous dispute** is rejected, protecting an honest Proposer.
* Final confirmation only proceeds for assertions that survive the challenge window.
* An **honest Watcher that wins a dispute earns a reward** — the incentive that sustains the 1-of-N honest assumption and encourages third-party participation.

> \[!NOTE] The security of the entire system reduces to: *at least one honest party fetches the data from the DAC, re-executes, and is willing and able to dispute*. This is why the platform actively encourages **third-party Watchers** with dispute rewards (see [Watcher](/zetrix-l2-documentation/architecture/system-components.md#watcher)). Note that data availability is backstopped by the L1 calldata fallback — see [Data Availability Committee (DAC) — AnyTrust](#data-availability-committee-dac--anytrust).

## L1 Settlement Contracts

Z2 settlement on Zetrix L1 is anchored by a small set of contracts:

| Contract            | Purpose                                                                                                                                                                                                                               |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Sequencer Inbox** | Records the ordered batch sequence posted by the Sequencer (and accepts force-included user transactions).                                                                                                                            |
| **Rollup**          | Holds the chain of state **assertions**. New assertions extend the frontier; after the challenge window with no successful dispute they become **confirmed — final on L1**. The Proposer posts assertions here via `createAssertion`. |
| **Bridge & Outbox** | Custodies bridged assets (**ZTP-20**, **ZTP-721**). The **Outbox** processes L2→L1 withdrawals: a withdrawal is claimed on L1 with a **Merkle proof** against a confirmed assertion.                                                  |

## Censorship Resistance (Escape Hatch)

If the Sequencer censors or omits a user's transaction, the user can **force-include** it directly through the L1 **Sequencer Inbox**. This guarantees users an L1-enforced path to transact even without Sequencer cooperation — a core liveness/trust property.

## Operator Signing (z2-signer / HSM)

Operator and application signing keys are protected by **`z2-signer`**, a **hardware-backed (HSM) signing service**. Privileged signing (Sequencer, Proposer, DAC members, Refueler, bridge operators) is performed through `z2-signer` so raw private keys are never exposed in application memory or configuration. See also [Security](/zetrix-l2-documentation/architecture/system-components.md#security).

***

[← Overall Architecture](/zetrix-l2-documentation/architecture/overall-architecture.md) · [Index](/zetrix-l2-documentation/readme.md) · [System Components →](/zetrix-l2-documentation/architecture/system-components.md)