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.

A core real-world failure of public blockchains is that payments expose far more information than necessary. In standard on-chain transfers, a merchant receiving funds immediately gains visibility into the payer’s full transaction history, balance patterns, counterparties, and behavioral signals. This is not required for settlement. It is an artifact of address-based accounting. Abyss replaces this model with proof-based payment authorization. In an Abyss-mediated payment, the merchant does not receive funds from a long-lived account. They receive funds from a withdrawal event that is cryptographically valid but historically unlinked. The merchant learns exactly three things:
  1. That they were paid
  2. The amount paid
  3. The asset received
They do not learn:
  • The payer’s balance
  • The payer’s prior transactions
  • The payer’s identity graph
  • Whether the payer has interacted with the merchant before
This is information minimization by design.

​
VI.2.1 Payment Flow Abstraction

A typical Abyss payment flow can be represented as: 
User Deposit → Privacy Pool → ZK Withdrawal → Merchant Address
At no point does the merchant interact with the user’s deposit address. The withdrawal may be executed by the user, a relayer, or even the merchant themselves if delegated credentials are provided. This enables multiple payment models:
  • One-time checkout payments
  • Invoice-based settlement
  • Subscription withdrawals
  • Programmatic payouts
All without account reuse.

​
VI.2.2 Delegated Withdrawal Credentials

Because withdrawal authorization is credential-based, users may issue limited-scope withdrawal keys to merchants or applications: 
withdrawal_key_i := H(secret_key || i)
Each key authorizes a bounded withdrawal and is consumed on use. This mirrors cash-like behavior without shared custody or persistent access. Merchants do not hold balances. They hold rights to withdraw a specific amount once.

​
VI.2.3 Compliance Implications

From a compliance standpoint, this model is superior to address-based payments. Merchants can:
  • Prove receipt of funds
  • Record transaction amounts
  • Maintain auditable books
Without storing sensitive customer financial histories. Data minimization reduces liability, breach impact, and regulatory exposure.

​
VI.2.4 Economic Consequences

By removing history leakage, Abyss enables:
  • Safer consumer payments
  • Merchant adoption without privacy risk
  • On-chain commerce that resembles real-world norms
Privacy here is not adversarial. It is functional.