Privacy Guarantees

This system is designed to provide strong, layered privacy guarantees through cryptographic mechanisms, protocol design, and smart contract architecture. It ensures users can send, receive, and store assets pseudonymously — without revealing their real-world identity or wallet address—unless they choose to disclose it. While transaction data is public, the system minimizes identifiable metadata and supports forward secrecy for privacy-preserving interactions.

1. Pseudonymous Identities with Commitment Hashes

Every lockbox and balance identity are derived from a double-hashed combination of an email and a secret passphrase:

• The system uses a global salt (publicly known) and combines it with email + passphrase to derive a hashed commitment. With sufficient entropy in passphrase and passwords, the global salt ensures rainbow table attacks are infeasible.

• Users are represented on-chain via these commitments rather than traditional wallet addresses.

• No party — not even the contract — can reverse the hash to learn the original identifier.

2. Forward Secrecy via Evolving Salts

The system ensures forward secrecy by introducing salt iteration:

• Each user sets up their own email / password combination for their private balance.

• Each time a user sends or claims funds, a new salt is generated (advanceSalt()), ensuring historical commitments are deprecated and unusable after each iteration, making replay attacks and metadata linkage infeasible.

3. Private Claim and Withdraw Operations

Claiming and withdrawing funds happen through privacy-preserving commitment flows:

• The funds are transferred to a balance commitment, not to a wallet, preserving recipient anonymity.

• To withdraw, the user must present a valid proof and provide a new nextCommitment for future operations.

• The contract validates commitment ownership using hash preimages and ensures privacy by requiring new commitments with each withdrawal.

4. No Wallet Address Correlation

Unlike standard crypto systems:

• The sender never learns the recipient’s personal wallet address.

• Funds can be sent to an email+passphrase combo before the recipient even has a wallet.

• Alternatively, funds can be sent to a pseudonymous address that forwards money to the recipient’s balance directly. This is via a Forwarder contract, but the final destination is still a balance, not an EOA.

5. Commitment Chaining and Burn Protection

The system enforces non-reusability of commitments. The contract uses a commitment chain to resolve balance transfers from outdated commitments to the most recent one. It also preserves auditability:

• Each commitment is used exactly once per transfer or withdrawal.

• Attempting to reuse a previous commitment to transfer or withdraw will revert the transaction.

• Internal chaining ensures deposits into a previous commitment will reach the current one, and the system knows the history without learning the actual identity.

6. Anonymity with Deterministic Forwarders

When depositing into a lockbox, users may use a deterministically deployed Forwarder contract via create2. This allows sending funds from shared custodial wallets (e.g. Binance / Crypto.com) to a recipient's pseudonymous balance:

• The Forwarder contract is deployed automatically as soon as the recipient retrieves their pseudonymous address, ensuring the contract is in place before any funds are sent.

• Any deployed Forwarder is validated on-chain to confirm it matches the expected bytecode. This prevents malicious contracts from redirecting funds to rogue wallets.

• In the unlikely event that an attacker launched a front-running attack and deployed a malicious contract at the expected address, the client app will advise the recipient to change their password, rendering the affected commitment obsolete and shifting the balance to a fresh, secure pseudonymous address.

7. Resistance to On-Chain Surveillance and Linking

The system is designed with minimal metadata leakage. No identity is stored on-chain. Association with real users is only feasible through existing KYC of wallets used in depositing or withdrawals.