TSN Flow - How TSN Transactions Work
How a TrustLink payment is authorized, settled and credited
TSN separates identity, authorization, settlement coordination and private balance accounting. The public chain verifies the rules it must enforce; the owner device retains the private material required to read a balance.
TIN identity → privacy-receiving root → GPRU authorization and routing → TSN Epoch Treasury → Mother/TSN ConfidentialSettlement authorization → TCAP tip credit → encrypted private snapshot → owner-device balance read.
What TSN does
TSN is the Transfer Settlement Network. It coordinates a payment from signed intent through verifiable settlement work. TSN is not a replacement for Solana consensus and it is not a user wallet. Its job is to make authorization, ordering, leases, liability and one-time execution explicit.
TCAP means Transfer Confidential Asset Protocol. TCAP is the private balance accounting layer: it advances a commitment-backed tip and anchors the owner’s encrypted snapshot. GPRU never holds funds.
System map
- 01IdentityTIN identifies the recipient relationship without publishing a human-facing wallet address.
- 02AuthorizationThe owner device signs the intent, privacy-receiving-root relationship and GPRU scope.
- 03VerificationReceiver stores redacted work; the TSN Node verifies signatures, policy, commitments, sequence and expiry.
- 04Settlement liabilityMother and the Epoch Treasury bind the authorized transition to protocol-controlled accounting.
- 05TCAP creditThe TSN CPI wrapper presents a complete ConfidentialSettlement receipt; TCAP consumes it and advances the tip.
- 06Private readThe owner device verifies and decrypts the matching encrypted snapshot locally.
The payment, stage by stage
1. Device authorization
The authorized device resolves the recipient TIN and privacy-receiving-root relationship. Private roots, master seeds, snapshot keys and plaintext balances remain on the device. A TIN is not a private key, token account or permission to spend.
2. SDK intent construction
The SDK constructs an immutable intent containing the payment commitment, amount and asset binding, recipient tip relationship, policy reference, GPRU scope, replay material and validity window. The authorized device signs the intent and the scoped authorization. A signature authenticates an already-bound plan; it does not authorize a Cranker to invent a new one.
3. Receiver ingress
The Receiver accepts authenticated work, stores a redacted coordination record and manages lease/status transitions. It is not a custody layer. It must not receive plaintext roots, seed phrases, spend keys, snapshot plaintext or private balances.
4. Node verification
The TSN Node verifies the signed fields and policy before work becomes executable. It checks commitment relationships, sequence, expiry, replay material, account bindings and the applicable lease. Invalid or stale work fails closed.
5. AcceptedIntent and root binding
For a ConfidentialSettlement credit, TSN records the accepted payment as an AcceptedIntentV1 PDA. Its canonical root is domain-separated and derived over the epoch, payment commitment, amount, token binding, recipient tip root, settlement bindings, policy, GPRU scope, replay/nullifier material and validity window. The wrapper receives that PDA and verifies the supplied fields against it; a caller cannot substitute an unrelated root.
6. Epoch Treasury and Mother authorization
The Epoch Treasury records aggregate funding and liability for the epoch. Mother/TSN creates the one-time ConfidentialSettlement authorization. This is an authorization boundary, not a plaintext balance ledger.
7. Cranker submission
A Cranker pays transaction fees and submits the exact authorized transaction. It cannot change the amount, token, recipient tip, commitment, sequence, policy, GPRU scope, nullifier or expiry. Cranker infrastructure is a submitter boundary; the TCAP credit path does not depend on CrankerVault payout liquidity.
8. TCAP receipt and tip credit
TCAP registers the complete receipt, requiring ConfidentialSettlement, the approved TSN program, the AcceptedIntent binding, the correct epoch root and all credit fields. credit_tcap_tin_tip_v1 checks the receipt, previous commitment, new commitment, sequence, token ID, policy commitment, GPRU scope, nullifier and validity window. It consumes the receipt/nullifier and advances the tip atomically.
9. Encrypted snapshot and owner read
The resulting commitment is persisted with an encrypted private snapshot. The snapshot store does not need to expose the plaintext balance to Receiver, Node or Cranker. The owner device fetches the matching ciphertext, verifies its commitment and decrypts it with owner-held snapshot material.
What is public and what is private?
| Boundary | Visible for enforcement | Retained privately |
|---|---|---|
| Identity | TIN relationship references and fixed commitments required by policy | Plaintext privacy-receiving root and identity metadata |
| Authorization | Commitments, token ID, policy, scope, sequence, nullifier and validity window | Signing seeds and device authorization material |
| TCAP credit | Tip PDA, receipt state, commitment transition and replay state | Private balance snapshot and snapshot key |
| Operations | Lease/status evidence and submitted transaction signatures | Service credentials, deployment secrets and private logs |
A TIN is not written into the TCAP tip as a public identity label. The tip is addressed by a blinded tip-root commitment and stores transition state, not a plaintext TIN or private balance. This reduces direct identity linkage; it does not promise that all timing, token or public-account signals disappear from Solana.
Who may change what?
- Owner device: authorizes the identity relationship, intent, scope and private snapshot read.
- Receiver: stores redacted ingress work and lease state; it cannot authorize value.
- TSN Node/Mother: verifies and authorizes the settlement transition within protocol policy.
- Cranker: submits exact authorized work and pays fees; it cannot rewrite the receipt.
- TSN program: enforces epoch, authorization, lease and one-time state.
- TCAP program: enforces receipt, tip, commitment, sequence, policy and nullifier rules.
Debit and exit boundaries
Credit is the active private-balance direction. Debit and exit interfaces may exist for future proof integration, but live confidential debit and exit remain proof-gated. A GPRU signature, hash-only payload or placeholder proof cannot spend a balance or drain a liquidity pool.
How to review the implementation
Reviewers should separate:
- Code evidence: account constraints, instruction logic and tests in the repository.
- Build evidence: successful SBF build with the stated Anchor/Rust toolchain.
- Devnet evidence: program ID, deployment slot, transaction signature and post-transaction account state.
- Production readiness: independent security review, governance controls, operational monitoring and an audited proof system for spend.
Program-dependent testing is Devnet-only. After any program or ABI change, build, deploy and verify the updated Devnet bytecode before interpreting a simulation or transaction result.
Architecture history
ZK-PRU was an earlier receiving and spending experiment. It was superseded by the privacy-receiving-root, GPRU and TCAP model. It is retained only as historical audit material and must not be targeted by new integrations.
TIN identity · GPRU authorization · TCAP private accounting · Research updates