TSN Privacy and Security Boundaries

What TSN is designed to protect, what each participant can do, and what remains visible on public chains.

TSN separates user authorization, service verification, private-state protection, and settlement authority. The sender’s wallet authorizes the requested payment. TSN services verify and route work. GPRU is designed to guard the integrity and privacy of the private state presented to TCAP. TCAP governs accepted assets, liquidity, and atomic settlement.

Participant boundaries

Participant	Role	Boundary
Sender wallet	Reviews and authorizes the payment.	A service or Cranker cannot replace the sender’s approval.
TSN services	Coordinate and verify payment work.	Service acceptance or verification is not on-chain settlement.
Cranker	Submits authorized work and pays transaction fees.	Submission does not prove confirmation or give authority to alter payment terms.
GPRU	Guards the user’s private state presented to TCAP.	A proof does not hold funds or replace TCAP checks.
TCAP	Governs accepted assets and applies authorized settlement.	The transition must satisfy the applicable asset, authorization, and liquidity rules.

Identity privacy and public-chain visibility

The native-credit ABI hides the recipient route/head witness and does not encode a plaintext TIN or private predecessor pointer. The owner retains its record lineage. Shared roots, public statement fields, encrypted Memo bytes, accounts, timing and funding wallets remain observable; the design does not establish that metadata or authorized Node/application knowledge cannot correlate payments. Confidential debit/exit remains a separate unverified execution path.

The current Node derives the published credit nullifier from the public deposit signature and TCAP program ID using a domain-separated SHA-256 hash reduced to a BN254 scalar. An observer can recompute the funding-to-credit relationship without a secret. This protects the deposit replay context but limits transaction privacy; it does not reveal the hidden TIN witness by itself. Node also handles private routing/witness preparation, so owner-only knowledge is not established.

Capability status

The hidden-head proof flow is not established as an end-to-end settlement capability, and confidential debit and exit are not established as available. A source-level design or accepted service request is not proof of settlement; rely on the confirmed chain transaction and resulting state.

The detailed adversary assumptions and implementation evidence are in the repository security documentation.