Skip to main content

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