How TSN Approaches Privacy on Solana
Transfer Settlement Network (TSN) approaches payment privacy at a different layer from most privacy systems on Solana. Instead of treating privacy only as the cryptographic hiding of an amount or the unlinking of a deposit from a withdrawal, the TrustLink Labs model begins with payment identity, wallet abstraction, protected routing, authorization, and settlement coordination.
This does not make TSN a replacement for zero-knowledge pools, confidential tokens, or private wallets. These systems protect different parts of a transaction. TSN is designed to coordinate them within a usable payment workflow.
The privacy landscape on Solana
Privacy is not a single feature. A system may protect the user-facing identity, wallet relationship, counterparty graph, transferred amount, balance, application state, or some combination of them.
| Category | Example | Primary mechanism | What it is designed to protect |
|---|---|---|---|
| Identity-first settlement coordination | TrustLink Labs: TIP, TIN and TSN | Payment-identity abstraction, owner commitments, protected PRU routing, signed intents and separated settlement execution | The relationship between a human-friendly payment identity, its owner wallet, protected receiving routes and the settlement workflow |
| Shielded or unlinkable transfers | Privacy-pool systems | Commitments, Merkle trees and zero-knowledge proofs used to weaken the public link between deposits and withdrawals | The transaction graph between entry and exit points, subject to the protocol's anonymity set and threat model |
| Private wallet and application layer | Umbra | Encrypted balances, anonymous transfers, shared-state privacy and selective viewing capabilities | Balances, transfer activity and the public connection between wallet operations |
| Confidential token state | Solana Token Extensions: Confidential Transfer | ElGamal encryption and zero-knowledge proofs within confidential-transfer token accounts | Transfer amounts and token balances; token-account addresses remain public |
| Compressed state infrastructure | Light Protocol | ZK Compression for scalable Solana state | Application scale and state cost; this should not be described as equivalent to a consumer privacy pool |
Identity abstraction is not the same as anonymity
A conventional shielded-pool design primarily attempts to break an observable on-chain link. A user deposits into shared state and later proves the right to withdraw without publicly revealing which deposit funded that withdrawal.
TSN starts from a different payment question: how can someone receive value through a stable, human-usable identity without making a primary wallet address the public identity of that person?
The public identifier in the TrustLink model is the 10-digit TIN—Transfer Identity Number. It is not a Tax Identification Number, and it is not legal-identity proof by itself. The TIN account stores a one-way commitment to the owner wallet public key. Control is proven through the required wallet authorization against that commitment.
A phone number, WhatsApp account, email address or similar social identifier may support discovery, communication or an authorized resolution flow. It is not the underlying blockchain identity, it is not published as a readable owner field, and it does not independently prove ownership of a TIN.
Protected routes instead of a single public destination
The TrustLink architecture derives 30 Privacy Receiving Units (PRUs) for a Transfer Identity. The public TIN registry stores only a SHA-256 commitment to the complete PRU address set. The plaintext route list is protected metadata made available through authenticated TSN route access; PRU private keys and operational history are not readable TIN-account fields.
This creates path separation between the identity a payer selects and the destination mechanics used by settlement. It is designed to reduce the direct exposure created when one permanent wallet address becomes a person's payment name.
Path isolation must not be confused with a blanket promise of anonymity. Its privacy properties depend on route selection, timing, amount correlation, RPC and indexer visibility, settlement behavior, client security, and the adversary being considered. Strong claims require a published threat model, implementation review and empirical analysis.
Settlement coordination rather than mixer execution
TSN separates payment creation from payment execution. A payer creates a signed payment intent. The network can evaluate authorization, policy, quotas and required disclosure before eligible intents are advanced by a worker layer commonly described as Crankers.
This architecture is intended to coordinate identity resolution, authorization, execution, finality and receipts as parts of one payment lifecycle. A privacy pool focuses on unlinkability inside its pool. A confidential token extension focuses on encrypted amounts and balances. TSN focuses on connecting payment identity to an authorized settlement path while limiting unnecessary exposure.
How WhatsApp fits into the system
TrustLink Pay can use WhatsApp infrastructure for handoff links, user communication, opt-in notifications, OTP delivery and confirmation flows. This can make a blockchain payment experience feel closer to familiar mobile-payment products.
WhatsApp is deliberately outside the cryptographic ownership boundary. A WhatsApp profile name is not identity proof. A WhatsApp session does not derive PRUs, expose PRU keys, create a TIN by itself or authorize TSN settlement by itself. TIN control and payment authorization remain bound to the protocol's wallet-signature and intent rules.
Where TSN fits
The strongest way to understand TSN is not as “another mixer.” It is an identity-first settlement architecture that can coordinate multiple privacy techniques:
- TIP and TIN define payment identity, ownership and discovery.
- TSN coordinates signed intents, protected routes, workers, settlement and receipts.
- TCAP defines confidential asset state and confidential settlement paths.
- ZK-PRU explores programmable privacy, selective disclosure and policy-bound authorization proofs.
That layered model is the distinction. Solana privacy protocols can hide transaction links, balances, amounts or computation. TSN asks how those capabilities become a complete payment network that people can use through recognizable identities without turning their primary wallets into permanent public profiles.
Primary references
- Transfer Settlement Network knowledge base — canonical TrustLink Labs definitions for TIP, TIN, PRUs, TSN, TCAP and ZK-PRU.
- TrustLink Labs on GitHub — research and protocol repositories.
- Light Protocol — current ZK Compression positioning and developer infrastructure.
- Umbra documentation — encrypted balances, anonymous transfers and auditable privacy.
- Solana Confidential Transfer documentation — confidential amounts and balances with public token-account addresses.
Research note: This comparison describes architectural categories and documented design goals. It does not assert that every system offers identical production readiness, anonymity guarantees or security assumptions. Readers should assess each protocol's current documentation, audits and deployment status.