Monero subaddresses stop observers and honest payers from linking your payments, but every subaddress hangs off one view key and one seed.
Where the separation breaks:
- The 2019 Janus disclosure: an active, paid probe that only works if you confirm receipt off-chain.
- Consolidation sweeps that spend from several subaddresses in one transaction.
- Service account databases that already key your payouts to your login.
Carrot's Janus anchor stops the first one once it ships with FCMP++. It doesn't touch the other two.
The takeaway: if two roles must never be linked, the boundary is a separate seed, not a separate subaddress.
For anyone keeping roles apart: do you run separate wallets, or subaddresses with careful habits?
Full write-up: https://cryptodecentral.co.za/notes/monero-subaddress-is-not-a-separate-identity
The Zcash side has exactly the same property, which supports your conclusion. Sapling's diversified addresses are unlinkable payment addresses derived from a single spend key - observers and payers can't link them, but one seed signs for all of them. Unified Addresses add receiver-type choice (Orchard/Sapling/transparent) but still resolve to one spend authority, so the identity boundary stays at the key level, not the address level.
One nuance worth adding: Zcash made the view boundary cheap on purpose. Full and incoming viewing keys let an auditor or a wallet service see every transaction without spending power, which is what makes compliance-friendly accounting possible without burning privacy. Monero's analogous direction - Carrot's anchored key expansion and FCMP++ - moves view capability in a similar direction, though subaddress-level view separation still isn't the same thing as seed-level separation.
On the operational side: separate seeds genuinely solve the linking problem, but they multiply the backup burden and the sweep path. Moving value between two seeds is an on-chain event with its own privacy properties, so the boundary you draw has to survive your own future consolidations, not just the adversary's heuristics. In practice the rule I'd use: seed boundary per adversary (and per jurisdiction), subaddress or diversified address per counterparty.