Skip to main content
TSN separates the identity used to address a transfer from the private state used to validate a balance change and the assets governed by settlement. This separation gives each protocol layer a distinct responsibility. As hybrid infrastructure for the Internet of Value, TSN coordinates identity, requests, and verification through off-chain services, then relies on on-chain programs to enforce authorization and settlement rules. The architecture is designed for interoperable value transfer across applications and blockchain networks; each route’s live status depends on its deployment and verification evidence.

​
Responsibility boundaries

  • TIP manages transfer identities. A TIN is one 10-digit identity managed by TIP; it is not a wallet key or a store of funds.
  • GPRU guards the user’s private state as it is presented to TCAP. Its proof is intended to show that the hidden state is current and that the proposed transition follows from it.
  • TCAP governs accepted assets, reserve liquidity, and the balance-changing action. It applies an authorized transition atomically.
  • TSNP enforces its on-chain authorization and settlement rules. TSN names the complete infrastructure, including the protocol layers and supporting services.
The proof does not grant custody or payment authority to GPRU. Settlement requires the applicable authorization and TCAP checks as well as a valid proof.

​
Privacy boundary

For a TIN-to-TIN transfer, the public chain records the settlement but does not identify the sender’s or recipient’s TIN, name either owner, or publish a pointer from the sender’s funding transaction to the recipient’s settlement. Each accepted TIN balance change is an independent opaque record: no stable per-TIN public reference links it to earlier or later settlements. The owner retains the private history needed to reconstruct that lineage. TSNP/TCAP verify the proof and apply the valid transition without learning the hidden TIN link. The sender sees their own funding signature and receives the settlement result through TSN; the signature does not reveal which on-chain record belongs to the recipient. TIP’s route root and TCAP’s commitment root are shared protocol accounts, not per-TIN identifiers, and timing does not create a recipient pointer. Solana still exposes transaction accounts, signatures, instruction data, timing, and ordering. Those fields do not reveal the TIN-to-TIN identity mapping. Direct wallet-to-wallet transfers expose their endpoints. A TIN debit to wallet exit exposes the output wallet and amount, but not the source TIN; observers can follow that output wallet’s later activity. The hidden-head proof flow is not currently established as an end-to-end settlement capability. This page describes the protocol’s intended privacy boundary separately from implementation readiness; it does not claim every layer is deployed or operational. Source-level design and deployment evidence are maintained in the repository documentation.