Shielded Settlement (SMILE v2)

Overview

BTX includes a native shielded transaction pool based on SMILE v2, a lattice-based confidential transaction system active from genesis (block 0). SMILE v2 provides amount confidentiality, sender anonymity via ring signatures, and receiver privacy via ML-KEM encrypted notes. All cryptographic primitives are post-quantum, built on Module-LWE and Module-SIS hardness assumptions over the Dilithium/CRYSTALS parameter set.

Protected Assets

Three Spend Surfaces

SMILE v2 defines three transaction paths that share the same proof system and note format:

Cryptographic Primitives

Lattice Parameters

Commitment Scheme

Values are committed using lattice Pedersen commitments: C = A · blind + g · value (mod q). The scheme is computationally hiding under MLWE and computationally binding under MSIS.

Range Proofs

Each output carries a range proof decomposing the committed value into 51 individual bit commitments. Each bit is proven to be 0 or 1 via a lattice OR-proof, and a Schnorr-style relation proof binds the decomposition to the original commitment.

Balance Proofs

A Schnorr-style balance proof demonstrates that sum(input_commitments) − sum(output_commitments) − Commit(fee, 0) = Commit(0, delta_blind), preventing supply inflation without revealing individual amounts.

Note Commitments and Nullifiers

Note Structure

A shielded note contains: value, owner commitment, randomness (rho, rseed), source binding, and an optional memo. Notes are stored as commitments in a Merkle tree of depth 32 (nShieldedMerkleTreeDepth).

Nullifiers

Each spend publishes a deterministic nullifier derived from the key image: DeriveInputNullifier(spending_key, ring_member_commitment). The NullifierSet (LevelDB-backed with in-memory cache, capped at 2,000,000 entries) enforces uniqueness to prevent double-spending. The same note always produces the same nullifier regardless of which ring it appears in.

Ring Signatures

Sender anonymity uses module-lattice ring signatures. For each input, the prover demonstrates knowledge of a short vector solving the Module-SIS relation for one ring member without revealing which one. The Fiat-Shamir transcript binds all ring members symmetrically, making them computationally indistinguishable under MLWE.

Note Encryption

Shielded outputs include encrypted note data so that recipients can discover and decode incoming payments:

1. Key encapsulation: ML-KEM (FIPS 203) establishes an IND-CCA2 shared secret with the recipient's public key.
2. Key derivation: HKDF-SHA256 derives an AEAD key from the ML-KEM shared secret.
3. Symmetric encryption: ChaCha20-Poly1305 AEAD encrypts the note plaintext (value, blinding factor, memo). Maximum ciphertext size: 2,048 bytes.

A 1-byte view tag (derived from KEM ciphertext and public key) enables recipients to quickly reject non-matching notes during wallet scanning, reducing trial-decryption cost at the expense of leaking 8 bits of recipient information to observers who can test candidate public keys.

Selective Disclosure

Shielded transactions support selective disclosure for compliance and audit: a note holder can reveal specific transaction details (value, sender, or both) to a designated auditor without breaking the privacy of other transactions. This is enabled by the separation between spending keys, viewing keys, and the ML-KEM encryption layer.

Account Registry

After the MatRiCT disable fork, shielded accounts are managed through a consensus-enforced registry with bounded growth:

Consensus Limits

BATCH_SMILE Bridge Path

The shielded pool integrates with the BTX bridge system via the BATCH_SMILE transaction family. Bridge batches can deposit into the shielded pool directly, creating synthetic credit notes that are indistinguishable from regular shielded outputs. This enables cross-layer transfers to enter the privacy pool without an intermediate transparent step. See the Bridges specification for the full settlement protocol.

Shielded State Recovery

Wallet recovery scans the full shielded Merkle tree using the owner's viewing key. The view-tag optimization rejects ~99.6% of notes without trial decryption. Recovery produces the complete set of unspent notes by cross-referencing discovered notes against the published nullifier set.

Security Assumptions