> ## Documentation Index
> Fetch the complete documentation index at: https://docs.useabyss.com/llms.txt
> Use this file to discover all available pages before exploring further.

> Describes the zero-knowledge architecture underpinning Abyss and how cryptographic proofs enforce private yet verifiable state transitions.

# Zero-Knowledge System Overview

### 4.1 Role of Zero-Knowledge in Abyss

Zero-knowledge proofs are the core enforcement mechanism of Abyss. They allow users to demonstrate that a withdrawal or state transition is valid without revealing the underlying secrets that establish ownership or linkage to prior deposits. In Abyss, zero-knowledge does not sit at the periphery as an optimization. It is the protocol’s primary authorization system.

Formally, every withdrawal from the anonymity pool must be accompanied by a proof that asserts the existence of a prior valid deposit, the possession of the corresponding secret, and the non-use of that deposit’s nullifier. The verifier contract checks this proof deterministically, without learning which deposit is being spent or how many withdrawals have previously occurred.

### 4.2 Proof System Choice

Abyss uses succinct non-interactive arguments of knowledge (ZK-SNARKs) due to their compact proof size and constant-time verification characteristics. These properties are critical for EVM compatibility, where gas costs impose strict constraints on computation. Proof generation occurs off-chain, while verification is enforced on-chain.

The protocol assumes standard cryptographic hardness assumptions, including:

* Knowledge of exponent assumptions
* Collision resistance of hash functions
* Soundness and completeness of the underlying SNARK construction

No trusted intermediary is involved in proof validation once parameters are established.

### 4.3 Statement, Witness, and Public Inputs

Each proof in Abyss asserts a statement of the following form:

```
“I know a secret s and a commitment C such that:
  1. C exists in the commitment set
  2. H(s) = C
  3. nullifier(s) has not been used before
  4. withdrawal_amount ≤ remaining_balance(s)
”
```

The **witness** includes:

* The secret key
* Internal accounting data for remaining balance
* Merkle path data proving inclusion in the pool

The **public inputs** include:

* The Merkle root of the anonymity pool
* The nullifier hash
* The withdrawal amount
* The recipient address

This separation ensures that ownership is proven without disclosure.

### 4.4 Merkle Tree Commitments

Deposits are represented as leaves in a Merkle tree. The tree root represents the canonical state of the anonymity pool at a given time. Users include Merkle proofs inside their ZK circuit to show membership without revealing position.

Merkle roots are periodically updated on-chain:

```
function updateRoot(bytes32 newRoot) external;
```

Only roots corresponding to valid deposits are accepted.

### 4.5 Soundness and Finality

Once a proof verifies:

* The withdrawal is final
* The nullifier is permanently marked as spent
* No further linkage is possible on-chain

The protocol does not support proof revocation or discretionary rollback. This finality is essential for trust minimization and composability.

### 4.6 Design Implications

By making zero-knowledge the sole authorization mechanism, Abyss eliminates address-based permissions entirely at the withdrawal layer. Control flows from cryptography, not identity. This allows the protocol to support advanced behaviors, such as infinite withdrawals from a single deposit, without introducing additional trust assumptions.