Transfer Settlement Network
Research edition · TrustLink Labs

Money Never Sleeps: The Trust Layer Blockchain Payments Need

Blockchain payment infrastructure enabling stablecoin settlement and privacy

Blockchain payments have moved from experiment to infrastructure. The open question is no longer whether digital money can settle quickly — it demonstrably can — but whether people and institutions can trust the systems that move it. This piece sets out why settlement alone is not a payment system, where real-world failures still happen, and one approach being built to close the gap.

The Settlement Revolution Has Already Started

To understand what is changing, it helps to be precise about what the old system was. Card and bank settlement in the United States ultimately runs through Fedwire, the Federal Reserve's real-time gross settlement rail, which has operated since 1915. The reason a Friday-night purchase historically did not settle until Monday was never that the technology could not run over a weekend. It was operational: Fedwire keeps defined business hours, and the harder problem — keeping enough liquidity on hand to settle at any hour — is what makes round-the-clock operation genuinely difficult. Blockchain settlement has no business hours, which is why it removes that constraint in the first place.

The shift is measurable rather than rhetorical. Stablecoin transfer volume reached roughly $27.6 trillion in 2024, exceeding the combined transaction volume of Visa and Mastercard for the first time, according to a CEX.IO industry report. That number deserves an honest caveat: raw on-chain volume includes automated trading, bot activity, and internal exchange transfers, and Visa's Onchain Analytics estimates that only about a quarter to a third of it reflects genuine payment activity. Even at the conservative end of that range, several trillion dollars of real settlement moved through stablecoin rails in a single year — enough that the discussion has shifted from whether stablecoins matter to how they are integrated and regulated.

The institutional signal points the same way. JPMorgan's Kinexys platform settles billions of dollars of intraday repo, cross-border payments, and foreign exchange daily on a permissioned blockchain. Visa has begun settling in USDC on Ethereum for institutional clients, Mastercard has added stablecoin settlement rails, and DTCC is rolling out a tokenization service with more than fifty financial firms. BlackRock's tokenized money-market fund, BUIDL, crossed a billion dollars in assets, and JPMorgan, Citi, Bank of America, and Wells Fargo are building a shared tokenized-deposit network through The Clearing House. These are production deployments with target dates and committed capital, not concept papers.

Here is the point that matters for everything that follows: settlement is the solved part of the problem, and it has been for years. What remains unsolved is the layer above settlement — the layer that decides who you are paying, whether you are authorized to pay them, and what happens when something goes wrong. That is where most of the real-world risk still lives.

The Human Problem Hidden Inside Blockchain Payments

Blockchains were designed for cryptographic security, and on that narrow measure they work. The difficulty is that cryptographic correctness and human intent are different things. A transaction can be mathematically valid and still be the wrong transaction.

A freelancer is about to send a $2,000 stablecoin payment to a contractor. She copies the contractor's wallet address from a messaging app. Unbeknownst to her, clipboard-swapping malware replaces the copied string with an attacker's address. She pastes it and checks the first few characters and the last few — the characters the malware deliberately preserved — and confirms. The transaction settles in seconds. It is fully valid on-chain. It is also irreversible, and there is no dispute process that can unwind it.

This is not a rare edge case. The same class of failure — a technically correct transfer carrying the wrong human intention — appears in wrong-address copy-paste, malicious replacement, compromised devices, and the simple inability to verify who actually controls a destination. A wallet address was designed as a destination for a program, not as a financial identity for a person. Using it as one turns every payment into a single paste away from a silent, irreversible mistake.

The Problem Is Not Blockchain. The Problem Is the Missing Coordination Layer.

The reason this persists is structural. Blockchains are excellent at settlement: they execute a transaction exactly as authorized. By design, they know nothing about identity, intent, or recovery, because that knowledge was always someone else's job. In traditional finance, institutions did that job. Banks, clearing houses, and processors sat between sender and destination and absorbed the responsibility for verifying counterparties and unwinding errors.

Blockchain removed most of those intermediaries. The removal is the point — it is what makes settlement fast, global, and low-cost. But it also removed the coordination layer, and nothing equivalent replaced it. The useful work those institutions performed is now expected from the end user, who is not equipped to do it.

A payment system, even a decentralized one, still needs five things that a bare transaction does not provide: a way to name a recipient without exposing a raw address; a way for the sender to state and authorize intent; a way to route the payment privately; a way to recover or dispute; and confidence, before settlement, that the destination is the right one.

The Future of Payments Requires Separating Identity From Wallet Exposure

The underlying design mistake is that a wallet address has been asked to do everything at once: it is an account, an identity, a destination, and a public transaction history. That conflation produces the privacy and usability problems above. A person who receives a payment should not have to expose their entire on-chain history to do so, and a business should not have to reveal every counterparty relationship to use digital settlement.

Separating those roles is the central architectural idea. Identity should be used for discovery — establishing where a payment should go. Authorization should be used for permission — proving the sender is allowed to make this payment. Settlement should execute securely. Privacy should protect the relationship between sender and receiver. None of those four jobs needs to be performed by the same public string of characters.

Why We Started Building the Transfer Settlement Network (TSN)

TSN is our attempt to rebuild that coordination layer. An honest framing matters here: this is an early-stage research and design effort, and the application built on it, TrustLink Pay, is in active Solana devnet validation. It is a proposed architecture under test, not a finished product. But the design choices are concrete, and each one maps to a specific failure described above. None of this is cheap to adopt: connecting a new coordination layer to existing wallets, compliance systems, and user habits is exactly the kind of integration work that makes payment networks change slowly.

A payment intent, instead of a raw transaction.

In TSN, a sender never submits a bare transfer. They sign a payment intent — a structured authorization that binds together the protocol identifier, the purpose of the TIN, the asset, the amount, the destination scope, an expiry, and any conditions. That signed intent enters a coordination layer where it is verified before anything reaches the chain. The design separates two layers of authority: the user's on-device signature is Layer 1, and a scope-restricted execution authority is Layer 2, granted only after the Layer 1 signature verifies. Layer 2 cannot act without a valid Layer 1. A fee-paying relayer called a Cranker submits the transaction on-chain but cannot alter the amount, the recipient binding, the commitment, or the route.

Identity-based discovery, instead of address exchange.

The sender addresses the recipient by a ten-digit Transfer Identity Number rather than a wallet address. The TIN is a routing handle, not a key: it is resolved through an identity registry to a destination, and a familiar identifier such as a phone number can assist discovery without ever becoming the public on-chain identifier. The recipient's plaintext wallet information never appears where a sender could copy it. What reaches the chain is not a plaintext root but cryptographic commitments, nonces, and validity data — enough to verify the payment, not enough to reconstruct who is who.

Protected receiving routes, instead of a public history.

On the receiving side, routing is scoped and redacted. A routing component supplies authorization and routing context without holding funds, and the settlement route is chosen by computation rather than pasted by the user. The receiver, node, and fee-payer each see only the redacted coordination data they need. The public record of a payment is a set of commitments, not an open ledger of the relationship.

Return to the freelancer example. With this flow she never copies an address, so there is no string for malware to swap. She selects the contractor by TIN or saved contact, and the destination is resolved for her. The intent she signs cryptographically binds the amount and the recipient's identity commitment; if any field were altered after signing, the Layer 1 verification fails and the payment stops before it reaches the chain. The contractor's plaintext wallet information was never exposed anywhere the sender could mis-copy. The specific failure the malware exploited — a raw address that could be silently substituted — does not exist in the flow.

The Next Generation of Financial Infrastructure

It is worth being precise about how others are attacking the same problem, because TSN is one answer, not the only one. The approaches fall into a few families.

  • Human-readable names (for example, Ethereum Name Service) replace the address with a memorable name. This solves memorability but not privacy — the underlying address remains public and copyable.
  • Custodial wallets and exchanges (such as PayPal's PYUSD) solve usability and recovery by taking custody, which reintroduces the centralized intermediary blockchains were meant to reduce.
  • Institutional tokenized deposits (JPMorgan's Kinexys, the Clearing House network, Mastercard, DTCC) solve settlement for banks on permissioned rails, but they are built for institutions, not for an individual paying a contractor.
  • Confidential transfers (zero-knowledge and privacy-preserving settlement) solve the exposure problem, sometimes at the cost of added complexity or compliance friction.

TSN's position sits at the intersection of these: the simplicity of a name, the non-custodial property of self-custody, the efficiency of blockchain settlement, and the privacy of confidential transfers — achieved by separating identity from address exposure and authorization from execution. Whether that combination holds in production is precisely what the devnet validation is meant to establish.

The Future of Payments Will Be Built Around Trust

Every layer of financial infrastructure, from the telegraph to the card network to the internet, went through a period in which the technology worked before people trusted it. The same is true now. Blockchain can settle; that was never the hard part. The hard part is the coordination layer that lets people name a recipient, authorize a payment, and keep the relationship private, so that what settles is the payment they actually intended to make.

The systems that win the next era of payments will not simply be the ones that move the most value. They will be the ones that make people confident about where that value is going. That is the layer we are trying to build.

For the person sending or receiving money, none of this is visible. A sender still pays in stablecoins and a recipient still receives stablecoins. What changes is everything underneath: the recipient is addressed by identity rather than a pasted string, the payment is authorized before it settles, and the relationship stays private. The goal is not to ask people to learn a new system — it is to change the infrastructure so they do not have to.

Sources

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
This research began from building TrustLink Pay and studying the weaknesses of existing blockchain payment flows.
at

Written by

TrustLink Labs · View all posts