Skip to main content
TIP (Transfer Identity Protocol) manages transfer identities and their route information. A TIN (Transfer Identity Number) is one 10-digit identity within TIP. A TIN gives a sender a recipient identifier to resolve before authorizing a transfer; it is not a wallet key, token account, or balance container.

​
Identity and wallet recovery

The TIP registry keeps identity information encrypted. The owner’s recovery record is stored in a separate on-chain PDA owned by the TIN Registrar program, not inside the main TIN registry account. That recovery record contains the owner’s public key and an encrypted TIN recovery envelope. When the owner reconnects the wallet, the SDK derives the recovery PDA, fetches the envelope, and decrypts it locally. This separation means the main registry does not need a standalone owner-public-key field to support wallet recovery. The current native-credit ABI does not encode a plaintext recipient TIN or private predecessor pointer. It uses shared TIP/TCAP roots, and the owner retains private record lineage. Public action fields, encrypted Memo bytes, accounts, signatures, ordering and funding wallets remain observable. That encoding boundary does not establish that metadata or authorized service/application knowledge cannot correlate payments. The complete hidden-head flow and confidential debit/exit remain separate unverified runtime capabilities; see the security boundary.

​
Resolving a recipient

An application can use the TSN SDK to resolve the TIN’s owner-provided display name and prepare a payment authorization. The display name is a recipient confirmation aid; it is not legal identity verification. The sending wallet still reviews and signs the payment authorization. The hidden-head proof flow that is intended to use TIP route information is not established as an end-to-end settlement capability. See the SDK identity guide for application-level usage. Issuer operations and the registry’s exact data contract belong in the repository documentation.