Identity-first, privacy-conscious, and confidential crypto payments powered by the Transfer Settlement Network (TSN) on Solana.
TrustLink Pay is a Solana payment system that enables users and applications to send stablecoins using 10-digit Transfer Identity Number (TIN) instead of wallet addresses.
The Transfer Settlement Network (TSN) is TrustLink Pay's settlement protocol designed to separate payment authorization, settlement execution, and recipient payout through verifiable settlement flows.
See what people are saying about the project: Community Mentions.
The project is built from one practical belief:
Blockchain payments should feel familiar for normal users while still giving developers verifiable settlement and better privacy design.
TrustLink Pay combines four protocol layers:
-
Transfer Identity Layer
- Transfer Identity System: gives each user a portable payment identity with a 10-digit TIN inside it.
- Social verification: WhatsApp and WhatsApp Business confidence signals for communication, authentication, and recipient checks.
- SAS: Solana Attestation Service support for verified names, merchants, and compliance attestations when those credentials are present.
-
Privacy Layer
- PRUs: Privacy Receiving Units. Every Transfer Identity has 30 PRUs by default.
- TIN balance: the unified balance across PRUs owned by a Transfer Identity.
- PRU-first spending: TrustLink Pay spends from PRUs first, then uses connected wallet top-up when the user chooses a mixed funding path.
- VPP-ready privacy assets: VPP is the privacy-asset layer planned for vAssets; PRUs are the current receiving and routing mechanism.
-
Settlement Layer
- TSN: Transfer Settlement Network. Separates sender funding from recipient payout.
- Crankers: Settlement operators that validate work, execute payouts, compete for recovery jobs, and keep the network live.
-
Liquidity And Accounting Layer
- Vaults: settlement liquidity used for recipient payouts.
- Epoch reservoirs: isolated settlement windows for reimbursement, recovery, and auditability.
The goal is simple: payments should feel as familiar as sending to a bank account number, while settlement remains verifiable and avoids exposing a clean sender-wallet-to-recipient-wallet graph.
Most crypto payments still start with a wallet address.
That creates problems:
- Wallet addresses are hard for normal users to verify.
- A direct wallet-to-wallet payment can expose a simple public payment graph.
- Merchants and creators often have to expose treasury wallets to receive funds.
- Apps rebuild payment, identity, and settlement logic from scratch.
TrustLink Pay changes the surface:
| Traditional crypto payment | TrustLink Pay |
|---|---|
| Share a wallet address | Share a 10-digit TIN |
| Sender pays directly to recipient wallet | Sender funds a TSN settlement path |
| Recipient wallet is the payment identity | TIN is the payment identity |
| Identity confidence is weak | Social verification and SAS attestations improve confidence when present |
| Apps rebuild payment flows | Apps can integrate Transfer Identity, PRUs, and TSN through SDKs |
Sender enters a recipient TIN. The Transfer Identity layer resolves the public identity context. Social verification or SAS status is shown when available. The sender reviews the recipient details and authorizes the payment. TSN receives the sender-side funding intent, Crankers validate and execute settlement work, and the recipient is paid into a PRU route rather than a public owner wallet.
The sender sees a normal payment experience. The protocol handles route authentication, PRU selection, settlement proofs, Cranker work, and recovery behind the scenes.
The Transfer Identity System is the identity layer.
A TIN is the 10-digit number inside a Transfer Identity. It works like a portable payment identity and lets a user receive payments without exposing a wallet address as their public identity.
Transfer Identity supports:
- 10-digit payment identities
- public display context
- encrypted social identity links
- wallet abstraction
- developer-accessible identity resolution
- PRU route commitments for private receiving and TIN balance
Wallets, payment apps, merchant tools, and on-chain products can use Transfer Identity as the top layer for safer payment identity.
PRU means Privacy Receiving Unit.
Every upgraded Transfer Identity has 30 PRUs by default. PRUs are token-agnostic receiving and spending endpoints controlled by the Transfer Identity owner through TSN intent proofs. When someone receives through TrustLink Pay, funds land in PRU routes instead of a public owner wallet. The frontend can load public PRU addresses only after the owner proves control through a signed route-auth message. It never receives PRU private keys or the TIN Master Seed.
TIN balance is the sum of supported token balances across the PRUs linked to the authenticated Transfer Identity. In the send flow, TrustLink Pay shows wallet balance and TIN balance as one usable payment balance, while still showing the split when a payment needs PRU funds plus connected-wallet top-up.
TrustLink Pay started with phone-number and WhatsApp confidence because this is how many users already understand payment trust.
Social verification includes:
- WhatsApp session-code authentication
- WhatsApp notification flows
- WhatsApp Business profile confidence where public business data is available
- encrypted TIN Master Seed and social identity storage
- recipient preview before payment
Phone numbers should help with confidence, not become the main public payment identity. The public payment identity is the TIN.
SAS means Solana Attestation Service.
SAS lets trusted issuers attach reusable verification credentials to a Transfer Identity.
Examples:
- verified legal name
- merchant verification
- business verification
- government or KYC verification
- proof-of-personhood
- risk or compliance attestations
The sender should see enough verified information to trust the recipient, without exposing sensitive documents or private identity data.
TSN is the Transfer Settlement Network.
Identity alone does not create privacy. If a TIN simply resolves to a wallet and the sender pays that wallet directly, the payment graph is still public.
TSN separates settlement into stages:
- sender authorization
- PRU or wallet funding
- Cranker validation
- PRU recipient payout
- settlement proof
- epoch accounting
- recovery and reimbursement
This separation helps TrustLink Pay reduce direct sender-to-recipient graph exposure while keeping settlement verifiable.
Crankers are settlement operators.
They monitor work, validate payment structure, execute payout work, submit proofs, and compete for recovery jobs. Crankers are part of the protocol's liveness and safety model.
Vaults provide liquidity for fast recipient payouts.
Epoch reservoirs, also called PEAs, isolate settlement accounting by time window. This makes reimbursement, recovery, and auditing easier to reason about.
TrustLink Pay does not claim that Solana becomes private.
Solana transactions and program accounts are public. The goal is narrower and practical:
- do not make wallet addresses the normal payment identity
- do not expose phone numbers or social identifiers in clear text
- do not publish a simple sender-wallet-to-recipient-wallet payment path
- use commitments, vaults, and separated settlement steps instead of one obvious direct transfer graph
This is privacy-conscious settlement design, not impossible privacy marketing.
TrustLink Pay started from a product question:
Why should normal users need wallet addresses to send and receive crypto payments?
The early direction used phone-number and WhatsApp confidence because it made payments feel familiar. That helped prove the user experience.
But the research also showed a deeper protocol problem:
- phone numbers are useful for communication, but should not be the permanent public payment identity
- TINs are better as portable payment identities
- SAS is needed for reusable verified-name and trust context
- TSN is needed because identity resolution alone does not protect the payment graph
- Crankers and vaults are needed for separated settlement and fast payouts
- epoch reservoirs are needed for safer accounting and recovery
That journey moved TrustLink Pay from an app idea into payment identity and settlement infrastructure.
- Transfer Identity devnet registry
- 10-digit TIN resolution
- upgraded TIN account layout with owner hash commitment
- authenticated PRU route loading
- 30-PRU Transfer Identity route model
- TIN balance display from PRU balances
- PRU-funded payments
- mixed PRU plus wallet top-up payments
- recipient payout into PRU routes
- TrustLink Pay frontend and backend
- WhatsApp session-code authentication
- TSN mempool
- Cranker settlement daemon
- escrow funding and vault payout flow
- commitment-based settlement direction
StableHacks 2026 - Track: Programmable Stablecoin Payments.
This milestone proved the first end-to-end identity payment path:
- recipient identity preview before payment
- escrow-backed Solana payments
- gasless UX direction
- WhatsApp-based confidence layer
- hardened escrow architecture
- fraud-protection direction
The Bags Hackathon - Track: Payments.
This milestone extended the TrustLink payment model toward identity-first SPL asset transfers and wallet-address-free recipient experiences.
Transfer Identity became the protocol answer to portable payment identity.
Instead of making a phone number the main payment identity, TrustLink Pay moved toward a 10-digit TIN that wallets and apps can integrate.
TSN became the protocol answer to privacy-conscious settlement.
TSN settlement includes:
- Cranker-sponsored escrow submission
- PRU recipient payout
- proof records
- mempool-first settlement work
- commitment-only settlement records
- epoch-aware accounting
- PEA reservoir design
TrustLink Pay is being built independently on Solana by a team focused on researching and improving blockchain payment experience.
The project has received support through the Superteam Agentic Engineering Grant program, approved for 200 USDG to accelerate fraud-protection system development.
Grateful to @SuperteamEarn and the @SuperteamNG community.
Special thanks to @NzubeEzudo and @Harri_Obi.
TrustLink Pay needs supporters, sponsors, reviewers, and ecosystem partners to move from devnet validation into stronger production-grade infrastructure.
| Program | Devnet ID |
|---|---|
| Transfer Identity | TinseNnU588NkmRZBe4ADJbxqrqQma92678UFP6VuwT |
| TSN | TSN31jddtsmUg4D5aEdhY31nwB1e53VJJg9X8NoRP8V |
TrustLink Pay deploys are pinned to the Solana/SBF 1.18.x builder line and Anchor 0.30.1.
Run this before deploying either program:
npm run deploy:lockfiles:stabilize
npm run deploy:doctorThe lockfiles intentionally avoid newer crate releases that require Rust edition 2024. This prevents the Solana/SBF 1.18 builder from failing before deployment.
Set one shared RPC entry point for the repo with TSN_SOLANA_RPC_URLS.
The frontend receives that value automatically at build time, so you only set the shared app-facing env once.
The gateway process reads TSN_SOLANA_RPC_URLS to route traffic across Solana RPC providers. Confirm the active selection with npm run rpc:inspect and npm run rpc:gateway:inspect.
| Path | Purpose |
|---|---|
frontend/ |
TrustLink Pay user interface |
backend/ |
API, payment records, identity records, and notifications |
docs/ |
Product and protocol documentation |
tin-system/tins-registrar/ |
Transfer Identity on-chain program |
tin-system/tins-sdk/ |
Transfer Identity SDK |
tsn/protocol/ |
TSN on-chain program |
tsn-sdk/ |
TSN SDK |
tsn-cranker-op-daemon/ |
Reference Cranker daemon |
tsn-cranker-sdk/ |
Cranker SDK and CLI helpers |
tsn-mempool-backend/ |
Mempool, epoch coordination, and challenge APIs |
tsn-mempool-frontend/ |
Mempool and epoch explorer |
tsn-rpc-gateway/ |
Standalone Solana RPC gateway project and shared RPC client |
- Documentation index
- Start Here
- Architecture
- Transfer Identity
- TSN commitment settlement
- RPC gateway
- Cranker guide
- Liquidity
- Security
- Deployment
TrustLink Pay is pre-launch and focused on devnet testing.
TrustLink Pay - Transfer Identity payments with PRU-routed balances, social confidence, SAS-ready attestations, and TSN settlement.