TIN: Identity and Privacy-Receiving Roots for TSN

TSN architecture · TIN identity

A TIN is a portable payment identity. It helps a sender address a recipient without treating an everyday wallet address as the human-facing identifier. The live route is TIN → privacy-receiving root → GPRU → TSN → TCAP.

What a TIN is

A Transfer Identity Number is a payment identity and route-discovery handle. It is not a private key, seed phrase, token account, confidential balance or permission for infrastructure to spend funds.

• The owner wallet authorizes the TIN relationship.
• The privacy-receiving root anchors the private receiving relationship.
• GPRU supplies scoped authorization and routing only; it never holds funds.
• TCAP stores the public tip transition while the owner keeps the encrypted balance snapshot.

Live payment path

1. The sender resolves the recipient TIN through the permitted identity service.
2. The SDK binds the privacy-receiving root relationship into the signed intent and GPRU scope.
3. The Receiver stores redacted work and the TSN Node verifies signatures, policy, commitments, sequence and expiry.
4. Mother and TSN authorize the ConfidentialSettlement transition for the Epoch Treasury and TCAP.
5. TCAP consumes the authorization receipt and nullifier, advances the tip, and binds the new commitment.
6. The owner device fetches and decrypts the matching encrypted snapshot for a private balance read.

Privacy boundary

Public state carries only the commitments, sequence values, token identifiers, policy references, nullifiers and validity data required for verification. Plaintext roots, master seeds, snapshot keys and private balances remain on the authorized device.

Receiver, Node and Cranker services receive redacted coordination data. A Cranker submits the exact authorized transaction and cannot replace the amount, recipient binding, commitment, sequence, policy, token or nullifier.

What TIN does not do

• A TIN does not hold tokens or replace Solana accounts in the final transaction.
• A TIN does not make GPRU custodial.
• A TIN does not expose a plaintext root or private snapshot.
• A TIN does not enable confidential debit or exit; those interfaces remain proof-gated.

Architecture history

ZK-PRU was an earlier receiving and spending experiment. It was superseded by the privacy-receiving-root, GPRU and TCAP model. Implementers must target the current route and must not use ZK-PRU as a live receiving, balance or spending architecture. Read the ZK-PRU retirement note for the audit history.

Developer integration boundary

Resolve the TIN, build the TSN plan, request owner authorization, and submit the immutable signed plan. A resolved identity is not permission to construct an arbitrary transaction.

Read GPRU authorization and routing → · Read the TCAP private balance layer → · Read TSN updates →