> ## Documentation Index > Fetch the complete documentation index at: https://sdk.umbraprivacy.com/llms.txt > Use this file to discover all available pages before exploring further. # Privacy Analysis > 3-tier privacy model: ETA → ETA (strongest), mixed flows (partial), ATA → ATA (weakest). Covers timing analysis, amount correlation, anonymity set sizing, and self-burnable vs receiver-burnable trade-offs. ## Summary The Stealth Pool's privacy strength is determined by three independent choices: where tokens come from (ATA or ETA), where they land (ATA or ETA), and who controls the burn (self-burnable or receiver-burnable). * Shielding both ends (ETA → ETA) eliminates amount correlation entirely and makes the sender completely unlinkable at burn time — the strongest possible configuration. * Shielding one end (mixed flows) partially limits what an observer can correlate, depending on which side is visible. * Public flows (ATA → ATA) expose amounts at both ends; the only remaining privacy property is the absence of a direct on-chain link between the two addresses. * Receiver-burnable notes are cryptographically equivalent to self-burnable notes with the same source and destination, but are stronger in practice — recipients naturally burn later and independently, widening the anonymity set without any deliberate effort. For a complete breakdown of all eight combinations see the [Privacy Ranking](#privacy-ranking) below. *** ## How to read this page Every Stealth Pool flow has two independent axes that determine its privacy profile: * **Source** — where the tokens come from: an `AssociatedTokenAccount (ATA)` or an `EncryptedTokenAccount (ETA)`. * **Destination** — where the tokens land after the note is burnt: an ATA or an ETA. * **Unlocker** — whether the sender (self-burnable) or the recipient (receiver-burnable) controls the burn. Writing a note from an ETA hides the deposited amount — no observer can see how much entered the pool. Burning into an ETA hides the released amount — no observer can see how much left the pool. When both ends are shielded, amounts cannot be correlated at all, and the sender is completely unlinkable at burn time. ### Self-burnable vs receiver-burnable Cryptographically, self-burnable and receiver-burnable notes with the same source and destination are equivalent — the same information is visible or hidden on-chain in both cases. The practical difference is behavioural. A sender burning their own note tends to do so relatively promptly. A recipient, acting independently, will typically burn at a time of their own choosing — often much later, and without coordination. This natural timing gap widens the anonymity set and makes temporal correlation significantly harder. Receiver-burnable is therefore the stronger choice — but only when the recipient is fully registered (see [Writing notes — registration prerequisites](/sdk/mixer/creating-utxos)). Each of the eight combinations below is assessed on: * **Visible on-chain** — what any observer can read from the chain. * **Hidden** — what an observer cannot determine. * **Timing risk** — how susceptible the flow is to correlation by time. * **Best for** — the use case this combination suits. *** ## Privacy Ranking Pairs share the same cryptographic strength. Within each pair, receiver-burnable is stronger in practice due to natural timing behaviour. * **Tier 1** — ETA → ETA (both ends shielded, no amounts observable) * ETA → receiver-burnable → ETA. * ETA → self-burnable → ETA. * **Tier 2** — Mixed (one end shielded) * ETA → receiver-burnable → ATA *(not yet shipped in V18 SDK; on-chain only)*. * ETA → self-burnable → ATA. * ATA → receiver-burnable → ETA. * ATA → self-burnable → ETA. * **Tier 3** — ATA → ATA (both ends public) * ATA → receiver-burnable → ATA *(not yet shipped in V18 SDK)*. * ATA → self-burnable → ATA. *** ## Tier 1 — ETA → ETA Both the write and the burn are shielded. No amounts are visible at either end. ### ETA → receiver-burnable → ETA The strongest possible flow. No amounts are visible at either end, and the exit happens entirely on the recipient's timeline. * **Visible on-chain** — a note commitment was inserted into the tree; a nullifier was burnt at some later time. * **Hidden** — the written amount, the released amount, the sender's identity, the recipient's identity, and any temporal relationship between the two events. * **Timing risk** — minimal. No amounts are observable at either end. The recipient burns at a time of their choosing with no signal from the sender. * **Best for** — anonymous payments to a fully registered recipient where maximum privacy is required for both parties. ### ETA → self-burnable → ETA Cryptographically identical to the receiver-burnable variant. The same party controls both events, so the timing gap is down to the sender's own discipline. * **Visible on-chain** — note commitment was inserted; nullifier was burnt. * **Hidden** — written amount, released amount, link between the two events. * **Timing risk** — low. Amounts cannot be correlated. The sender controls burn timing and can delay it to widen the anonymity set, though this requires deliberate effort rather than happening naturally. * **Best for** — moving your own funds through the pool with no on-chain amount trail at either end. *** ## Tier 2 — Mixed One side is visible, one is hidden. Amounts can be partially observed but not fully correlated across the pool boundary. ### ETA → self-burnable → ATA The write is hidden but the burn exits publicly. No amount is visible at entry, so the visible exit cannot be tied back to any specific note with certainty. * **Visible on-chain** — burned amount and destination ATA at burn time. * **Hidden** — written amount and any quantitative link from the burn back to the write. * **Timing risk** — medium. The burn amount is visible but no matching write amount can be observed. Same party controls both events, so timing correlation is possible if you burn promptly after writing. * **Best for** — surfacing funds into a public wallet where hiding the deposit amount matters more than hiding the exit. ### ATA → receiver-burnable → ETA The write is public but the burn is hidden. An observer can see who wrote and how much, but the burn produces no visible exit. The recipient acts independently. * **Visible on-chain** — written amount and the writing ATA at note-write time. * **Hidden** — burned amount, burn destination, link from the visible write to the eventual burn. * **Timing risk** — low-medium. The exit is invisible, so even though the write is known, there is no observable burn event to correlate it against. The recipient controls timing. * **Best for** — scenarios where the sender's identity is not sensitive but the recipient's privacy must be protected. ### ATA → self-burnable → ETA Cryptographically identical to the receiver-burnable variant; the same party controls both events. * **Visible on-chain** — written amount and writing ATA at note-write time. * **Hidden** — burned amount and destination. * **Timing risk** — medium. The write is fully visible. The exit leaves no trace, but the sender burning their own note may do so close to the write time. * **Best for** — moving funds into a private ETA from a known public wallet, where the source is not sensitive but the destination must be hidden. *** ## Tier 3 — ATA → ATA Both ends are public. Amounts are fully observable at write and burn. The only privacy property is the absence of a direct on-chain link. ### ATA → self-burnable → ATA The weakest flow. Both events are fully visible and the same party controls both, making timing and amount correlation straightforward. * **Visible on-chain** — written amount, writing ATA, burned amount, destination ATA. * **Hidden** — the direct on-chain link between the two addresses; a ZK proof still prevents anyone from proving which write maps to which burn without the secret inputs. * **Timing risk** — high. Amounts are visible at both ends. Matching equal amounts written and burnt within a short window is easy when the anonymity set is small. * **Best for** — the minimum viable case where address unlinking is the only goal and amount / timing privacy are not a concern. Use round, pool-common amounts to maximise the anonymity set.