Skip to content

Phase 3 Protocol Terminology (TKT-P3-23)

This file is the canonical glossary referenced by the Phase 3 protocol spec and downstream documentation. Use it whenever you need to describe the architecture, the wallet tracking model, or the code/comments in a protocol-first way.

Core protocol terms

  • Confidential covenant – the shared BCH locking script that enforces valid confidential transitions. It owns the protocol state cells (tokenized covenant UTXOs) and validates proofs produced by the backend/kernel.
  • Protocol state cell – each covenant-controlled UTXO that stores a canonical SCv2 commitment (note root, nullifier root, metadata). Phase 2 calls them “shards”; Phase 3 frames them as protocol state cells.
  • Protocol entry – spending an ordinary BCH UTXO into the confidential covenant so it becomes a state cell. Entry may re-use wallet-controlled keys (stealth, RPA/paycode), but the protocol cares only that the covenant receives valid funds.
  • Confidential transition – the backwards-compatible ZK proof-enabled spend that moves value from one or more state cells to their successors while updating SCv2 commitments, public inputs, and nullifier roots.
  • Protocol exit – spending a state cell back to a transparent or alternative covenant constraint such that the confidential state leaves the covenant.

Receiver identity and wallet tracking

  • Receiver identity (A, B) – the protocol-level ownership model that pairs a scan key (A) with a spend key (B) (the normalized (scanPriv32, spendPriv32) pair). All wallet note tracking derives from this tuple.
  • Wallet note – a deterministic record (decrypted payload + witness + metadata) that binds a (A, B) identity to a confirmed protocol state cell.
  • Inbound note discovery – the process of scanning transactions, deriving (A, B)-based shared secrets, decrypting payloads/hints, and validating note commitments before adding wallet notes.
  • Wallet note tracking – persisting wallet notes, spend/nullifier status, and change metadata so the wallet can continue building confidential transitions.

Supporting cryptographic policy

  • RRE1 – the canonical note commitment format (versioned WNEnc1/WNPay1 payload) that feeds noteRoot and nullifier calculations. Treat RRE1 as a protocol object, not a wallet UX detail.
  • One-time owner key – the ephemeral private key derived for each note (e.g., deriveRpaOneTimePrivReceiver) whose hash160 appears in the transaction output; note commitments and wallet notes index this key.
  • Note commitment – the leaf preimage inserted into noteRoot/nullifier computations; it ties decrypted amounts, randomness, and identity metadata together.
  • Nullifier – the canonical spend credential derived from a note; it ensures insert-only semantics in the nullifier set.

Protocol tooling and optional layers

  • Paycodes and RPA – optional identity distribution transports that deliver (A, B) receipts; the protocol treats them as metadata, not normative requirements.
  • Public candidate feed – an optional indexer (or JSON feed) that publishes candidate transactions for inbound note discovery; it behaves like an overlay service.
  • Optional index server – a recommender service that provides predictable txids/fees; it is not part of the covenant or wallet state, only a helper.
  • Stealth-compatible ownership – any wallet that holds (A, B) can prove ownership by deriving the shared secret for the same inputs; the term “stealth address” is a UX layer, not a protocol requirement.
  • Derivation paths – wallet-level policy for generating (A, B) pairs; the protocol does not treat them as normative rules. Document derivation guidance separately (e.g., in wallet docs) and reference it here if needed.

Consistency rules

  1. Use the glossary terms above in new spec sections, docs, and code comments. Reference this file whenever you need to explain terminology.
  2. When you must mention Phase 2 “pool” terminology (e.g., compatibility sections), label it as an implementation container or legacy artifact.
  3. Keep wallet-facing phrases confined to user-facing files and map them back to the protocol terms at the top of future PRs.