Skip to content

How One Transfer Works

What This Page Explains

This page walks through one confidential transfer end to end, from input state to receiver recovery.

Why It Matters

If a newcomer understands this one flow, they can place every deeper spec page in context.

Plain-Language Concept

A transfer consumes the current protocol continuation state, proves a valid confidential transition, publishes only the bounded public boundary, settles on BCH, and lets the receiver recover the next private state.

Technical Detail

End-To-End Sequence

flowchart TD
    S1[Input state cell and continuation output] --> T[Transition statement]
    T --> W[Hidden witness]
    T --> PI[Public Inputs version 1 (PIv1)]
    W --> P[Proof generation in runtime]
    PI --> P
    P --> PB[Proof Blob version 1 (PBv1)]
    PB --> TX[BCH transaction carrier]
    TX --> OUT[Next continuation output]
    TX --> R[Receiver discovery and recovery]

Step-By-Step

  1. Input state: sender wallet selects the authoritative continuation output and required state references.
  2. Hidden witness: wallet/runtime prepare private witness material (note secrets, transition witness fields).
  3. Public inputs: runtime constructs PIv1 bytes for verifier-facing public commitments.
  4. Proof blob: runtime emits PBv1 envelope bytes for transaction carriage and verifier acceptance.
  5. Transaction carrier: wallet assembles BCH transaction containing required protocol carrier fields.
  6. State transition: transaction confirms; next continuation output becomes the authoritative source for the next hop.
  7. Receiver recovery: receiver wallet scans, decrypts, validates, and tracks recovered state locally.

Prover, Verifier, Wallet Roles

  • Prover/runtime: proves bounded statement consistency for the current lane and outputs PIv1/PBv1 artifacts.
  • Verifier path: checks accepted boundary structure and bounded statement conditions for the published profile.
  • Wallet: orchestrates transaction assembly, host checks, persistence, discovery, and recovery.

Current Truth Boundary For This Flow

  • Current truth: first-hop and follow-on direct-spend flow are live-validated in bounded mode.
  • Proof-enforced semantics: bounded hidden transition semantics are enforced in the active lane.
  • Artifact-described behavior: evidence/reporting artifacts are descriptive outputs.
  • Public observables: BCH graph, fees, shell economics, and timing remain visible.
  • Future optional aggregation: later service-layer reduction of observability remains optional and deferred.

Code Mapping