Selective disclosure
Keep public observation separate from intentional accountability.
Protocol behavior is proposed. This release is an interface preview; no funds or wallet signatures are accepted.
Viewing access
The design separates a party’s ability to inspect private activity from its ability to authorize a spend. A user can intentionally disclose viewing material to an accountant, institution, or other reviewer without publishing it to every observer.
A disclosed key can expose more than a single transaction. The UI must explain scope, historical reach, and whether future activity becomes visible. Revoking service access cannot erase information a recipient has already copied.
Deposit screening
A guard screens pending deposits before admission to shielded state. A decision can approve entry, request additional review, or reject the deposit according to contract-defined refund rules.
Admission control and asset ownership are separate powers. The guard should not possess unilateral spending authority, but it can still affect availability and access. Its policy and operational role require disclosure.
Post-admission revocation
The proposed revocation mechanism associates approved deposits with revocation material. If a deposit is later flagged, publication of the relevant secret would enable other users to prove their notes are not funded by that deposit.
This is a provenance-proof design objective, not a claim of automatic compliance or a currently implemented Jammer feature. Recursive proof construction, revocation propagation, privacy leakage, and false-positive handling all require specification and review.