Private Deposit

The Deposit mechanism acts as the Ingress Bridge for the privacy protocol. It allows users to convert transparent, public assets (Native BNB or BEP-20 tokens) into opaque, private "Notes" within the protocol.

Technically, this process is known as Shielding. When a user deposits funds, the assets are locked in the protocol's smart contract, and a cryptographic "Commitment" representing those funds is added to the protocol's state. Crucially, while the act of depositing is public, the ownership of the resulting private note is mathematically hidden.

1. Client-Side Note Construction

To ensure that the protocol never possesses the user's private keys or financial data, the "Note" is constructed entirely within the client's browser (or wallet environment). This involves generating cryptographically strong random values.

The Commitment Scheme

A "Note" is defined by a 32-byte Commitment Hash. The client computes this using the Poseidon Hash function, which is optimized for efficiency within Zero-Knowledge circuits.

The formula for a commitment is:

$Commitment = \text{Poseidon}(Secret, Amount, Randomness, TokenAddr)$

• Secret: A 31-byte random value derived from the user's signature. This acts as the "Private Key" for this specific pile of money.

• Amount: The integer value of tokens being deposited.

• Randomness (Blinding Factor): A high-entropy salt that prevents rainbow table attacks. Even if two users deposit exactly 10 BNB, their Commitments will look completely different due to this value.

• Token Address: Binds the note to a specific asset type, preventing cross-asset spoofing.

Local Persistence

Once generated, the client encrypts the raw values ($Secret$, $Randomness$, etc.) and stores them in the user's local database (e.g., IndexedDB). Critical: If this local data is lost before the note is spent, the funds are cryptographically unrecoverable, as not even the protocol admins can regenerate the secret.

2. Proof of Correctness

Before the transaction is submitted to the blockchain, the client generates a Zero-Knowledge Proof (Groth16).

Because the smart contract cannot see the inputs (Secret/Randomness), it needs a guarantee that the Commitment was formed correctly. The ZK-Proof attests to the following statement without revealing the data: "I have generated a Commitment that validly hashes to C, and it represents a deposit of exactly X tokens."

This prevents "Griefing Attacks" where malicious users might try to insert invalid or garbage hashes into the protocol's Merkle Tree.

3. On-Chain Settlement

The deposit transaction serves two purposes: asset custody and state insertion.

Asset Locking

The interaction differs slightly based on the asset type:

• Native BNB: The transaction value (msg.value) is sent directly to the Stealth Pool contract.

• ERC-20 Tokens: The contract utilizes transferFrom to pull the approved amount from the user's wallet into the Pool's vault.

Verification & Accumulation

Upon receiving the transaction, the Smart Contract performs the following atomic operations:

1. Verifier Call: It passes the ZK-Proof ($A, B, C$) and the Public Signal (The Commitment) to the Verifier contract. If the math doesn't check out, the transaction reverts.

2. State Insertion: If verified, the contract appends the new Commitment to the global BalanceRegistry (or Merkle Tree).

3. Pool Update: The global public balance of the pool increases, but the internal accounting only records the opaque hash.

4. Privacy Implications

It is important to understand the privacy boundary during a deposit:

• The Public Side: The blockchain explorer will show a transaction: User Wallet A $\to$ Stealth Pool : 10 BNB. This link is visible.

• The Private Side: The blockchain records a new "Commitment" leaf in the tree.

• The Severed Link: There is no mathematical way to link that specific Commitment back to User Wallet A without knowing the .

When the user later spends or withdraws these funds, they will prove they own "one of the commitments in the tree" without revealing which specific commitment it is. This effectively mixes the user's 10 BNB with every other deposit in the pool, creating an Anonymity Set.