Transfer Settlement Network (TSN) Protocol Whitepaper

Protocol specification · TSN whitepaper

The Transfer Settlement Network (TSN) is an intent-based protocol for stablecoin settlement. It separates payment identity, authorization, routing, settlement liability and private accounting so an automated submitter can execute an authorized payment without custody of owner keys or disclosure of a recipient balance.

Abstract

TSN is currently specified and implemented as a Solana source accounting domain. The repository also contains the Creditcoin-first EVM settlement boundary, Attestcoin route verification, destination vault and executor contracts, and deployment helpers. These source components are not the same as a live production deployment: testnet deployment and real transaction evidence are required before the cross-chain path can be called operational.

1. Protocol model

A payment is a sender-authorized state transition, not an instruction assembled by a relay. The owner device resolves a recipient TIN, binds the privacy-receiving relationship and policy, and signs an intent containing the asset, amount, validity window, replay material and settlement commitments. Every later transition is bound to those signed values.

TIN → privacy-receiving root → GPRU → TSN Epoch Treasury → AcceptedIntent → ConfidentialSettlement → TCAP tip credit → encrypted private balance snapshot → owner private read

TIN is a payment identity. GPRU is scoped, non-custodial authorization and routing; it never holds a balance. TSN coordinates settlement liability. TCAP (Transfer Confidential Asset Protocol) records private balance transitions as commitments and encrypted snapshots.

1A. Payment routes

TSN supports four native Solana routes and one Creditcoin-led cross-chain route:

Route	Settlement behavior
Wallet deposit → wallet exit	Compatibility route using common intent, authorization and liability boundaries.
Wallet deposit → TIN credit	Funds become private TCAP credit for the recipient identity.
TIN debit → TIN credit	Identity-to-identity settlement without exposing a public destination address from the device boundary.
TIN debit → wallet exit	Public wallet exit through the existing Mother-rooted DNA and exit-permit boundary.
Solana → Creditcoin or another supported EVM network	Solana creates the debit commitment; Creditcoin consumes it and Attestcoin connects the authenticated instruction to a selected prefunded destination route.

2. Participants and authority

The owner device holds the privacy-receiving root, signing material and snapshot key. The Receiver accepts authenticated, redacted work. The Node verifies signatures, policy, commitments, sequence and expiry. Mother and TSN authorize the ConfidentialSettlement transition. The Epoch Treasury records funded liability. A Cranker submits the exact authorized transaction and pays execution fees; it cannot alter amount, asset, recipient, commitments, policy, sequence or nullifier. TCAP verifies the receipt and advances the recipient tip.

No coordination role grants a spending key or unilateral authority to redirect value.

3. Solana settlement domain

The device resolves the recipient TIN and signs the canonical payment intent.
The Receiver stores authenticated redacted work; the Node verifies it.
A Cranker submits the exact governed Solana funding and acceptance transaction.
Solana records Epoch Treasury liability and the canonical intent root atomically.
Mother/TSN authorizes the applicable settlement transition.
The Cranker submits the exact authorized Solana credit or exit transaction.
TCAP checks the receipt, commitments, sequence, policy, scope, validity window and one-time nullifier.
The owner device verifies and decrypts the encrypted snapshot addressed by the resulting commitment.

Funding and AcceptedIntent acceptance are atomic: if either instruction fails, the transaction reverts. Settlement authorization and TCAP credit are separate later transitions and consume the same accepted-intent bindings.

4. State and commitments

An AcceptedIntent binds epoch, payment commitment, amount, token, recipient tip root, policy, settlement commitments, replay nonce and validity window. Its canonical root is the identifier used by later authorization; a caller cannot replace it with an unrelated root.

A TCAP tip stores a predecessor commitment and sequence, not a plaintext TIN, private balance or device secret. A credit advances one predecessor to one successor: previous_commitment = tip.current_commitment, new_commitment = successor(previous_commitment, authorized transition), and new_sequence = tip.sequence + 1.

The snapshot store holds encrypted balance state keyed by the resulting commitment. Plaintext roots, seeds, snapshot keys and balances remain with the owner device.

5. Security invariants

The protocol requires device authorization over canonical fields, one-time nullifiers, monotonic sequences, validity windows, exact policy and GPRU scope, and predecessor/successor commitment continuity. Treasury funding and intent acceptance are atomic. Receiver, Node and Cranker may be unavailable, but they cannot rewrite an accepted authorization or spend from it. Confidential debit and exit are proof-gated until conservation, destination-binding and liquidity proofs are enabled.

Public state exposes only evidence required for verification. TIN is bound to the receiving root through a one-way relationship and is not a public key for a TCAP balance.

6. Settlement domains and attestations

A settlement domain is a blockchain-specific execution environment with its own assets, finality and transaction rules. TSN keeps identity and intent semantics stable while a domain adapter maps a verified authorization into that environment.

Attestation is TSN’s cross-domain connection mechanism. It binds source and destination domains, settlement identifier, assets, amount, accepted intent, recipient, sequence or nonce, validity window and settlement commitment. The destination verifies the cryptographic source fact before executing its own transaction. A transaction hash, API response or operator statement is not sufficient.

7. Creditcoin-first EVM domain

The first additional settlement domain is Creditcoin. The source repository contains the Creditcoin route, liquidity, executor and message boundaries, but deployment and real testnet evidence are still required before the path can be called live:

Solana debit intent → Node validation → Solana debit commitment → Creditcoin Hub authorization → Attestcoin authenticated message → selected EVM executor → prefunded stablecoin vault → recipient

The destination must reject a message whose domain, asset, amount, recipient, settlement identifier, finality, route or validity window does not match the source authorization. Creditcoin is the first funded EVM settlement domain and the source for onward supported-EVM payout messages.

8. Liquidity and value model

A message is not a payment asset. The value path is:

Liquidity provider or treasury → prefunded stablecoin vault → registered destination executor → recipient wallet

Creditcoin CTC pays Creditcoin gas. The destination network’s native token pays destination gas. Stablecoins are the payout asset. Attestcoin proof and message infrastructure verifies and connects a route; it does not create liquidity. A route is not eligible without a configured executor, token, destination network and current liquidity observation.

The direct Creditcoin route and an onward EVM route use the same principle: the network that pays the recipient must have stablecoins available in its own configured vault. The Hub reserves verified route capacity before publishing the payout message.

9. Contract and software boundaries

Component	Responsibility	Value custody
CreditcoinSettlementHub.sol	Verify authorization, reject replay, reserve route capacity and publish payout message.	No destination payout balance.
DestinationLiquidityASC.sol	Verify source liquidity evidence through Attestcoin readability.	None.
DestinationLiquidityRegistry.sol	Store route configuration, observations and reservations.	None.
TSNSettlementExecutor.sol	Validate the authenticated destination message and invoke local payout.	Uses the vault boundary.
TSNERCLiquidityVault.sol	Hold and release destination stablecoins.	Yes, destination liquidity.
TinExitAttestedASC.sol	Record a proved exit receipt.	No payout liquidity.
TSN Node	Orchestrate, validate, authorize and track.	No user payout custody.
Cranker	Submit exact authorized transactions and pay gas.	No user payout custody.

Solana-native programs remain outside the cross-chain layer. The cross-chain layer must not rewrite sealed TIP, the two-phase exit commitment, Path 1/2 wiring, one-vault behavior, liability PDAs or GPRU-only authorization.

10. Threat model

Security depends on source and destination consensus, cryptographic signatures, attestation verification, TSN authorization rules and the correctness of each domain adapter. The threat model includes compromised or unavailable Receiver, Node, Cranker, relayer, liquidity provider and RPC services.

Availability failure may delay settlement; it must not authorize a new value transfer, bypass a nullifier, redirect a recipient or convert an invalid message into a payout. The current Creditcoin Hub proves a Node-signed commitment payload on Creditcoin; it does not claim independent Solana verification through Block Prover.

No raw TIN, private balance, device key, plaintext receiving root or snapshot secret is written to Creditcoin or another secondary EVM network.

ZK-PRU was an earlier experiment and is retired. It is not part of the receiving, balance or spending architecture described here.

11. Implementation and deployment status

The repository contains the cross-chain contracts, Node route validation, TSN-only SDK façade, Attestcoin integration helpers and testnet deployment scripts. Source compilation is not the same as a live deployment.

Configure a funded Creditcoin CC3 Testnet EVM signer.
Provide the real CC3 Attestcoin token and protocol route addresses.
Deploy the Creditcoin contracts on CC3 Testnet.
Configure a supported destination route and prefund its stablecoin vault.
Submit a real Solana debit transaction and the resulting authorized Creditcoin settlement transaction.
Record real explorer links and emitted events before publishing deployment claims.

12. Scope and non-goals

This paper covers identity-aware settlement coordination, Solana source accounting, Creditcoin-first EVM settlement, Attestcoin liquidity verification and message delivery, destination stablecoin liquidity, and the Node/Cranker execution boundary. It does not claim that a proof or message is itself a stablecoin, that Creditcoin pays every destination from one universal vault, that Solana is currently supported by Creditcoin’s native Block Prover, or that a Cranker generates proofs or makes payout decisions.

8. Threat model

Security depends on source and destination consensus, cryptographic signatures, attestation verification, TSN authorization rules and the correctness of each domain adapter. Liveness depends on Receiver, Node, Cranker and destination liquidity. A failure may delay or revert a transition; it must not create value, bypass a nullifier or redirect an authorized payment.