Skip to main content

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.

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.