SIP-0004: Shielded SRC-20 — Privacy Extension (Phased Approach)

[reinamora137]

SIP-0004: Shielded SRC-20 — Privacy Extension

Status: Draft
Author: reinamora137
Created: 2026-02-15
Requires: None (independent of SIP-0001/0002/0003, but interacts — see below)
Related: SIP-0001 (#685), SIP-0003 (#485)

---

Abstract

This proposal introduces optional privacy features for SRC-20 tokens through a phased approach: stealth addresses (Phase 1), confidential amounts via Pedersen commitments + Bulletproofs (Phase 2), and a full ZK-SNARK shielded pool (Phase 3). Each phase is independently valuable and ships incrementally, with later phases contingent on adoption metrics from earlier phases.

Motivation

SRC-20 tokens currently operate with full transparency: balances, transfers, and addresses are visible to anyone via chain analysis or indexers. This limits adoption in privacy-sensitive use cases.

Market signal: Privacy coins outperformed the broader market by ~290% in 2025. Monero hit ATH in early 2026. The demand for privacy on Bitcoin is real and growing.

Competitive gap: No Bitcoin meta-protocol (BRC-20, Runes, Ordinals, SRC-20) has shipped any privacy features. SRC-20 would be the first.

SRC-20's unique advantage: Data stored in unprunable UTXO set (OLGA/P2WSH encoding) provides permanent, verifiable privacy — unlike ephemeral witness-based approaches.

Design Principles

1. Opt-in only — Transparent operations remain the default. Privacy is never mandatory.
2. All data in OLGA — No Taproot witness split. All proof/commitment data goes in unprunable P2WSH outputs. This costs more but preserves re-indexing capability.
3. Phased deployment — Each phase is independently useful. Phase 3 only proceeds if Phase 1-2 demonstrate demand.
4. Audit keys built-in — Viewing keys for selective disclosure (regulatory compliance) from day one.
5. Backward compatible — Existing transparent SRC-20 operations unchanged.

Phase 1: Stealth Addresses (Receiver Privacy)

What it does: Hides the recipient's address. Sender generates a one-time stealth address for each transfer. Only the recipient (with their viewing key) can identify and claim the transfer.

New fields on transfer operation:

{
  "p": "SRC-20",
  "op": "transfer",
  "tick": "KEVIN",
  "amt": "1000",
  "dest_stealth": "03a1b2c3...stealth_meta_address",
  "ephemeral_key": "02d4e5f6...one_time_pubkey"
}

How it works:

1. Recipient publishes a stealth meta-address (derived from their spending key + viewing key)
2. Sender generates one-time stealth address using ECDH: stealth_addr = hash(ephemeral_key * viewing_key) + spending_key
3. Sender includes ephemeral_key in the transfer
4. Recipient scans all transfers, uses viewing key to identify which stealth addresses belong to them
5. Indexer credits the derived stealth address; recipient can spend from it

Privacy achieved: Observers cannot link transfers to the recipient's main address.

Implementation complexity: Low

• ~2 weeks indexer work
• Standard ECDH cryptography (no ZK proofs, no trusted setup)
• Libraries: secp256k1 (already used in Bitcoin)

Cost impact: Minimal (~64 bytes additional per transfer)

---

Phase 2: Confidential Amounts (Pedersen Commitments + Bulletproofs)

What it does: Hides transfer amounts. Balances and transfer values are replaced by cryptographic commitments. Bulletproof range proofs ensure values are positive without revealing them.

New fields on transfer operation:

{
  "p": "SRC-20",
  "op": "confidential_transfer",
  "tick": "KEVIN",
  "input_commitment": "commitment_to_sender_balance",
  "output_commitment_1": "commitment_to_recipient_amount",
  "output_commitment_2": "commitment_to_sender_change",
  "range_proof": "bulletproof_hex_encoded",
  "excess": "pedersen_blinding_factor_excess"
}

How it works:

1. Amounts are replaced by Pedersen commitments: C = v*G + r*H (value v, blinding factor r)
2. Bulletproof proves: 0 ≤ value ≤ 2^64 (no inflation, no negative values)
3. Indexer verifies: sum(input_commitments) == sum(output_commitments) (value conservation)
4. Indexer verifies Bulletproof range proof validity
5. Only the sender and recipient know the actual amounts (via shared blinding factors)

Privacy achieved: Transfer amounts hidden. Combined with Phase 1 stealth addresses: both recipient AND amount are private.

Implementation complexity: Medium

• ~6-8 weeks indexer work
• Bulletproofs: ~600-700 byte proofs (no trusted setup!)
• Requires Rust FFI for verification performance (btc_stamps already has Rust FFI for tx parsing)
• Libraries: bulletproofs (dalek-cryptography), secp256k1-zkp

Cost impact: ~700-900 bytes additional per transfer (Bulletproof + commitments)

Key advantage over Groth16: No trusted setup ceremony required.

---

Phase 3: Full Shielded Pool (ZK-SNARKs)

Contingent on: Phase 1-2 adoption metrics (≥1,000 active privacy users, ≥10% of SRC-20 volume using confidential transfers)

What it does: Complete privacy — sender, recipient, and amount all hidden. Tokens enter a shielded pool and can be transferred privately within it.

New operations:

// Deposit to shielded pool
{"p": "SRC-20", "op": "shield", "tick": "KEVIN", "amt": "1000",
 "commitment": "note_commitment", "proof": "groth16_proof"}

// Private transfer within pool
{"p": "SRC-20", "op": "shielded_transfer", "tick": "KEVIN",
 "nullifier": "spent_note_nullifier", "commitment": "new_note_commitment",
 "proof": "groth16_proof", "encrypted_note": "recipient_ciphertext",
 "merkle_root": "current_tree_root"}

// Withdraw from shielded pool
{"p": "SRC-20", "op": "unshield", "tick": "KEVIN",
 "nullifier": "spent_note_nullifier", "proof": "groth16_proof",
 "dest": "bc1q_transparent_address", "amt": "1000"}

ZK Circuit proves (without revealing):

• Note exists in the commitment Merkle tree
• Nullifier is correctly derived (prevents double-spend)
• Value is conserved (no inflation)
• Sender has the spending key

Implementation complexity: Very High

• ~6-12 months development
• Groth16 proofs (~192 bytes, fast verification, BUT requires trusted setup ceremony)
• Alternative: Halo2 (no trusted setup, but larger proofs ~868+ bytes, slower verification)
• New indexer state: nullifier set (append-only), commitment Merkle tree, shielded supply tracking
• Client-side: proof generation library, note management, viewing key derivation
• Rust FFI verifier mandatory (Python verification is 500-2000x too slow)

Cost impact: 1.5-3KB per shielded transfer (proof + public inputs + encrypted note)

Critical requirement: ALL data must be in OLGA (unprunable P2WSH). Do NOT use Taproot witness — witness data is prunable and would break re-indexing capability.

---

Indexer State Changes

Phase 1

• Stealth address registry (optional — recipients can announce stealth meta-addresses)
• Scanning logic for ephemeral key → stealth address derivation

Phase 2

• Replace balance tracking with commitment tracking for confidential accounts
• Bulletproof verifier (Rust FFI)
• Commitment-based balance validation

Phase 3

• src20_shielded_notes table (commitment Merkle tree)
• src20_nullifiers table (append-only, 32 bytes each)
• Aggregate shielded supply per token (public — verifiable against transparent supply)
• Groth16 verifier (Rust FFI)
• Merkle tree state management

Nullifier Set Growth (Phase 3)

Scale	Storage	Concern?
10K shielded transfers	320 KB	No
100K transfers	3.2 MB	No
1M transfers	32 MB	No
10M transfers	320 MB	Manageable

Spam protection: require meaningful Bitcoin fees per shielded operation (minimum fee floor).

---

Security Considerations

Phase 1 (Stealth Addresses)

• Low risk: Standard ECDH, well-understood cryptography
• Weakness: Timing analysis can still correlate sender/receiver if transfer patterns are predictable

Phase 2 (Confidential Amounts)

• Medium risk: Bulletproofs are well-audited (used in Monero since 2018)
• No trusted setup: Eliminates ceremony risk entirely
• Weakness: Transaction graph still visible (who transacts with whom, just not how much)

Phase 3 (Shielded Pool)

• High risk: Novel ZK circuits require independent audit ($150-300K)
• Trusted setup (if Groth16): Multi-party ceremony, minimum 50+ participants
• Anonymity set concern: If fewer than ~1,000 users are in the shielded pool, timing/amount/flow analysis can deanonymize transfers. This is why Phase 3 is contingent on Phase 1-2 adoption.
• Indexer consensus: If indexers disagree on proof validity, SRC-20 state forks with no Bitcoin-level resolution. Shared test vectors and reference implementation are critical.

Regulatory Compliance

• Viewing keys (all phases): Allow selective disclosure to auditors/regulators
• Opt-in only: Transparent mode remains default
• Framing: "Verifiable privacy" — compliance-compatible, not evasion-focused

---

Relationship to Other SIPs

SIP	Relationship	Notes
SIP-0001 (Conditional Transfers)	Independent	Can ship in any order. Combining shielded + conditional transfers (shielded HTLC) requires a dedicated ZK circuit — Phase 3+ scope.
SIP-0002 (UTXO Binding)	Independent	UTXO binding is for art stamp trading. Shielded pool is for SRC-20 balances. No overlap.
SIP-0003 (Bridge)	Independent but interacts	Shielded tokens must "unshield" before bridging (bridge needs to verify supply). A shielded bridge would be exponentially more complex — out of scope.
SIP-0000 (Process)	Follows SIP process	This proposal is the first to use the phased SIP approach.

Recommended Implementation Order (All SIPs)

SIP-0001 (Conditional Transfers)     ← Foundation: swaps, bridges, escrow
    │
    ├── SIP-0003 (Bridge)            ← Benefits from SIP-0001's HTLCs
    │
    └── SIP-0004 Phase 1 (Stealth)   ← Independent, can ship anytime
            │
            └── SIP-0004 Phase 2 (Confidential Amounts)
                    │
                    └── SIP-0004 Phase 3 (Full Shielded Pool)
                            │                  ↑
                            │          Only if ≥1000 active
                            │          privacy users from Ph 1-2
                            │
SIP-0002 (UTXO Binding)              ← Independent track, ships when ready

---

Resource Estimates

Phase	Development	Audit	Timeline	Go/No-Go Gate
Phase 1 (Stealth)	~$20K	Not required (standard crypto)	2-3 months	None — ship it
Phase 2 (Bulletproofs)	~$60-80K	~$30-50K (Bulletproof circuits)	6-8 months	Phase 1 adoption
Phase 3 (ZK-SNARKs)	~$150-200K	~$150-300K (full ZK audit)	12-18 months	≥1,000 active privacy users
Total	~$230-300K	~$180-350K	~20-29 months	Phased gates

---

Open Questions

1. Stealth address standard: Use EIP-5564-style stealth addresses or design SRC-20-specific scheme?
2. Confidential supply tracking: How does the indexer prove total supply is correct when individual balances are hidden? (Answer: homomorphic property of Pedersen commitments — sum of commitments = commitment to sum)
3. Phase 3 proof scheme: Groth16 (small proofs, trusted setup) vs Halo2 (no setup, larger proofs)?
4. Viewing key granularity: Per-token viewing keys or per-address?
5. Fee model: Should shielded operations have a minimum fee floor to prevent anonymity set pollution?
6. Activation: Each phase has its own activation block? Or rolling activation?

---

Test Vectors

Phase 1 — Stealth Address

{
  "description": "Valid stealth transfer",
  "recipient_spending_key": "0x1234...",
  "recipient_viewing_key": "0x5678...",
  "stealth_meta_address": "st:btc:03a1b2c3...+02d4e5f6...",
  "ephemeral_key": "02abcdef...",
  "derived_stealth_address": "bc1q_derived_stealth...",
  "expected": "recipient can derive and spend from stealth_address"
}

Phase 2 — Confidential Transfer

{
  "description": "Valid confidential transfer - amounts hidden, value conserved",
  "input_value": 1000,
  "output_value_1": 700,
  "output_value_2": 300,
  "input_commitment": "C_in = 1000*G + r1*H",
  "output_commitment_1": "C_out1 = 700*G + r2*H",
  "output_commitment_2": "C_out2 = 300*G + r3*H",
  "excess": "(r2+r3-r1)*H",
  "range_proof": "bulletproof proving 0 <= values <= 2^64",
  "expected": "valid_confidential_transfer"
}

---

This SIP takes the "prove demand before building complexity" approach. Stealth addresses are cheap, useful, and ship fast. If privacy finds product-market fit on SRC-20, we scale up. If not, we've spent $20K instead of $500K.