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 deposit into Abyss is the only point at which a user’s public on-chain identity directly interacts with the protocol. This interaction is deliberately minimized, tightly scoped, and structurally severed from all future actions. The purpose of the deposit flow is not to hide participation, but to terminate provenance. From a systems perspective, a deposit performs a one-way transformation: 
(Address, Asset, Amount)
        ↓
(Commitment, Secret, Merkle Inclusion)
Once this transformation completes, the protocol no longer reasons about addresses, balances, or accounts. All subsequent authorization is mediated exclusively through zero-knowledge proofs.

​
V.1.1 Client-Side Preparation

Before any on-chain interaction occurs, the user’s client generates entropy locally: 
secret_key      := random(256 bits)
deposit_nonce   := random(256 bits)
Using these values, the client computes a commitment: 
commitment := H(secret_key || deposit_nonce || amount_V)
This commitment is a cryptographic binding between value and secret knowledge. Crucially, the secret never leaves the client environment. The protocol has no mechanism to recover or regenerate it. Loss of the secret implies permanent loss of funds. This is not a UX oversight. It is a direct consequence of eliminating custody and identity from the protocol’s trust model.

​
V.1.2 Asset Normalization Boundary

The deposit flow enforces asset normalization as a hard boundary. Incoming assets are converted into $V prior to commitment insertion. This step ensures that all subsequent privacy guarantees are independent of the original asset’s liquidity, rarity, or on-chain footprint. 
amount_V := convert(asset, amount)
Only $V ever enters the anonymity pool.

​
V.1.3 On-Chain Deposit Execution

The deposit contract enforces minimal invariants: 
function deposit(bytes32 commitment, uint256 amountV) external {
    require(amountV > 0);
    require(!commitmentExists[commitment]);
    transferVFrom(msg.sender, address(this), amountV);
    insertCommitment(commitment);
}
The contract:
  • Does not persist sender identity
  • Does not associate commitments with addresses
  • Does not track balances
Its sole responsibility is state correctness.

​
V.1.4 Privacy Boundary and Finality

Once a commitment is inserted:
  • The anonymity set grows
  • Provenance is destroyed
  • Withdrawal rights exist independently of addresses
From this point forward, privacy is enforced cryptographically, not procedurally.