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

# Infinite Withdrawal Model and Balance Accounting

> Defines how Abyss supports multiple, arbitrary withdrawals from a single deposit while preserving unlinkability and preventing balance inflation.

### 9.1 Rationale for Infinite Withdrawals

Most privacy protocols model deposits as single-use notes. Once spent, the note is exhausted and removed from the anonymity set. While simple, this model is poorly suited for real payments. It forces users to re-deposit repeatedly, fragments privacy, and leaks behavioral patterns through note churn.

Abyss adopts a fundamentally different abstraction. Deposits are **stateful commitments** that can authorize multiple withdrawals over time. This allows a single large deposit to support many small, unlinkable withdrawals without re-entering the pool. The result is stronger privacy, better usability, and native support for merchant payments, payroll, and recurring transfers.

***

### 9.2 Balance as a Hidden State Variable

Each commitment implicitly encodes a balance. This balance is **not stored on-chain** in the clear. Instead, it is enforced inside the zero-knowledge circuit.

Let:

```
B₀ := initial deposit amount
w₁, w₂, …, wₙ := withdrawal amounts
```

The circuit enforces the invariant:

```
Σ wᵢ ≤ B₀
```

This constraint is proven in zero knowledge at every withdrawal. The protocol never learns:

* How many withdrawals have occurred
* The remaining balance
* The withdrawal schedule

Only validity is proven.

***

### 9.3 Withdrawal Indexing and Nullifier Sequence

Each withdrawal is associated with an index `i` and a corresponding nullifier:

```
nullifier_i := H(secret_key || i)
```

Properties:

* Each index may be used exactly once
* Indices need not be sequential on-chain
* The protocol does not track indices, only nullifiers

This allows users to pre-generate an arbitrary number of withdrawal credentials offline.

***

### 9.4 ZK Circuit Enforcement

The withdrawal circuit proves:

```
Inputs (public):
  MerkleRoot
  nullifier_i
  withdrawal_amount
  recipient

Witness (private):
  secret_key
  MerklePath
  previous_withdrawals_sum
```

Constraints enforced:

```
1. commitment(secret_key) ∈ MerkleTree
2. nullifier_i = H(secret_key || i)
3. nullifier_i not yet used
4. previous_withdrawals_sum + withdrawal_amount ≤ B₀
```

No linkage between withdrawals is revealed.

***

### 9.5 On-Chain Accounting Model

On-chain, the protocol maintains only:

```
- Set of valid Merkle roots
- Set of used nullifiers
```

There is **no per-user balance mapping**. This is intentional. All balance logic lives inside the proof system.

This design eliminates:

* Address-based balance tracking
* State bloat
* Correlation via balance observation

***

### 9.6 Privacy and Payment Implications

This model enables:

* Micropayments from a single deposit
* Merchant checkout flows without account reuse
* Streaming payments without stateful channels
* Arbitrary timing without linkage

Recipients see only the withdrawal they receive. They cannot infer the payer’s total balance or past activity.

***

### 9.7 Failure and Edge Cases

If a user reuses an index:

```
nullifier collision → transaction reverts
```

If a withdrawal exceeds remaining balance:

```
proof invalid → verification fails
```

There is no way to partially fail. Either the proof is valid or the transaction is rejected.

***

### 9.8 Design Consequences

The infinite withdrawal model turns Abyss from a privacy tool into a **private payment substrate**. Funds behave like cash, not accounts. Control is cryptographic, not historical.

***