Skip to main content
TSN separates identity, authorization, private-state verification, and asset settlement. These principles describe the intended trust boundaries; availability of a feature still depends on its verified end-to-end implementation.

​
Core boundaries

  • The owner authorizes wallet actions. A service or Cranker cannot change the sender’s signed payment terms.
  • GPRU guards private state. Its proof is intended to show that the hidden user state is current and that the proposed transition follows from it.
  • TCAP governs funds. It checks accepted assets, authorization, and liquidity, then applies valid changes atomically.
  • A confirmed transaction is the settlement evidence. Request acceptance, service verification, and transaction submission are earlier stages.

​
Limits

The hidden-head proof path is not established end to end. Confidential debit and exit are not established as available. 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 roots and timing do not create that pointer. Direct wallet transfers expose their endpoints. A TIN-to-wallet exit exposes the destination and amount, but not the source TIN; later activity from the output wallet remains public. This design is not a verified runtime guarantee until the proof flow is operational and validated. Do not infer that a capability is active from a helper, diagram, or program instruction alone. Check the target network and verify the transaction and resulting state. Detailed source-level checks and evidence requirements are maintained in the repository documentation.