Skip to content

BCH Confidentiality Protocol v1

Draft protocol spec

Status: proposed draft
Purpose: define a protocol first confidentiality layer for BCH that supports wallet local discovery, covenant controlled state cells, and optional discovery acceleration without making any index server part of the trust model.

1. Summary

This protocol turns ordinary BCH UTXOs into protocol state cells locked by a confidential covenant. Once value enters the protocol, spending is no longer only signature authorization. Spending is a confidential state transition that must:

  1. satisfy the covenant rules
  2. bind to the real BCH transaction outputs
  3. create new protocol valid state
  4. allow intended receivers to discover inbound notes from chain data plus wallet keys

This draft keeps the protocol first framing:

  • the protocol is the product
  • wallet local pools are only an early implementation container
  • the chain is the source of truth
  • wallets implement protocol compatible discovery, tracking, and spend construction

This draft assumes the existing PIV0 public input boundary remains in place and continues to carry:

  • state_in
  • state_out
  • output_fingerprint_m2
  • batch_digest
  • fee_digest

This draft also assumes the BCH 2026 path that makes P2S outputs standard, raises standard unlocking bytecode to 10,000 bytes, raises token commitment length to 128 bytes, and adds loops and reusable functions, all of which make covenant controlled transactions and structured recovery envelopes practical on chain.

2. Goals

2.1 Required goals

  • no public recipient marker
  • no mandatory index server
  • wallet recovery from chain data plus wallet keys
  • confidential value represented as protocol governed note state
  • confidential transition outputs use fixed public carrier sats rather than public economic transfer values
  • tokenized protocol state cells remain the carrier of confidential transition state
  • output binding to real BCH outputs
  • on chain proof verification of the selected final proving backend for the fixed confidential-transfer statement
  • protocol entry, confidential transition, and protocol exit as first class actions
  • wallet note tracking and inbound note discovery as protocol obligations
  • support for multiple wallet sync modes without changing the protocol itself
  • baseline operation through wallet self-advance without mandatory proving or aggregation services

2.2 Non goals for v1

  • general many-recipient fan-out in one transaction
  • generalized recursive aggregation before the fixed-statement verifier is complete
  • mandatory aggregator or proving-service dependence for baseline protocol operation
  • broad proof-system abstraction beyond the selected backend needed for the first on-chain verifier
  • perfect consensus-level privacy for metadata outside the protocol envelope
  • full multi-wallet interoperability package before the fixed-statement prover/verifier path is complete
  • freezing protocol rules that are not required for the first fixed-statement confidential send/receive system

2.3 Delivery discipline for v1

The v1 delivery target is a fixed-statement confidential send/receive system with:

  • off-chain proof generation for one fixed confidential-transfer statement
  • on-chain verification of that selected proof system on BCH
  • no public receiver marker in the confidential transition path
  • no public economic transfer amount in confidential transition outputs
  • tokenized continuation outputs whose token commitment carries state_out

This draft does not require generalized proving flexibility before the first fixed-statement system is complete.

3. Verifier strategy

3.1 Fixed-statement first

The first proving backend MUST target a single fixed confidential-transfer statement rather than a generalized family of statements.

That fixed statement MUST cover at least:

  • source note ownership
  • note inclusion
  • nullifier correctness
  • receiver note creation
  • sender change note creation
  • committed-value conservation
  • transition consistency between state_in and state_out
  • consistency with the actual BCH continuation outputs bound by the current output-fingerprint policy

3.2 Split between host checks and proof checks

The confidential covenant enforcement path is split into:

  1. host-visible transition checks
  2. public input parsing
  3. proof-envelope parsing
  4. output binding to real BCH outputs
  5. tokenized state-cell carrier invariants

  6. state_out continuity into the continuation output token commitment

  7. proof-system verification

  8. succinct verification of the selected proving backend for the fixed confidential-transfer statement

The host path MUST NOT substitute for the proof verifier in the final backend target.

3.3 Backend selection rule

The selected proving backend MUST be chosen using verifier-first criteria:

  • true zero knowledge for witness data
  • practical off-chain proving for wallet use
  • practical on-chain verification on BCH under the 2026 target environment
  • compatibility with fixed-statement confidential transfers before broader generalization

Backend convenience for off-chain proving alone is not sufficient.

4. Design principles

  1. Protocol first

  2. all normative rules describe the shared confidentiality protocol, not a wallet local pool

  3. Wallet modes are implementation choices

  4. full node wallet, thin wallet, and index accelerated wallet must converge on the same protocol result

  5. No public recipient tag

  6. the chain must not expose a stable public hint saying a note belongs to a specific receiver

  7. Private ownership testing is unavoidable

  8. some wallet local recognition step is required

  9. the protocol should make that step cheap

  10. Discovery and tracking are separate

  11. discovery finds new inbound notes

  12. tracking follows already known protocol state cells and notes

  13. Index servers are optional accelerators

  14. they may return public candidates
  15. they must not be trusted for ownership or validity decisions

5. Normative language

The key words MUST, MUST NOT, SHOULD, and MAY are used in the usual normative sense.

6. Terminology

6.1 Core protocol terms

  • confidential covenant
    The covenant locking logic that enforces valid protocol state transitions.

  • protocol state cell
    A covenant controlled UTXO that carries protocol governed confidential state.

  • protocol valid state
    A state representation accepted by the covenant and by wallet side protocol rules.

  • confidential state transition
    A transaction that spends one or more protocol state cells and creates the next protocol valid state.

  • protocol entry
    A transaction that spends ordinary BCH value into a new protocol state cell.

  • protocol exit
    A transaction that converts protocol governed value back into ordinary BCH outputs.

  • wallet note tracking
    The wallet process of persisting, updating, and following discovered protocol notes and related state.

  • inbound note discovery
    The wallet process of discovering candidate confidential transfers and determining which notes belong to the wallet.

6.2 Envelope terms

  • RRE1
    Receiver Recovery Envelope v1. The proposed recovery envelope used for receiver discovery and note recovery.

  • transaction ephemeral pubkey R
    A transaction level one time pubkey used by intended receivers to derive a shared secret.

  • owner pubkey P_i
    A one time owner pubkey for note i.

  • note commitment cm_i
    The public commitment to note i inserted into protocol state.

6.3 Serialization conventions

Unless another frozen rule overrides them, this draft uses the following conventions:

  • hashes are raw 32 byte values
  • secp256k1 public keys are compressed 33 byte SEC1 encodings
  • serP(P) means compressed SEC1 serialization of point P
  • LE32(x) means unsigned 32 bit little endian encoding
  • varint means BCH CompactSize integer encoding
  • bytes means a length specified by an adjacent fixed width or varint field

7. Protocol roles

7.1 Sender

Constructs a protocol valid transition that creates one or more new notes.

7.2 Receiver

Scans chain data or candidate feeds, performs private ownership testing, recovers note data, validates state consistency, and persists wallet notes.

7.3 Wallet

Implements protocol compatible behavior for:

  • key management
  • candidate discovery
  • note recovery
  • note validation
  • note persistence
  • future spend construction

7.4 Chain

The chain is the source of truth for:

  • protocol transitions
  • covenant controlled outputs
  • state roots
  • actual BCH outputs
  • public recovery envelope bytes

7.5 Optional index server

A discovery accelerator that MAY index public protocol structure and public envelope bytes. It is not part of the trust model.

8. High level object model

The protocol uses the following objects.

8.1 Receiver identity

Each receiver is identified by a stealth style key pair set:

  • scan public key A
  • spend public key B

and the corresponding private keys:

  • scan private key a
  • spend private key b

The protocol requires the scan and spend split, but does not require one wallet derivation path.

Wallets SHOULD derive these keys deterministically from the wallet seed so recovery from seed phrase remains possible.

This protocol uses the same ownership structure as stealth address systems:

  • ownership testing uses the scan private key a
  • final spend authority derives from the spend private key b
  • one time owner keys are derived as P_i = B + t_i G
  • one time spend keys are derived as x_i = b + t_i mod n

8.1.1 Stealth compatibility

This protocol is compatible with stealth address constructions based on a scan and spend key split.

A receiver identity is defined by:

  • scan public key A
  • spend public key B

and corresponding private keys:

  • scan private key a
  • spend private key b

The sender and receiver procedures defined in this protocol are equivalent to a stealth addressing scheme in which:

  • the sender derives a shared secret using A
  • the receiver detects ownership using a
  • one time owner keys are derived from B

No additional public recipient identifier is required.

8.1.2 Key derivation independence

The protocol does not require a specific seed derivation path.

Wallets:

  • MUST produce valid (A, B) keypairs
  • MAY derive these keys from any deterministic or non deterministic scheme
  • MUST NOT assume that other wallets follow the same derivation path

Derivation paths are not part of consensus or protocol validity.

Wallets MAY use a BIP32 compatible derivation layout to derive stealth keys.

A recommended layout is:

m / 352' / coin_type' / account'
  ├── 0' / 0   spend key
  └── 1' / 0   scan key

Where:

  • 352' identifies stealth compatible keys
  • coin_type' SHOULD follow SLIP-0044
  • account' allows multiple independent receiver identities

This layout is provided for interoperability guidance only.

8.1.4 Relationship to paycodes and RPA

Reusable payment codes and similar schemes MAY be used to communicate receiver identities.

In such constructions:

  • the paycode encodes or derives (A, B)
  • the protocol operates only on (A, B)

The confidentiality protocol does not depend on any specific paycode format.

8.1.5 Domain separation recommendation

Wallets SHOULD avoid reusing the same receiver identity across unrelated domains.

Wallets SHOULD support separate derivation branches for:

  • transparent BCH activity
  • reusable payment codes
  • confidential protocol usage

This reduces cross domain linkage risk and improves long term privacy.

8.2 Public state cell

Each protocol state cell commits to:

  • protocol version
  • state digest
  • note root
  • nullifier root or equivalent spent set commitment
  • other public protocol fields required by the covenant

8.3 Note

A note is a confidential claim on protocol value. A note is not an ordinary BCH output to the receiver.

A note is represented by:

  • a public note commitment in protocol state
  • an encrypted recovery payload in RRE1
  • wallet local recovered note data
  • wallet local derived spend authority

8.4 Transparent stealth compatibility

A wallet MAY use the same receiver identity (A, B) and the same one time key derivation form for protocol exit outputs or optional transparent receive modes.

In such modes, a visible BCH output MAY be paid to a standard script derived from a one time public key P = B + tG.

This does not change the meaning of confidential notes inside protocol state cells. Confidential notes remain protocol objects, not ordinary BCH receiver outputs.

9. Transaction classes

9.1 Protocol entry

A protocol entry transaction:

  • spends ordinary BCH UTXOs
  • creates at least one protocol state cell
  • commits the initial note set or initial value representation
  • binds the state transition to real outputs using the existing output fingerprint mechanism

9.2 Confidential transition

A confidential transition transaction:

  • spends one or more protocol state cells
  • verifies protocol valid old state
  • creates the next protocol valid state
  • publishes RRE1
  • inserts new note commitments
  • updates nullifier or spent note state commitments
  • binds to real outputs using output_fingerprint_m2

9.3 Protocol exit

A protocol exit transaction:

  • spends protocol state
  • destroys or consumes notes
  • creates ordinary BCH outputs
  • still binds the public transition statement to the real outputs

9.4 Confidential amount mode v1 (frozen)

For confidential transitions in v1, economic transfer amount is represented in committed protocol state only.

Normative freeze:

  • The transferred amount MUST be represented only in note/state commitments and witness logic.
  • Public BCH output satoshis on confidential transition continuation outputs MUST be treated as carrier values only.
  • Confidential transition validity MUST NOT rely on public BCH output satoshis as the economic amount representation.
  • Wallet acceptance for confidential transitions MUST reject any shell that treats visible BCH output value as the transferred confidential amount.

Carrier sats policy for continuation outputs (v1):

  • Each continuation protocol state cell output MUST use a fixed, versioned carrier sat value configured for the statement profile.
  • Carrier sats are transport/relay values, not economic transfer values.
  • Carrier sat policy changes require an explicit profile/version change.

Tokenized state-cell carrier invariants (v1):

  • Confidential transition continuation outputs MUST be tokenized protocol state cells.
  • Continuation output token category+capability MUST be continuous with the spent state-cell input category+capability.
  • Continuation output token commitment MUST equal state_out.
  • The continuation output index MUST be deterministic and explicitly bound.
  • Default restoration candidate for the current single-continuation profile: fixed index 0.
  • Future profiles MAY use another deterministic index rule, but it MUST be explicit and versioned.

Fee treatment (v1):

  • Fees are public BCH amounts paid at transaction level.
  • Fee deduction MUST be accounted for in committed state transition logic (state_in -> state_out) and MUST be versioned by statement profile.
  • The protocol MUST distinguish fee leakage from confidential value transfer accounting.

Publicness split (v1):

  • Protocol entry: public BCH value enters confidential state.
  • Confidential transition: economic transfer amount remains committed/private; only carrier sats are public on continuation outputs.
  • Protocol exit: value may become public BCH outputs again.

10. Public input boundary

This draft preserves the existing PIV0 public input boundary as the transport for:

  • state_in
  • state_out
  • output_fingerprint_m2
  • batch_digest
  • fee_digest

PIV0 does not itself define the hash policy for output_fingerprint_m2. OFm2/v1 remains frozen for the legacy tokenless compatibility profile, but confidential amount mode requires a token-aware successor policy before real prover activation.

For RRE1, the protocol relies on:

  • state_out
  • output_fingerprint_m2

as domain separated binding inputs during envelope construction and receiver recovery.

11. Receiver Recovery Envelope v1

11.1 Purpose

RRE1 serves two jobs:

  1. receiver recognition
  2. receiver note recovery

It is designed so that:

  • outsiders can see the envelope
  • outsiders cannot tell which receiver it targets
  • the intended receiver can test ownership cheaply
  • full decryption only happens for matching notes

11.2 Placement

For v1, RRE1 SHOULD be placed in the unlocking bytecode of the protocol transition input.

Reason:

  • it is relayed and mined as ordinary transaction data
  • it is visible in mempool and blocks
  • it travels with the transition it describes
  • 2026 standard unlocking bytecode capacity makes this practical

Alternative placements MAY be defined later, but v1 SHOULD freeze one deterministic placement rule.

11.3 Public layout

RRE1_SECTION
- rre_version                : 1 byte
- rre_flags                  : 1 byte
- tx_ephemeral_pubkey_R      : 33 bytes
- protocol_output_index      : varint
- recipient_note_count       : varint
- NOTE_ENTRY[i] repeated recipient_note_count times:
  - owner_pubkey_P_i         : 33 bytes
  - note_commitment_cm_i     : 32 bytes
  - encrypted_payload_digest32_i : 32 bytes

11.4 Public fields

  • rre_version
    Envelope version.

  • rre_flags
    Reserved for optional features such as memo presence.

  • tx_ephemeral_pubkey_R
    A transaction level one time pubkey used by receivers to derive a shared secret.

  • protocol_output_index
    The index of the transaction output carrying the next protocol state cell. This index MUST refer to the tokenized continuation output whose token commitment equals state_out under the active carrier invariant profile.

  • recipient_note_count
    Number of note entries in the envelope.

  • owner_pubkey_P_i
    One time owner pubkey for note i.

  • note_commitment_cm_i
    Public note commitment for note i.

  • encrypted_payload_digest32_i
    HASH256 of the PBv1 encrypted payload bytes for this note entry. This keeps RRE1 compact enough for hints transport while still binding discovery metadata to ciphertext bytes.

11.5 No public recipient tag

RRE1 MUST NOT include:

  • receiver id
  • receiver hint
  • reusable public scan tag
  • any stable public marker that lets third parties correlate repeated payments to the same receiver

12. Cryptographic primitives

This draft proposes the following v1 choices:

  • curve: secp256k1
  • point serialization: SEC1 compressed form
  • shared secret derivation: ECDH over secp256k1
  • transcript hashing: tagged SHA256
  • scalar derivation: hash to scalar reduced mod curve order
  • note encryption: XChaCha20-Poly1305
  • note commitment hash: HASH256("NTL1" || encodeNoteLeafV1(note_leaf_v1))

12.1 Domain tags

The following domain tags are proposed:

  • "bch-ct/v1/shared-secret"
  • "bch-ct/v1/owner"
  • "bch-ct/v1/note-key"
  • "NTL1" (note commitment leaf domain via NoteLeafV1)
  • "P3-16:nullifier:v1" (nullifier derivation domain for the current confidential-send path)

13. Sender construction

For receiver (A, B) and note index i:

  1. choose random scalar r
  2. compute transaction ephemeral pubkey: R = rG
  3. compute shared point: S = rA
  4. derive shared secret transcript: ss = TaggedHash("bch-ct/v1/shared-secret", serP(S))
  5. derive owner tweak: t_i = HashToScalar("bch-ct/v1/owner" || ss || LE32(i) || state_out || output_fingerprint_m2)
  6. compute one time owner pubkey: P_i = B + t_i G
  7. construct note plaintext m_i
  8. compute note commitment: cm_i = NoteCommit(P_i, m_i)
  9. derive note encryption key: k_i = HKDF-SHA256(ikm = ss, salt = state_out || output_fingerprint_m2 || LE32(i), info = "bch-ct/v1/note-key")
  10. encrypt note body:
    ct_i = XChaCha20-Poly1305_Encrypt(key = k_i, aad = rre_version || R || P_i || cm_i || state_out || output_fingerprint_m2, plaintext = m_i)
  11. publish R, P_i, cm_i, and HASH256(ct_i) in RRE1; publish ct_i in PBv1 encrypted payload section

13.1 Sender obligations

The sender MUST:

  • use a fresh random r per transaction
  • never reuse R
  • bind key derivation to state_out and output_fingerprint_m2
  • ensure every published cm_i is actually inserted into the next protocol state
  • ensure the envelope and state transition refer to the same transaction reality

14. Receiver recovery

For each candidate confidential transition transaction:

  1. parse RRE1_SECTION
  2. read R
  3. compute shared point: S = aR
  4. derive shared secret transcript: ss = TaggedHash("bch-ct/v1/shared-secret", serP(S))
  5. for each note entry i:
  6. derive t_i = HashToScalar("bch-ct/v1/owner" || ss || LE32(i) || state_out || output_fingerprint_m2)
  7. compute P_i' = B + t_i G
  8. compare P_i' with public P_i
  9. if P_i' != P_i, discard the note without decrypting
  10. if P_i' == P_i:
    • require HASH256(ct_i) to match encrypted_payload_digest32_i
    • derive k_i
    • decrypt ct_i
    • parse note plaintext m_i
    • recompute cm_i' = NoteCommit(P_i, m_i)
    • require cm_i' == cm_i
    • require cm_i to match the note commitment inserted by the observed state transition
    • derive one time spend private key: x_i = b + t_i mod n
    • persist the wallet note record

14.1 Important property

This design means the wallet does:

  • one ECDH style scan derivation per candidate transaction
  • cheap public key comparisons per note
  • decryption only for matching notes

It does not require trial decryption of every note.

15. Note plaintext

The encrypted note body MUST contain enough data for:

  • wallet note persistence
  • note commitment recomputation
  • future spend construction

Proposed v1 layout:

NOTE_PLAINTEXT_V1
- note_version
- asset_id
- amount
- note_blind
- nullifier_seed
- memo_len
- memo_bytes
- optional_wallet_metadata

15.1 Privacy expectations

The following SHOULD remain private inside the ciphertext:

  • amount
  • note blinding
  • nullifier seed
  • memo
  • wallet metadata

16. Note commitment

For this v1 path, note commitments are frozen to the canonical NoteLeafV1 encoding and hash policy already implemented in @bch-stealth/zk-notes:

Normative formula freeze: spec/note-commitment-nullifier-formulas-v1.md.

encodeNoteLeafV1(note_leaf_v1) =
  "NLeaf1" ||
  poolId32 ||
  shardId32 ||
  ownerCommitment32 ||
  valueCommitment32 ||
  nonce32

cm_i = HASH256("NTL1" || encodeNoteLeafV1(note_leaf_v1))

Where:

  • ownerCommitment32, valueCommitment32, and nonce32 come from the sender and receiver construction rules in Section 13.
  • cm_i is the same value persisted as noteHashHex in wallet-note records and inserted into the next noteRoot.

Nullifier derivation is also frozen for the current confidential-send path:

nullifier32 =
  HASH256(
    "P3-16:nullifier:v1" ||
    noteId32 ||
    noteHash32 ||
    senderPub33 ||
    receiverSpendPub33 ||
    shardId32
  )

17. State transition requirements

A confidential transition transaction MUST satisfy all of the following:

  • old state binding
    public inputs and covenant checks must identify the previous protocol state

  • new state binding
    public inputs and covenant checks must identify the next protocol state

  • output binding
    the transition statement must bind to the real BCH outputs through output_fingerprint_m2

  • note commitment insertion
    the public commitments cm_i published in RRE1 must match the commitments inserted into the next state

  • spent state update
    nullifier or spent note state must be updated consistently

  • transaction reality consistency
    RRE1, PIV0, and the actual BCH outputs must all describe the same transition

18. Wallet behavior

Wallets MAY implement different sync modes, but all wallets MUST follow the same protocol rules after they obtain a candidate transaction.

The deterministic replay and rollback rules for this implementation slice are captured in spec/recovery-scan-rules-v1.md.

18.1 Required wallet duties

Every protocol compatible wallet MUST be able to:

  • parse candidate confidential transitions
  • parse RRE1
  • perform the receiver recovery algorithm locally
  • validate note commitments against the observed transition
  • persist wallet note records deterministically
  • track already known protocol notes and state cells
  • recover from chain data plus wallet keys

18.2 Wallet modes

A. Full local mode

The wallet:

  • watches mempool and blocks
  • scans protocol candidates locally
  • does all recognition and validation locally

B. Thin wallet mode

The wallet:

  • syncs headers
  • uses protocol level block filters or other public candidate reduction
  • fetches only candidate blocks or transactions
  • performs local recognition and validation

C. Index accelerated mode

The wallet:

  • uses an optional index server to obtain public candidates
  • still performs local recognition and validation
  • can recover without the index server

18.3 Protocol invariance across modes

Wallet mode MUST NOT change:

  • note ownership rules
  • note commitment rules
  • state validity rules
  • spendability rules

Wallet mode only changes:

  • how candidate transactions are discovered efficiently

18.4 Self-advance authority and optional service paths

The protocol MUST preserve a wallet self-advance path where a wallet can produce a valid confidential transition using local proving and direct BCH broadcast.

Optional services (including service-assisted proving or aggregation producers) MAY be used for convenience, privacy amplification, or cost optimization, but they MUST remain non-authoritative.

A service provider MUST NOT become part of the protocol trust model for:

  • transition validity
  • spendability correctness
  • consensus acceptance authority

Wallets using optional services SHOULD retain a direct local path or local verification fallback so service unavailability cannot block baseline protocol operation.

19. Candidate discovery interface

This protocol separates discovery from tracking.

19.1 Discovery

Discovery is the process of finding newly created notes that may belong to the wallet.

The protocol allows candidate discovery from:

  • direct chain scanning
  • block filter assisted scanning
  • optional index server results
  • public pubkey indexers or equivalent public candidate feeds

19.2 Tracking

Tracking is the process of following already discovered notes and relevant protocol state.

Once a wallet has discovered a note, it SHOULD persist enough information to follow:

  • note status
  • state cell lineage
  • relevant roots
  • spent or nullified status
  • reorg updates

20. Optional index server

20.1 Purpose

An index server MAY accelerate discovery by indexing only public protocol structure.

This includes:

  • protocol candidate transactions
  • public envelope bytes
  • transition input locations
  • protocol state cell outputs
  • block heights and txids
  • public sender or ephemeral pubkeys if a discovery mode requires them

20.2 Trust limit

An index server MUST NOT be part of the trust model for:

  • ownership determination
  • note decryption
  • state validity
  • spendability

The wallet MUST perform those locally.

An index server MAY return, for a height range:

  • txid
  • height
  • vin
  • protocol_outpoint
  • rre_version
  • tx_ephemeral_pubkey_R
  • recipient_note_count
  • envelope_offset
  • envelope_length

It MAY also return the raw public RRE1_SECTION.

20.4 Example dedicated schema

{
  "from": 943370,
  "to": 943372,
  "count": 12,
  "candidates": [
    {
      "txid": "3a1b2d74d9c0eaee02d612599fdb55cd9461b77c9535759c853a3d75c2da2c84",
      "height": 943370,
      "vin": 0,
      "protocolOutpoint": "53ab76211ac3b7c461aec1f9cafc0f0c5147059a82d2271f1eff545f222981dd00000000",
      "rreVersion": 1,
      "ephemeralPubkey": "02c72ca3449d847bc75133d9b29461237d12fb90c1adbf91a92ca6331a50b6d07d",
      "noteCount": 2,
      "envelopeOffset": 412,
      "envelopeLength": 290
    }
  ]
}

21. Wallet note record schema

A wallet SHOULD persist recovered notes in a deterministic record format.

Proposed v1 layout:

WALLET_NOTE_RECORD_V1
- txid
- block_height
- protocol_state_outpoint
- rre_version
- recipient_note_index
- owner_pubkey_P_i
- note_commitment_cm_i
- one_time_spend_privkey_x_i
- asset_id
- amount
- note_blind
- nullifier_seed
- memo
- state_root_hint
- spend_status
- discovery_source

21.1 Minimum persistence objective

The stored record MUST contain enough information to:

  • revalidate ownership after restart
  • construct future spends
  • detect spent or nullified state
  • survive chain reorganization replay

22. Local metadata

discovery_source MAY record:

  • mempool
  • block
  • filter
  • indexer

This field is local metadata only. It is not a protocol field.

23. Persistence and recovery expectations

A protocol compatible wallet SHOULD persist enough data to recover protocol state without depending on any external service. At minimum, wallets SHOULD retain:

  • wallet note records
  • relevant protocol outpoints
  • note status
  • the latest validated roots needed for spend preparation
  • reorg handling metadata

Deleting accelerators or local caches MUST NOT change the result of ownership or validity checks once the wallet replays chain data and its keys.

24. Reorg and confirmation handling

Wallets MUST handle:

  • unconfirmed candidate notes from mempool
  • confirmation when the transaction is mined
  • invalidation on mempool eviction or conflict
  • block disconnection during reorg
  • replay of discovery and tracking after reorg

A wallet SHOULD distinguish:

  • pending inbound notes
  • confirmed inbound notes
  • invalidated notes

25. Privacy properties

If implemented correctly, v1 provides:

  • no public recipient id
  • no reusable public recipient marker
  • receiver recognition only by holders of the scan key
  • local decryption only after ownership match
  • optional index server acceleration without server side ownership visibility, as long as the wallet does not reveal ownership matches back to the server

26. Security considerations

26.1 Decryption is not enough

A wallet MUST NOT treat successful decryption alone as ownership confirmation.

It MUST also verify:

  • cm_i recomputation
  • consistency with the observed state transition
  • consistency with the protocol state cell identified by the transaction

26.2 Fresh ephemeral key requirement

The sender MUST use a fresh transaction ephemeral key R per transaction.

26.3 No server trusted for wallet truth

An index server MUST be treated as a cache or search layer, not a wallet authority.

26.4 Key separation

Scan key and spend key SHOULD remain distinct.

26.5 Domain separation across wallet modes

Wallets SHOULD avoid using the same receiver identity for:

  • transparent BCH activity
  • paycode identity distribution
  • confidential protocol note recovery

This recommendation is about wallet privacy hygiene, not about consensus validity.

For the first working prototype, the protocol SHOULD keep bounds small:

  • recipient_note_count <= 2
  • one external recipient note
  • one sender change note
  • one transaction level ephemeral pubkey
  • deterministic RRE1_SECTION placement
  • block based confirmed sync as the default wallet policy
  • optional mempool watch for fast inbound detection

These are implementation bounds, not permanent protocol limits.

28. Open items still to freeze

The following items still require separate freezing if not already settled elsewhere:

  • exact token-aware output_fingerprint_m2 successor hash policy for confidential transitions
  • exact paycode or RPA mapping to (A, B)
  • exact RRE1_SECTION byte serialization inside unlocking bytecode
  • exact state cell encoding for note root and nullifier root
  • exact fee and batch digest handling for confidential transitions
  • exact envelope size limits and recipient count limits

The best order to freeze this protocol is:

  1. output fingerprint policy
  2. note commitment policy
  3. RRE1 byte encoding
  4. wallet note record schema
  5. wallet discovery and tracking rules
  6. protocol entry, transition, and exit transaction layouts
  7. proof statement boundary for future prover work
  8. verifier ABI and host/kernel split for the selected backend

30. Compact short form

A concise summary of v1 is:

BCH Confidentiality Protocol v1 uses covenant controlled protocol state cells, a public state transition boundary carried through PIV0, and a receiver recovery envelope RRE1 placed inside confidential transition transactions. Receivers discover inbound notes by deriving a transaction level shared secret from an ephemeral pubkey, comparing derived one time owner keys to public owner keys, decrypting only matching note payloads, and validating recovered notes against public commitments inserted into the next protocol state. Wallets may use full local scanning, thin block filtered scanning, or optional index accelerated candidate discovery, but all ownership and validity decisions remain local to the wallet.

31. Why this fits BCH 2026

This protocol shape is practical on BCH because the 2026 path:

  • makes P2S outputs standard
  • raises standard unlocking bytecode length to 10,000 bytes
  • raises token commitment length to 128 bytes
  • adds loops for bounded repeated covenant procedures
  • adds reusable functions for more compact and auditable complex contract logic

These assumptions improve practicality and ergonomics for covenant heavy confidential transactions, but they do not change the trust model of the protocol itself.

32. Final stealth proposal

For this draft, the final proposal is:

  • freeze the protocol around the scan/spend receiver identity model (A, B)
  • explicitly define the protocol as stealth compatible at the ownership layer
  • keep derivation paths optional and non normative
  • recommend the BIP352-style derivation layout for wallet interoperability
  • keep RPA or paycode formats as optional identity distribution layers
  • preserve wallet level domain separation between transparent, paycode, and confidential usage

This preserves compatibility with stealth address design patterns without collapsing confidential notes into ordinary visible UTXOs.

33. Implementation guidance

A codebase is aligned with this draft if:

  • it models receiver identity as scan plus spend keys
  • sender and receiver derive matching one time owner keys
  • wallet recovery depends on chain data plus wallet keys
  • derivation path choices are treated as wallet policy, not protocol validity
  • confidential transition outputs use fixed carrier sats and tokenized state cells
  • the final backend path is designed so host checks and proof checks remain distinct
  • the selected proving backend is evaluated verifier-first rather than prover-convenience-first

A codebase is not required to use a specific BIP32 path to remain protocol compatible.

34. References

  • PIV0 public input boundary definition in the surrounding protocol spec set
  • CHIP-2024-12 P2S: Pay to Script
  • CHIP-2021-05 Loops: Bounded Looping Operations
  • CHIP-2025-05 Functions: Function Definition and Invocation Operations
  • BIP47 Reusable Payment Codes for Hierarchical Deterministic Wallets
  • BIP352 Silent Payments