> ## Documentation Index
> Fetch the complete documentation index at: https://trust-link-tsn.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# How a TSN Transfer Works

> The user-facing sequence for resolving a TIN, authorizing a transfer, and settling it on Solana.

A TSN transfer begins with an identity the recipient can share and ends with an on-chain settlement governed by TCAP. The sender reviews the resolved recipient and authorizes the payment; protocol services verify the request and prepare it for execution.

This is TSN's hybrid model: applications and protocol services coordinate the request off chain, while TSNP and TCAP enforce applicable authorization, asset, and settlement rules on chain. This model is intended to connect value transfer across the Internet of Value, while the status of each cross-network route remains specific to its verified deployment.

```mermaid theme={null}
sequenceDiagram
    participant S as Sender and wallet
    participant A as Application and SDK
    participant N as Node
    participant R as Receiver
    participant K as Cranker
    participant P as TSNP
    participant T as TCAP
    participant G as GPRU

    S->>A: Choose recipient TIN and payment details
    A->>A: Resolve display identity through trusted lookup
    A->>S: Present payment for review
    S->>A: Sign message and exact reserve deposit
    A->>N: Submit the authorized intent
    N->>R: Persist authorized funding ingress
    N->>R: Lease and verify funding
    K->>R: Claim verified funding
    K->>T: Submit unchanged wallet-signed deposit
    K->>R: Report confirmed funding
    N->>N: Resolve TIP route and prepare root-matching proof
    N->>R: Signed verified settlement projection
    K->>P: Submit Mother-authorized call followed by Memo
    P->>T: Invoke governed credit
    T->>G: Verify hidden-head proof and Memo
    G-->>T: Valid transition relation
    T->>T: Advance shared root and liability accounting atomically
    K->>R: Report confirmed settlement signature
    A->>R: Reconcile funding and settlement status
```

GPRU protects the integrity and privacy of the user's private state presented to TCAP: its proof is intended to show that the hidden state is current and that the proposed change follows from it. TCAP remains responsible for the funds and applies a valid authorized change atomically.

## What confirmation means

An accepted request means the application delivered the intent. Verification means the protocol services accepted it for processing. A submitted transaction is not yet a confirmed transaction. Settlement is confirmed only when the relevant Solana transaction succeeds; for a flow with separate funding and credit transactions, each signature represents a separate stage.

The inspected sequence requires separate funding and settlement confirmation. 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](https://trust-link-tsn.mintlify.site/security/threat-model.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.