Fixtures

Fixtures live in the fixtures crate as a synthetic, embedded, deterministic catalog — never real wallet material, never secrets. Every type in the catalog is constructed so no field can hold a private value.

Catalog

FixtureCatalog (crates/fixtures/src/catalog.rs) is the embedded default:

• Accounts — alice, bob, carol, issuer, admin, auditor, plus registerable accounts (e.g. dave). Each has a role, a registration flag, a frozen flag, and synthetic public metadata.
• Tokens — ct-usdc, ct-eurc, native.
• Balances — keyed by actor.token; the starting public ledger each scenario’s conservation invariant is checked against.
• Commitments — confidential-state fixtures with a digest and a status (live / spent / malformed).
• Transactions — prior transaction fixtures for replay and duplicate-content scenarios.
• Proofs — proof fixtures whose posture (valid / invalid / tampered / malformed) drives the prover double’s verification behavior, plus their pinned circuit version.
• Policies — frozen-account and authorization postures.

Why code-defined?

The spec (§69) requires fixtures to be deterministic, synthetic, versioned, documented, and reusable. Embedding them in the crate makes them:

• deterministic — no filesystem or environment dependence in tests,
• type-checked — a malformed fixture is a compile error, not a runtime surprise,
• the single source of truth — the JSON artifacts under fixtures/generated/ and test-vectors/generated/ are derived from the code-defined catalog by scripts/generate-*.sh, so external tooling consumes exactly what the tests use.

Adding a fixture

Extend the embedded catalog and add a test that asserts the shape. A new fixture must never carry a key, seed, witness, or confidential amount.

Fixtures vs. oracle

Fixtures define the starting state and the posture of test doubles. Expected outcomes are computed independently by scenarios from the declared inputs (balance arithmetic, ownership rules) — never by asking the surface under test what the answer is.