> ## 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. # TSN Threat Model: Adversary Classes and Guarantees > TSN adversary classes: compromised Receiver, Node, Cranker, network observer, malicious sender or recipient. What each can achieve and what stays protected. 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. ## Related pages The 11 protocol invariants that must always hold. Every key in the system and who holds it. Data visibility per operator role. How TSN rejects before any token moves.