Veil Protocol

1. Problem Statement

Public blockchains like Sui provide transparency by default. While transparency is valuable for protocol verification, it creates serious privacy vulnerabilities for users.

Privacy is not a feature. It is a fundamental property of sound money and functional financial infrastructure. Sui's ecosystem currently has no production-grade privacy solution. Veil fills this gap.

2. Design Principles

3. Protocol Architecture

3.1 Commitment Scheme - Poseidon Hash

Every private note in Veil is represented as a Poseidon hash commitment: C = Poseidon(value, secret, blinding). The value is hidden behind the commitment, and only the owner (who knows the secret and blinding factor) can open it.

Poseidon is a ZK-friendly hash function designed for arithmetic circuits. It operates over the BN254 scalar field and is approximately 50x cheaper inside ZK circuits compared to SHA-256, making it ideal for on-chain proof verification.

3.2 Merkle Tree Accumulator

All commitments are stored in an on-chain Merkle tree using Poseidon hashing at each level. When a user shields SUI, their commitment is inserted as a new leaf. The Merkle root is updated and stored on-chain, providing a compact digest of all existing notes.

To spend a note, the user provides a ZK proof that their commitment exists somewhere in the tree (using a Merkle path) without revealing which leaf. This is the core privacy mechanism: the spender proves membership in the set of all valid notes without identifying their specific note.

3.3 Nullifiers - Double-Spend Prevention

Each note has a unique nullifier derived deterministically from its secret: N = Poseidon(secret, leafIndex). When a note is spent, the nullifier is published on-chain and recorded in a global registry. If the same nullifier appears twice, the second transaction is rejected.

Critically, nullifiers are unlinkable to commitments. An observer sees a nullifier being published and a new commitment being created, but cannot determine which existing commitment was consumed.

3.4 ZK-SNARK Proofs - Groth16

Veil uses Groth16 zero-knowledge proofs over the BN254 curve for all privacy-critical operations. The proving system generates compact proofs (3 group elements, ~128 bytes) that are verified on-chain using Sui's native sui::groth16::verify_groth16_proof function.

3.5 Stealth Addresses & ECDH Note Discovery

Recipients register a StealthMeta on-chain containing their BLS12-381 view and spend public keys. These keys are deterministically derived from the wallet's signature, so the same wallet always produces the same keys on any device. When a user first connects, their StealthMeta is automatically registered on-chain as an owned object.

When sending VEIL, the sender looks up the recipient's view_pubkey from their on-chain StealthMeta. The sender generates an ephemeral keypair (r, R = r*G), computes a shared secret via ECDH: s = blake2b256(r * view_pubkey), and encrypts the note's secrets (value, secret, blinding) into a 125-byte memo stored on-chain alongside the commitment.

The recipient automatically discovers received notes during recovery by scanning all on-chain memos. For each memo, they compute the same shared secret using their view private key: s = blake2b256(viewPrivKey * R). If the checksum verifies, the note belongs to them. No manual sharing of note codes or out-of-band communication is required.

3.6 Privacy Pool

Users enter privacy by shielding: depositing transparent SUI and receiving a private note (commitment in the Merkle tree). They exit by unshielding: providing a ZK proof that they own a valid note, publishing its nullifier, and receiving transparent SUI.

The privacy pool acts as a fungibility set. The larger the pool (more active commitments and more transaction volume), the stronger the anonymity guarantees. The fair launch emission system is designed specifically to bootstrap this pool by rewarding early shielding.

3.7 Encrypted Recovery & Dual Memo System

When notes are created, an encrypted memo is stored on-chain as part of the LeafInsertedEvent. The memo format depends on who needs to read it:

During recovery, the scanner tries both formats for every on-chain event. If either decryption succeeds and the resulting commitment matches, the note is added to the wallet. Nullifier status is checked on-chain to distinguish spendable notes from already-spent ones.

4. VEIL Token Economics

4.1 Fair Launch

VEIL uses a fair launch model with zero pre-mine. No tokens exist at genesis. All 210,000,000 VEIL are minted exclusively through protocol usage and predefined allocations, with 75% earned directly by users (60% privacy pool rewards + 15% LP incentives).

4.2 Token Allocation

4.3 Emission Schedule

The 60% privacy pool allocation (126M VEIL) is distributed through a halving emission schedule. Users earn VEIL proportional to the amount of SUI they shield. The emission rate halves every 6 months across 4 halvings, ending permanently after 24 months.

4.4 Utility

4.5 Fee Structure

Protocol fees are collected in VEIL on every shield and unshield operation. Fee revenue is used for: buyback and burn (40%), staking rewards (30%), development fund (20%), and treasury reserve (10%).

5. On-Chain Architecture

Veil Protocol is implemented as a suite of Move smart contracts deployed on Sui. The modular design separates concerns across 11 contracts, each handling a specific aspect of the privacy system.

Why Sui?

6. Client SDK

The TypeScript SDK handles all off-chain operations: key management, proof generation, stealth address scanning, note encryption, and transaction construction. It is built on @noble/curves (BLS12-381), @noble/hashes (blake2b, sha256), and circomlibjs (Poseidon hashing).

7. Roadmap

8. Risks and Mitigations

9. Conclusion

10. How to Use Veil Protocol

Getting Started

Buying VEIL

Sending VEIL Privately

Receiving VEIL

Recovering Notes on a New Device

Contract Addresses

All contracts deployed on Sui Testnet. Mainnet deployment pending security audit.