ADR 0005: Privacy is a venue, not a feature - Corridor

Context

A bolt-on privacy feature looks like if (shielded) callZcashService(): a second payment system with its own state, its own books and its own failure modes, reconciled with the first by hand.

Decision

Privacy is the zcash_ironwood venue in the one route graph. privacy: "shielded" is a constraint on the path (it must end in a shielded venue), not a separate subsystem.

Concept	Public lane	Shielded lane	Same code
Venue	`tempo`, `solana`, `partner_fiat`	`zcash_ironwood`	One enum
Route	Legs through the graph	Legs through the same graph	One planner
Saga	Forward and compensation per leg	Same	One engine
Ledger	Accounts by owner, corridor, asset, venue	Same, venue `zcash_ironwood`	One journal
Reference	TIP-20 memo, Solana memo	Zcash encrypted memo	One codec
Reconciliation	Chain logs and webhooks	Viewing-key scan	One matcher

Consequences

Shielded and public payouts share every guarantee: exactly-once booking, compensation, reconciliation.
Disclosure is built in: a viewing key per (customer, period).
The console shows shielded balances only to the customer and key holders.

Alternatives rejected

A separate privacy service: duplicated state and a reconciliation problem between systems.
A private L2 or mixer: weaker disclosure semantics and no per-period audit scoping.