Skip to main content
TSN’s guarantees hold under specific, well-defined adversary classes. This page enumerates them, states what each can and cannot achieve, and lists what is deliberately out of scope for the current architecture.

​
Adversary classes

​
Compromised Receiver

Can lose or corrupt work state, delay ingress, or drop leases. Cannot verify signatures, cannot forge Node authorization, cannot decrypt private snapshots, and must never receive plaintext roots or authorization material. A compromised Receiver cannot mint a valid ConfidentialSettlement receipt.

​
Compromised Node

Can refuse verification or delay decisions. Cannot forge Mother authority, cannot mint DNA, and cannot access encrypted binding keys beyond its own Node/Mother scope. A compromised Node cannot alter a sender-signed intent because the sender signature is checked on chain.

​
Compromised Cranker

Can delay, censor, or attempt to replay within a lease window. Cannot change amount, token, recipient binding, commitments, sequence, policy, nullifier, or expiry. The Solana program re-checks Node permit and lease before any token movement. If the Cranker tries to submit different bytes than the authorized transaction, the program rejects it.

​
Network observer

Sees commitments, sequence numbers, policy commitments, nullifiers, and the opaque slot at the moment of consumption. Does not see the plaintext balance, privacy-receiving root, TIN master seed, or snapshot plaintext. Cannot correlate a funding transaction to a specific settlement slot because the opaque slot is absent from funding.

​
Malicious sender

Bounded by TCAP asset entry status: the entry must be active, approved, and unpaused. A policy_commitment mismatch prevents the transition. The sender cannot force TCAP to accept a transition that does not match the tip PDA’s stored policy.

​
Malicious recipient

Cannot mutate the Node-signed permit or claim the epoch slot before authorized settlement. Even if the recipient controls the destination account, the Solana program requires the full ConfidentialSettlement receipt before crediting the tip.

​
Out of scope

TSN does not defend against the following. Integrators must treat these as separate concerns:
  • Solana consensus failure. TSN relies on Solana’s execution, ordering, and finality.
  • Sender device signing key compromise. If the sender’s wallet key is stolen, that wallet can authorize new intents. Use hardware wallets and standard key hygiene.
  • Out-of-band coercion of the TIN holder. TSN cannot prevent someone from being coerced into signing an authorized transfer.
  • Confidential debit and exit. These paths remain proof-gated and are not live in phase one. Do not treat GPRU signatures or placeholder proofs as spend authorization.
  • Application-layer privacy leaks. A frontend or backend that logs sensitive fields, exposes plaintext identifiers, or fingerprints users is out of TSN’s scope.

Invariants

The 11 protocol invariants that must always hold.

Authority & Keys

Every key in the system and who holds it.

Operator Boundaries

Data visibility per operator role.

Fail-Closed

How TSN rejects before any token moves.