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

> Explains how Abyss abstracts heterogeneous assets into a single privacy-preserving representation to eliminate provenance leakage. styling in standard markdown

# Asset Normalization via the $V Token

### 7.1 Motivation for Asset Normalization

On EVM chains, different assets carry different traceability profiles. ERC-20 tokens differ in liquidity, transfer patterns, holder distributions, and interaction histories. Even if transactional unlinkability is achieved at the address level, asset-level metadata can still leak information. For example, withdrawing a rare or thinly traded token from a privacy pool may itself act as an identifying signal.

Abyss addresses this by introducing **\$V**, a protocol-native privacy asset that serves as the sole unit of account within the anonymity pool. All deposits are converted into \$V before entering the pool, and all withdrawals exit the pool as \$V. This design ensures that privacy guarantees are uniform regardless of the original asset deposited.

The normalization step is not cosmetic. It is a deliberate cryptographic and economic boundary that severs asset provenance at the pool entrance and prevents downstream re-identification via asset uniqueness.

***

### 7.2 Entry Conversion Semantics

When a user deposits an asset `A` into Abyss, the protocol executes:

```
deposit(A, amount_A):
  swap A → V at prevailing rate
  mint V_amount
  create commitment(V_amount, secret)
```

The swap may occur through integrated liquidity sources or protocol-defined conversion logic. Once converted, only \$V is tracked by the privacy system. The original asset never enters the anonymity pool directly.

This ensures:

* Homogeneous pool composition
* Elimination of asset-specific fingerprints
* Simplified ZK circuit constraints

***

### 7.3 Single-Denomination Privacy Pool

Inside the pool, all balances are denominated in \$V. There are no fixed denominations, no bucketization, and no per-asset sub-pools. This contrasts with systems that require users to choose deposit sizes or asset-specific pools, which fragment anonymity.

Formally, the pool state tracks:

```
PoolState :=
  { commitments_i(V_amount_i, secret_i) }
```

Privacy scales with the total volume and usage of \$V, not with individual asset popularity.

***

### 7.4 Exit and Redemption

Upon withdrawal, users receive \$V, which can then be redeemed for:

* The original asset
* A different supported asset
* A stable asset
* A payment destination

```
withdraw(secret, amount_V):
  prove ownership
  transfer V → recipient
```

Redemption is performed *after* privacy is achieved, meaning the final asset choice does not leak information about the deposit source .

***

### 7.5 Privacy and Economic Implications

Asset normalization has several second-order effects:

* Privacy becomes independent of asset diversity
* Liquidity concentrates around a single privacy asset
* ZK circuits remain constant-size and auditable
* Merchants and recipients receive fungible value without historical context

This design makes \$V a **privacy transport layer**, not a speculative asset.

***

### 7.6 Design Constraints and Non-Goals

\$V is not intended to:

* Replace stablecoins
* Act as a store of value
* Introduce monetary policy complexity

It exists to enforce privacy invariants. Any value dynamics are strictly incidental to that role.

***