Skip to main content
A TSN transfer begins with an identity the recipient can share and ends with an on-chain settlement governed by TCAP. The sender reviews the resolved recipient and authorizes the payment; protocol services verify the request and prepare it for execution. This is TSN’s hybrid model: applications and protocol services coordinate the request off chain, while TSNP and TCAP enforce applicable authorization, asset, and settlement rules on chain. This model is intended to connect value transfer across the Internet of Value, while the status of each cross-network route remains specific to its verified deployment. GPRU protects the integrity and privacy of the user’s private state presented to TCAP: its proof is intended to show that the hidden state is current and that the proposed change follows from it. TCAP remains responsible for the funds and applies a valid authorized change atomically.

​
What confirmation means

An accepted request means the application delivered the intent. Verification means the protocol services accepted it for processing. A submitted transaction is not yet a confirmed transaction. Settlement is confirmed only when the relevant Solana transaction succeeds; for a flow with separate funding and credit transactions, each signature represents a separate stage. The hidden-head proof flow is not yet established end to end, and confidential debit and exit are not available as verified capabilities. Each TIN settlement is designed as a new opaque record without a public pointer from funding or its private predecessor; the owner retains the lineage, while TSNP/TCAP verify the proof without learning the hidden TIN link. Shared protocol roots and timing do not create that pointer. Wallet-to-wallet transfers expose their endpoints. A TIN debit to wallet exit exposes the output wallet and amount but not the source TIN. Use the SDK lifecycle guides to interpret status in an application, and the repository documentation for implementation and operator procedures.