Transfer Settlement Network

Executive Summary

Stablecoins solved an important problem: they made digital dollars and other fiat-linked assets move quickly across the internet. But moving value is not the same as running a payment system. In traditional finance, a completed payment usually depends on several hidden layers working together: identity, authorization, clearing, settlement rules, receipts, and audit trails. The Bank for International Settlements defines settlement as the discharge of an obligation, and a payment system as the instruments, procedures, rules, participants, and operator used to transfer funds. In other words, “money moved” is only one part of “payment completed.” ^[1,4]

Blockchains changed the mechanics of value transfer by allowing direct, programmable settlement on a shared ledger. But they also exposed a new weakness: wallet-to-wallet transfers are excellent for moving assets and often poor at expressing real payment relationships. Polygon’s private-payments launch with Hinkal is notable because it hides sender, receiver, and amount while keeping transfers verifiable and screened. Visa’s 2026 work with Brale on Canton shows that institutional stablecoin settlement now revolves around privacy and compliance, not just speed. Starknet’s STRK20 goes further by adding shielded balances, private transfers, and scoped disclosure paths to a public-chain environment. Academic work such as HFIPay shows that privacy-preserving payments to human-friendly identifiers are now an explicit research direction, not merely a product wish list. ^{[2,10,13,14,12,11,8]}

This article proposes a clear, layperson-friendly definition: a Transfer Settlement Network is a blockchain-native infrastructure layer that coordinates identity, authorization, settlement execution, confidentiality, and final ownership updates for digital value transfers. Under that definition, TSN is not just another “private transfer” feature. It is the missing payment layer between simple blockchain movement and real-world commerce.

Transfer, Settlement, and the Hidden Machinery of Payments

Most people think a payment is the moment money leaves one side and shows up on another. That is understandable, but payment systems are more layered than that. The BIS glossary defines settlement as “the discharge of an obligation in accordance with the terms of the underlying contract.” It separately defines a settlement system as an arrangement used to facilitate the settlement of transfers of funds or financial instruments, and a payment system as a set of instruments, procedures, and rules for the transfer of funds among participants. Those definitions matter because they show that a payment is not only an asset movement; it is also a rule-governed process that turns a promise into a completed obligation. ^[1]

The Federal Reserve makes a similar distinction in a 2023 note on wholesale payments. It describes the settlement asset as the “what” used to discharge obligations and the payment platform or transfer mechanism as the “how.” That is a powerful way to think about blockchain systems. A new platform can be very innovative even if the underlying asset remains a familiar dollar-issued instrument. Conversely, a new token alone does not automatically create a better payment system if the surrounding mechanism is weak. ^[3]

Traditional card systems reveal how much work sits behind the scenes. Visa defines authorization as the step where a transaction request is approved or declined by the issuer. It defines clearing as the later process, after authorization, where validation, financial assessment, and actual movement of the transaction are performed. Consumers rarely think in those terms. They just see “approved” and later get a receipt. But for the network, the sequence matters: first determine whether the payment is allowed, then process its financial consequences, then reconcile records across participants. ^[4]

ACH makes the same point in a different way. Nacha explains that a recurring utility payment might begin with a standing authorization from the customer, then move from the merchant as Originator to its bank as ODFI, to an ACH Operator, and finally to the customer’s bank as RDFI. The user’s experience feels simple, but the underlying system coordinates instructions, roles, timing, and settlement windows. Nacha also notes that the ACH network processes payments through scheduled settlement cycles rather than as a single universal real-time rail. ^[5]

Real-time gross settlement systems show the opposite end of the spectrum. The Federal Reserve explains that Fedwire is an RTGS system in which participants make final payments in central bank money, and that payment becomes final and irrevocable when the receiving participant is credited or notified. This is the gold-standard example of infrastructure whose core purpose is not social UX but certainty, finality, and risk control. ^[6]

Cross-border systems add another lesson: user-facing apps are only the visible surface. Visa’s paper on cross-border payments describes three layers, including a rules-and-processes layer and an infrastructure layer that supports messaging, clearing, and settlement. That framework explains why a sleek payment app can still fail to deliver a good payment experience if the back-end rails do not support the right kinds of authorization, finality, traceability, and cost structure. ^[7]

Put differently, traditional finance already knows something crypto builders sometimes forget: the payment is not the interface. The payment is the whole stack.

Why Blockchain Transfers Are Not Complete Payment Systems

Public blockchains made an extraordinary leap: they allow a shared ledger to record and verify asset transfers without requiring every participant to trust the same intermediary. That changed the economics of internet-native money. But blockchains did not magically solve everything that payment systems must do. The result is that many onchain applications are still better described as asset transfer tools than as fully developed payment systems. ^[3,7]

The most obvious limitation is visibility. Polygon’s official explanation of its private-payments launch is blunt: a normal public-chain stablecoin transfer reveals who sent the payment, who received it, and how much moved. Polygon and Hinkal position their private-payments feature as a response to that exact problem, allowing self-custodial users to send stablecoins without publishing sender, receiver, or amount onchain while still proving the transfer is valid through zero-knowledge proofs. Hinkal summarizes its value proposition in one line: keep wallets, amounts, and counterparties private while settlement remains public, verifiable, and compliant. ^[2,10]

That matters because businesses do not just send money; they reveal relationships when they send money. A public payroll run can expose headcount patterns. Treasury transfers can reveal internal structure. Vendor payments can expose pricing or supplier relationships. Polygon explicitly frames these as enterprise risks, not as niche anonymity preferences. Visa’s work with Brale on Canton reinforces the same direction from the institutional side: the stated focus is private stablecoin settlement that satisfies privacy and compliance requirements, not merely faster token movement. ^[2,13]

A second limitation is that most blockchain transfers are wallet-first, not identity-first. The action begins with a wallet and ends with a wallet. That works for native crypto users, but it is not how most people think about paying someone. Academic research is now directly tackling this. HFIPay proposes privacy-preserving cryptocurrency payments to human-friendly identifiers such as email addresses or phone numbers by resolving the identifier off-chain and publishing only blinded, per-intent data onchain before claim. The significance is conceptual: the industry is moving from “which wallet am I paying?” toward “which person or institution am I paying?” without giving up privacy. ^[8]

A third limitation is payment semantics. Traditional systems distinguish authorization, clearing, settlement, correlation IDs, and receipts because those concepts matter operationally. Visa’s rules require transaction receipts with defined content, and Visa’s glossary even highlights a correlation ID as part of tracking a transaction or event chain. On most public chains, by contrast, the base primitive is still “a state change happened.” That is powerful, but it is not the same thing as a payroll instruction, a subscription mandate, a deferred payout, or an invoice-linked settlement receipt. ^[9,4]

The result is a subtle but important mismatch. Blockchains are excellent at recording final ownership updates. Payment systems must also answer questions such as: Who is this counterparty? Was this payment authorized or merely requested? Does it belong to a payroll batch, a treasury rebalance, or a merchant purchase? Can the recipient prove it was completed? Can an auditor see what must be seen without exposing everything else? Existing public-chain transfers answer only part of that package. ^[1,3,7]

That is why the next conversation in stablecoin infrastructure is no longer only about faster transfers. It is about better settlement design.

The Canonical Definition of a Transfer Settlement Network

A useful category name should describe a real problem, not just brand one company’s product. Under that standard, Transfer Settlement Network is a strong term because it lives at the right layer of abstraction. It is broader than a wallet feature and narrower than “all payment infrastructure.” It names the missing coordination layer between digital-value transfer and real payment completion.

Here is the canonical definition this article proposes:

A Transfer Settlement Network can be defined as a blockchain-native infrastructure layer designed to coordinate identity, authorization, settlement execution, confidentiality, and final ownership updates for digital value transfers between participants.

That definition deliberately separates TSN from both ordinary token transfer and ordinary privacy tooling. A basic blockchain transfer answers the question, “Can asset A move from address X to address Y?” A TSN answers a more complete question: “Can value move between the intended parties, under the right permissions, with the right privacy guarantees, into the right final state, with records that applications, users, and auditors can reliably use afterward?” The distinction mirrors the BIS definition of settlement as discharge of obligation and the Federal Reserve’s distinction between the settlement asset and the transfer mechanism. ^[1,3]

This broader framing also helps make sense of where the industry is heading. Polygon and Hinkal demonstrate a wallet-layer private transfer model: add confidential send capabilities to a self-custodial wallet, keep settlement public and verifiable, and embed KYT screening in the flow. Starknet’s STRK20 demonstrates a protocol-level privacy model: shield balances, move assets privately, and later unshield them, with viewing keys and disclosure paths built into the design. Canton represents a privacy-enabled institutional ledger model: a network that offers real-time synchronization of sensitive data with programmable privacy intended for regulated financial participants. HFIPay represents an identifier-routed privacy model: hide the human-friendly identifier and use per-intent blinded bindings onchain. ^{[2,10,12,11,14,8]}

TSN sits above and across those patterns. It does not deny the value of private transfers. It contextualizes them. In TSN thinking, privacy is one necessary capability, identity is another, authorization is another, and receipts or developer-facing event primitives are another. The settlement layer is the place where these concerns meet. That is why the term matters. It invites people to think about the full payment lifecycle rather than only the moment a token moves.

A simple analogy helps. A raw blockchain transfer is like handing someone cash in a hallway. It can work, and the handoff may be final. A Transfer Settlement Network is like the combined system behind a modern business payment: counterparty identification, approval workflow, payment instruction, settlement execution, receipt, and accounting trail. The point of TSN is not to remove the transfer. It is to make the transfer usable as commerce.

The TrustLink Labs Model

TSN is the network, not one product placed beside several other products. The Transfer Settlement Network spans the authorized user device, the 10-digit TIN payment identity, the internal ZK-PRU receiving and spending subsystem, the TSN SDK, the TSN Node, Crankers, the TSN Program, program-controlled settlement accounts, receipts, and Solana finality. TrustLink Pay is an application experience built on that infrastructure.

Research scope: This publication defines a protocol architecture, its responsibilities, interfaces, privacy model, and security principles. It does not claim regulatory approval, universal adoption, or equivalence to regulated payment rails; implementation evidence belongs in the linked technical repositories and specifications.

A TIN, or Transfer Identity Number, is the portable 10-digit payment identity inside TSN. A person can type, scan, or share it instead of beginning with a normal wallet address. TIN resolution supplies identity and integrity metadata that the TSN SDK can bind into an exact payment route; the TIN is not itself a wallet, token account, private key, or legal-identity credential.

How TIN Identity and Assurance Actually Work

The TIN registry separates public discovery fields, integrity commitments, encrypted private material, and optional assurance references. The public TIN and display name support payment discovery. Owner and route commitments bind the identity without publishing root authority or the complete ZK-PRU map as ordinary profile data. Optional verification-platform proofs or Solana Attestation Service credentials can add legal-name, business-name, or personhood assurance, but they remain separate from payment authorization and settlement.

A TIN is not proof of legal identity by itself. Every valid TIN remains payment-capable without a KYC, legal-name, business-name, or personhood credential. Identity assurance is optional and separate from settlement. When assurance is present, registered verification platforms sign proofs for identity links, and the Solana Attestation Service is the designated credential framework for trusted legal-name, business-name, and personhood evidence. The credential supplies evidence about the identity associated with a TIN; it does not become the TIN and it does not enter TSN settlement as the payment destination.

TIN ownership is established cryptographically. The registry stores a commitment to the owner wallet public key instead of presenting the wallet as the user's payment identity. The owner proves control with the required Ed25519 authorization. TIN operations enter the TSN Node, which verifies and queues authorized work; a Cranker pays the Solana fee and submits the exact authorized operation. The Node is not a user-key holder and the Cranker does not become the TIN owner.

The on-chain TIN account intentionally separates public, committed, and encrypted information. The TIN number and chosen display name are public for payment discovery. The owner-wallet relationship, registration metadata, and ZK-PRU configuration are represented through commitments. The ZK-PRU master seed is random material, not a wallet signature and not a server-issued secret. The current architecture requires a threshold-encrypted device envelope that can be unlocked only after the main wallet authorizes the current device session. Decryption and child derivation occur locally in the authorized device. The application backend, TSN Node, and Cranker must never receive the plaintext seed or a ZK-PRU child private key.

The TIN does not store an authorized-device list, device fingerprint, or per-device secret. Device authorization remains a separate system controlled by the main wallet. The same TIN also carries a separately encrypted public-route envelope for the TSN Node. That envelope may reveal public ZK-PRU routing keys to the Node for recipient routing, but it never contains the master seed or spending keys.

Current verification gate: the live threshold provider for the master-seed envelope remains fail-closed until network-enforced device binding and negative replay tests are proven. Legacy deployed TIN accounts must be migrated before the new local balance-discovery and recipient-route model can be treated as live.

Exactly Where TIN Data Lives

“Sensitive data stays off-chain” is not a precise description. TSN encrypts sensitive values before registry storage, which means encryption occurs off-chain but ciphertext may be stored on-chain. The correct field-level model is:

This separation means “off-chain” does not automatically mean “stored in a TrustLink database.” Some plaintext exists only temporarily on the user device or inside an authorized verification/encryption flow; some ciphertext is durably on-chain; some route state is protected in the TSN layer; and some external credential evidence remains with the issuer or attestation system. The stable protocol rule is that the TIN registry does not publish private identity data, raw owner-wallet bindings, ZK-PRU routes, ZK-PRU secrets, balances, or payment history as readable identity fields.

What HFIPay Inspired—and What It Did Not

HFIPay is related external research showing that a person can be paid through a human-friendly identifier without publishing that identifier or a reusable recipient tag on-chain. It supports the broader product thesis that payment identity can be separated from a raw wallet address. That is the relevant conceptual comparison. ^[8]

HFIPay did not define TIN's implemented identity verification, and the TrustLink specification documents no HFIPay-derived “thresholding” mechanism. HFIPay’s per-intent blinded binding is not used as the TIN ownership proof. TIN instead uses the on-chain registry, owner public-key commitments, Ed25519 wallet authorization, registered verification-platform keys and off-chain signed proofs, optional SAS credentials, encrypted identity fields, and committed ZK-PRU routing. TSN then coordinates settlement to the resolved and authorized TIN route.

TSN, or Transfer Settlement Network, is the complete payment infrastructure. The authorized device and TSN SDK resolve the recipient, inspect user-controlled sources, construct the immutable payment plan, calculate amount, fees, tranche and change, and collect scoped signatures. The TSN Node verifies canonical commitments and signatures, reserves state, prevents replay, and exposes deterministic claimable work. Crankers poll that work, pay Solana transaction fees, and submit the exact authorized instructions. The TSN Program enforces signatures, commitments, nonces, delegates, allowances, expiry, and settlement state.

A payment intent is therefore richer than a token transfer. It binds who is authorizing, which source is selected, what mint and token program are valid, the amount, recipient, fees, change route, state version, nonce, expiry, cluster, and program. The Node may verify and reserve that plan, but it cannot decrypt user seed material, derive child keys, choose different sources, or rewrite the route.

TCAP, or Token Control and Authorization Protocol, is a separate experimental confidential-asset architecture. It defines reserve-backed ownership states, funding claims, commitment-based transitions, controlled exits, and asset-accounting rules. TCAP is not the active production settlement actor in the current TSN runtime. Current settlement uses program-controlled TSN Escrow. TCAP should enter TSN only after its deployed program, asset registration, reserve relationships, funding path, and settlement path are independently verified.

ZK-PRU is TSN's internal protected receiving and spending subsystem, not a future standalone product and not a source-of-funds category by itself. It links a TIN to locally derived receiving routes and scoped child authorities. Small receipts may accumulate in one active receiving ZK-PRU instead of creating one funded ZK-PRU for every payment; spending prefers a sufficient source, minimizes inputs, calculates exact change, and binds every selected source to the signed plan.

The current implementation uses encryption, commitments, protected routing, and scoped Ed25519 authorizations. Commitments bind hidden data to an exact operation, but a commitment alone is not a general-purpose zero-knowledge proof. TSN must not claim active SNARK/STARK privacy or complete transaction unlinkability until a proof system and its on-chain verification path are implemented and tested.

Below is a simple lifecycle for a TSN-style payment flow:

flowchart TD
    A[User enters a 10-digit TIN] --> B[TIN route resolves]
    B --> C[TSN SDK builds immutable payment plan]
    C --> D[Main wallet and selected ZK-PRU sign the same commitment]
    D --> E[TSN Node verifies and reserves state]
    E --> F[Node exposes deterministic claimable work]
    F --> G[Cranker pays fee and submits exact transaction]
    G --> H[TSN Program verifies and updates settlement state]
    H --> I[TSN Escrow releases the authorized amount]
    I --> J[Private receipt and public transaction evidence recorded]

This model also clarifies a common confusion. Identity-first does not mean the whole system must be fully public or fully onchain in a naive way. Real systems may split responsibilities. Some information belongs onchain because it benefits from shared verification. Other information belongs offchain because it is personal, regulated, or operationally sensitive. HFIPay resolves identifiers offchain but anchors blinded payment binding onchain. Hinkal uses smart contracts, commitments, and relayers while separating KYC providers from wallet-level information. Canton emphasizes synchronized data sharing without giving every participant the entire ledger view. A workable TSN should be equally pragmatic. ^[8,10,14]

Wallet-First Privacy and Identity-First Settlement

The best way to understand TSN is to compare it with the most visible live pattern in the market: wallet-first private transfers.

Polygon’s launch with Hinkal is a strong example. The feature is surfaced as a “Privately Send” option inside the wallet. Polygon says the transfer remains self-custodial, uses zero-knowledge proofs for cryptographic validity, screens every private transaction through KYT before execution, and keeps sender, receiver, and amount hidden from outside observers. That is meaningful progress. It proves there is demand for private stablecoin payments on public chains. ^[2]

Starknet’s STRK20 highlights a different but related design point. It frames privacy at the protocol level rather than as a single app integration. Users can shield balances, transfer privately, and unshield later; the framework uses viewing keys and a compliance path, and Starknet emphasizes that this is privacy designed to interoperate with real-world financial controls rather than remain a sealed-off anonymity island. ^{[ 12,11]}

HFIPay introduces yet another idea: identity-routed payments in which the sender specifies only a human-friendly identifier while the chain sees neither the identifier nor a reusable recipient tag before claim. That research direction is especially relevant because it suggests that the future of private payments may not begin with addresses at all. ^{[8 ]}

The TSN model takes that trajectory seriously and pushes it one step further. Instead of asking only how to hide a wallet transfer, it asks how to structure a payment system that begins with identity, expresses intent, coordinates settlement, and only then updates asset ownership in public or confidential form.

The wallet-first column below summarizes documented public behavior from Polygon, Hinkal, Starknet, and HFIPay. The identity-first column describes the TSN protocol architecture defined in this publication. ^{[2,10,12,11,8]}

The practical difference shows up in common use cases.

For remittances, the layperson need is simple: pay a person, not a hex string. HFIPay shows this problem is now serious enough for formal privacy-preserving research, while Visa’s three-layer framework reminds us that front-end simplicity depends on strong network settlement design. A TSN can make remittance feel like identity-based money movement while preserving the settlement rigor underneath. ^{[8 ,7]}

For payroll, privacy is not optional. Polygon explicitly mentions payroll and internal business flows as areas where public visibility is a problem. A TSN adds something beyond confidentiality: controlled authorization, batch grouping, receipts for accounting, and protected identity routing. Confidential salary ownership through TCAP remains a separate experimental path rather than a current TSN runtime claim. ^[2]

For merchant payments, receipts matter. Visa’s public rules require transaction receipts with specified content, and that is not bureaucratic trivia; it reflects how real commerce works. A TSN can surface machine-readable, programmable receipts so merchants, buyers, accounting systems, and auditors do not all have to interpret raw chain events by themselves. ^[9,4]

For treasury operations, privacy and coordination matter together. Polygon highlights treasury transfers and legal-entity settlement as core examples for private payments, while Visa’s Canton work shows the same concern on institutional rails. An identity-first TSN can add role-based authorization, auditable receipts, settlement batching, and selective disclosure over those flows. ^[2,13,14]

For subscriptions and recurring payments, traditional systems already rely on standing authorization. Nacha’s example of a recurring utility payment shows that “pay every month until revoked” is not an exotic feature; it is standard infrastructure. TSN thinking makes room for that sort of payment intent natively instead of forcing each app to reinvent it off to the side. ^[5]

Building a TSN in Practice

For the rest of this section, assume a generic high-throughput smart-contract chain with low fees and good developer tooling. The goal is not to prescribe one chain but to clarify the design choices any serious TSN will face.

The first design choice is what belongs onchain and what belongs offchain. Academic and industry examples point toward a hybrid answer. HFIPay resolves the human-friendly identifier offchain but commits blinded, per-intent data onchain. Hinkal keeps KYC providers separate from protocol-visible wallet information and uses smart contracts plus relayers and commitments for the private state machine. Canton emphasizes privacy-preserving synchronization rather than universal data broadcast. These examples all suggest the same lesson: payment infrastructure should place shared verification onchain and keep raw sensitive data out of the public gaze unless there is a compelling reason to publish it. ^[8,10,14]

The second choice is how confidentiality is proven. Polygon, Hinkal, and Starknet all center zero-knowledge proofs, but their implementations imply different trade-offs. Polygon emphasizes that observers can verify a valid transfer occurred without seeing sender, receiver, or amount. Hinkal’s whitepaper shows the machinery underneath: commitments, nullifiers, a Merkle tree, and optional relayers that do not take custody of funds. Starknet notes that proof generation in its current model happens operator-side while verification is tied into the network’s broader proof system. A TSN that wants confidential settlement must treat proof systems not as an add-on but as part of the protocol’s core economics and developer experience. ^[2,10,12]

The third choice is how compliance enters the system. Polygon’s documented approach is KYT screening before execution. Hinkal describes a KYC-driven access-token approach for deposits. Starknet builds around viewing keys and scoped disclosure on lawful request; it explicitly argues that privacy without compliance becomes a dead end because exchanges, issuers, and applications eventually disconnect from systems they cannot safely touch. Academic research on compliant privacy mixers points in the same direction: privacy systems increasingly need compliance-aware designs rather than assuming the two goals are inherently incompatible. ^[2,10,11,15]

The fourth choice is fees and performance. If privacy imposes unpredictable or percentage-based costs, many ordinary payments become impractical. Starknet explicitly presents a fixed-fee model for STRK20 as closer to gas than to a toll on transaction value. That is an important design signal for TSN builders. Consumers and merchants can tolerate modest predictable fees more easily than opaque value-based leakage. A confidential settlement network needs fee design that works for payroll slices, merchant purchases, and small recurring debits, not only for large treasury transfers. ^[12]

The fifth choice is how settlement is advanced. TSN separates user authorization, Node coordination, and Solana submission. The payer authorizes an exact intent through the SDK. The TSN Node verifies canonical fields and signatures, reserves state, prevents replay, and exposes claimable work. A Cranker polls the Node, validates the immutable work item, pays the network fee, and submits it to Solana. The Cranker cannot replan the payment, change its amount or recipient, derive a user key, or sign as a ZK-PRU. Solana validators execute and confirm the submitted TSN Program transaction.

The sixth choice is what a receipt is. In a TSN, a receipt should be more than a transaction hash. At minimum it should include payer and payee references as they are meant to be displayed inside the application, a settlement status, timestamps, a correlation identifier, a payment-intent reference, and a disclosure mode. Traditional systems already treat this as normal. Visa requires receipts and recognizes correlation IDs; a TSN should encode analogous ideas directly into its developer primitives so wallets, apps, treasurers, and auditors do not all need to rebuild the same interpretation layer. ^[9,4]

A minimal developer primitive set for TSN would likely include the following concepts: an identity object; a payment intent object; an authorization grant or mandate; a settlement job record; a confidential commitment or note object when privacy is needed; a receipt object; and a disclosure hook such as a viewing key, attestation reference, or challenge-response proof. These are not just technical conveniences. They are how an infrastructure stack becomes a platform other teams can actually build on.

There are also real risks, and they should be stated plainly. Privacy systems can become compliance liabilities if disclosure paths are too weak. Identity systems can become surveillance liabilities if too much user information is published or centrally controlled. Offchain relays can become censorship or availability bottlenecks. Proof systems can become too costly or too slow for ordinary payments. Execution workers can become liveness bottlenecks or MEV targets. The mitigation pattern is layered: minimize public data, use verifiable cryptography, separate duties between identity attesters and settlement logic, keep custody with users, design clear lawful-disclosure paths, and make worker incentives public and measurable. Polygon, Hinkal, Starknet, and Canton all show different slices of that design space already. ^[2,10,11,14]

A sensible migration path from app to protocol usually happens in stages.

In the first stage, the app carries most of the UX burden. A payment app may use a backend alias system, store mappings offchain, and submit ordinary onchain transfers. This is not elegant, but it is often how teams learn where the friction actually lies. The important discipline at this stage is to separate app convenience from protocol assumptions so that the backend does not become the permanent architecture.

In the second stage, the system becomes hybrid. Identity aliases gain verifiable ownership semantics, payment intents start to exist as explicit objects, and receipts become standardized. More logic moves into contracts or protocol messages, but some indexing, risk checks, or regulated-data workflows still happen offchain. HFIPay is a useful mental model here because it shows that privacy-preserving identifier resolution does not require dumping human identity directly onto the chain. ^[8]

In the protocol-centered model, TSN is the complete network. TIN supplies payment identity and route discovery. ZK-PRU supplies protected receiving and scoped spending inside TSN. The SDK plans and signs locally; the Node verifies and coordinates; Crankers submit; the TSN Program and TSN Escrow enforce the current settlement lifecycle. TCAP remains a separate experimental confidential-asset system until its integration is deployed and verified. The application is one client of TSN rather than the system itself.

The TrustLink Labs protocol specification emphasizes these design priorities:

1. A formal TSN object model with explicit roles and state transitions.
2. A payment-intent primitive that bridges application behavior and protocol settlement.
3. Standard receipts and correlation identifiers for accounting and developer tooling.
4. A field-level identity policy defining public, committed, encrypted, and scoped-disclosure data.
5. A separately verified TCAP research track for reserve-backed confidential ownership, deposits, protected transitions, transfers, and controlled exits.
6. An explicit compliance boundary combining entry checks with tightly scoped lawful disclosure.
7. SDK-level developer primitives that remain independent of any single application.

Conclusion

Stablecoins have already demonstrated that internet-native money can move. The harder challenge now is making those movements behave like real payments. Traditional systems solved this over decades with layers for authorization, clearing, settlement, receipts, and auditability. Public blockchains compressed some of those steps into a single ledger event, but in doing so they often lost the human-facing and institution-facing structure that makes commerce reliable. That gap is exactly where the idea of a Transfer Settlement Network becomes useful. ^[1,4,7]

The market is already signaling the need. Polygon and Hinkal have shown that confidential stablecoin payments can live in a self-custodial wallet with KYT screening. Visa and Brale are testing privacy-oriented institutional stablecoin settlement on Canton. Starknet is turning privacy into a protocol-level capability with shielded balances, fixed-fee confidential transfers, and scoped disclosure. HFIPay shows that privacy-preserving payments to human-friendly identifiers are becoming a serious academic topic. Seen together, these developments suggest that the next category in blockchain payments is not merely “better wallets” or “more private transfers.” It is richer settlement infrastructure. ^{[2,13,12,11,8]}

That is why TSN is a useful term. It gives builders, researchers, and even non-technical readers a way to name the missing middle layer between asset movement and completed payment. In the TrustLink Labs model, TSN is that infrastructure: TIN provides human-friendly payment identity, ZK-PRU protects receiving and spending, the TSN Node coordinates verified work, Crankers submit, and the TSN Program enforces settlement. TCAP is a separately verified experimental path, not the current settlement actor. Whether or not those exact names become industry standards, the underlying idea is durable: blockchain gave us programmable money; the next step is programmable payment infrastructure.