Skip to main content

​
2.1 Adversary Model

Abyss assumes a global passive adversary with full read access to the blockchain. This includes the ability to observe:
  • All transactions and events
  • All calldata and emitted logs
  • All historical state transitions
  • Timing, ordering, and value flows
The adversary is assumed to possess advanced graph-analysis capabilities, including clustering heuristics, balance tracking, timing correlation, and probabilistic inference. The adversary does not control consensus, cannot break standard cryptographic primitives, and cannot forge zero-knowledge proofs. Active attacks such as transaction censorship or chain reorganization are considered out of scope for the privacy guarantees, though the protocol remains safe under such conditions.

​
2.2 Privacy Objective

The primary privacy objective of Abyss is unlinkability, not anonymity of participation. Formally, the protocol aims to ensure that, given:
  • a deposit transaction ( D )
  • a withdrawal transaction ( W )
there exists no efficient algorithm by which an observer can determine whether ( D \rightarrow W ) with probability meaningfully greater than random chance, assuming the anonymity set is non-trivial and protocol usage conditions are met. Abyss does not hide amounts, timing, or the fact that a withdrawal occurred. Instead, it hides ownership continuity across time.

​
2.3 Cryptographic Enforcement

Unlinkability is enforced through:
  • Commitment schemes binding deposits to secrets
  • Nullifiers preventing double-spends without revealing identity
  • ZK-SNARK proofs asserting valid state transitions without disclosing witness data
At no point does the protocol rely on trusted setup beyond standard ZK assumptions, nor does it require off-chain coordination or trusted relayers to preserve privacy.

​
2.4 Anonymity Set Assumptions

Privacy strength scales with the size and diversity of the anonymity set. Abyss assumes:
  • Multiple independent users
  • Overlapping deposit and withdrawal activity
  • Non-pathological usage patterns
The protocol is deliberately designed around a single global anonymity pool to avoid fragmentation that would otherwise degrade these guarantees.

​
2.5 Aside: Privacy-Preserving Payments

Abyss is explicitly designed to support private payments, not just private asset movement. In traditional on-chain payments, merchants receive funds from addresses whose entire transaction history is immediately visible. This creates unacceptable information leakage: balances, prior counterparties, historical behavior, and even inferred identity. Abyss enables a different model. Users can pay merchants via withdrawals that are cryptographically valid yet unlinkable to prior activity. Merchants receive funds without learning anything about the payer’s history beyond the payment itself. This has direct implications for:
  • Consumer payments
  • Merchant settlement
  • Payroll and contractor compensation
  • Subscription and recurring billing primitives
In this model, privacy is not about evasion. It is about information minimization. Merchants learn what they need to know (that they were paid) and nothing else. Users retain control over when, how, and whether their financial history is exposed. Abyss treats this as a foundational use case, not an afterthought.

​
2.6 Explicit Non-Goals

Abyss does not attempt to:
  • Obfuscate consensus participation
  • Hide contract interactions unrelated to transfers
  • Provide identity anonymity at the network layer
These constraints are intentional to preserve composability, auditability, and system integrity.