Shielded Settlement (SMILE v2)

Overview

BTX includes a native shielded transaction pool based on SMILE v2, a lattice-based confidential transaction system introduced at genesis (block 0). In the v0.33 release-line production policy, the active support surface is strict shielded-to-transparent exits and wallet recovery for existing shielded state. Transparent-to-shielded deposits, z-to-z sends, re-shielding, and bridge shield ingress are not production-supported.

Current Production Status

Protected Assets

Spend Surfaces and Status

SMILE v2 defines three transaction paths that share the same proof system and note format. Their production status differs after the v0.33 release-line shielded wind-down heights:

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

Before the shielded sunset, shielded accounts were managed through a consensus-enforced registry with bounded growth. New shielded appends are disabled at height 125000, so these limits describe the historical bounded surface rather than a currently open production deposit path:

Consensus Limits

BATCH_SMILE Bridge Path

The shielded pool has consensus-visible bridge commitment surfaces through the BATCH_SMILE transaction family, but bridge shield ingress is not production-supported after the sunset heights above. Bridge structures may still commit to historical ingress data and recovery/exit metadata; they should not be read as an active transparent-to-shielded deposit path. See the Bridges specification for the current bridge commitment model.

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