> ## 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.

# Proof Statements and Witness Structure

> Specifies exactly what is proven, what remains private, and how zero-knowledge enforces correctness without disclosure.

At the core of Abyss is a single, well-defined zero-knowledge statement: **a withdrawal is valid if and only if it corresponds to a previously committed deposit, has not been spent before, and does not exceed the committed balance**. Everything else in the protocol exists to support this statement.

Formally, each withdrawal is accompanied by a ZK-SNARK proof asserting knowledge of a witness ( W ) such that the following conditions hold.

#### VII.1.1 Public Inputs

The verifier contract receives a fixed set of public inputs:

```
PublicInputs :=
{
  merkle_root,        // current or recent commitment tree root
  nullifier,          // unique spend identifier
  withdrawal_amount,  // value being withdrawn
  recipient_address   // destination of funds
}
```

These values are observable on-chain and are sufficient to enforce correctness without revealing identity.

#### VII.1.2 Private Witness

The witness is never revealed and exists only inside the proof circuit:

```
Witness :=
{
  secret_key,
  deposit_nonce,
  deposit_amount,
  withdrawal_index,
  merkle_path,
  previous_withdrawals_sum
}
```

This data allows the prover to demonstrate authorization without exposing linkage.

#### VII.1.3 Core Proof Statement

The circuit enforces the following constraints simultaneously:

```
1. commitment = H(secret_key || deposit_nonce || deposit_amount)
2. commitment ∈ MerkleTree(merkle_root)
3. nullifier = H(secret_key || withdrawal_index)
4. nullifier ∉ NullifierSet
5. previous_withdrawals_sum + withdrawal_amount ≤ deposit_amount
```

All constraints must hold for the proof to verify. Failure of any single constraint invalidates the withdrawal.

***

### VII.1.4 Zero-Knowledge Properties

The proof system guarantees:

* **Completeness**: valid withdrawals always verify
* **Soundness**: invalid withdrawals cannot verify
* **Zero-knowledge**: no information about the witness leaks

An observer learns only that *some valid commitment* authorized the withdrawal.

***

### VII.1.5 Why This Structure Matters

This construction achieves three critical goals simultaneously:

1. Prevents double-spending without identity
2. Enforces balance conservation without accounts
3. Preserves unlinkability across time and actions

There is no address-based permission model anywhere in the withdrawal path. Authorization is purely cryptographic.

***