Happy-path scenarios

Happy paths prove that the supported Confidential Token workflow succeeds and that every effect is what the protocol rules say it must be — never just “the transaction did not error.”

Flows catalog

The flows crate builds the happy-path catalog (CT-HAPPY-*, pack happy-path), six registered scenarios: register, deposit, merge, transfer, withdraw, and the full register→deposit→merge→transfer→withdraw lifecycle. They are plain Scenarios and run through the same harness and report gate as every other pack.

What every happy path asserts

Beyond “the operation was accepted,” each flow asserts:

• the expected public event was emitted (ct_register, ct_deposit, …),
• balances moved by the independently computed amount — the scenario computes expected balances from the declared inputs and fixture starting state, never by asking the simulator what happened,
• ownership moved to the correct owner where the protocol defines it,
• proofs generated for a transfer verify against the transfer’s statement before the transfer executes,
• the full-lifecycle scenario additionally runs with every built-in invariant attached (conservation, ownership, commitment consistency, proof binding, input binding, replay protection, privacy) — a lifecycle that passes its own assertions but violates conservation is a failure.

Anti-circular testing

Expected values are derived from declared inputs and fixture starting state (e.g. deposit 40 on a fixture balance of 100 ⇒ 140), not from the simulator’s own reported results. The pack tests require each scenario to pass with all invariants, so the happy path is checked from two independent directions.