1) What can be deanonymized?

• Linkable addresses: funding patterns & transfers correlate EOAs together.
• MEV & mempool leaks: pending txs reveal action before inclusion.
• Off-chain metadata: IP address / RPC provider logs, wallet analytics, device IDs.
• App-level IDs: referral codes, account linking in dapps, email/ENS reuse.

2) Mixers & Pool-based Privacy

Mixers (a.k.a. tumblers) create an anonymity set by pooling deposits and later allowing withdrawals
to unrelated addresses. Modern designs use zero-knowledge proofs to prove ownership without
revealing which note was deposited.

• How it works: deposit → receive note/commitment → prove knowledge → withdraw elsewhere.
• Limits: size and freshness of the anonymity set; on-ramp/off-ramp clustering; sanction risk.
• Mitigations: wait time between deposit/withdrawal, relayers for gas, diversified denominations.

3) Stealth Addresses & One-time Keys

With stealth addresses, the receiver advertises a public viewing key; the sender derives a unique
one-time address using Diffie-Hellman-like tricks. Funds land in an address that only the receiver can scan
and spend, but outsiders can’t link payments to the receiver’s identity.

• Great for donations, payroll, NFT airdrops where recipients don’t want balance linkage.
• Needs wallet support for scanning and spending from derived addresses.
• Pairs nicely with account-abstraction & paymasters to hide funding patterns.

4) ZK Proofs & Private Payments

ZK systems (zk-SNARKs/zk-STARKs) let you prove “I have valid funds and I sent them” without
revealing who sent what to whom. Examples include shielded pools and privacy-enabled L2s.

• Benefits: strong privacy with on-chain verification; programmable privacy (selective reveal).
• Costs: proving time, gas costs, trusted set-ups (for some SNARKs), UX complexity.
• Design tips: consider viewing keys, auditability hooks, rate limits for Sybil resistance.

5) Metadata Hygiene (what most users miss)

• Prefer RPCs that support privacy / MEV-protection and avoid logging IP ↔ address mappings.
• Avoid address reuse; rotate EOAs and label them by purpose (trading, salary, cold storage).
• Don’t reuse ENS names, emails, or socials across “clean” and “private” personas.
• Use session keys / smart accounts for dapps; hide funding with paymasters.
• Beware of analytics/telemetry in mobile wallets and browser extensions.

6) Compliance: Sanctions, KYC walls & “Responsible Privacy”

Teams can ship privacy while respecting rules:

• Blocklists / allowlists: restrict UI usage for sanctioned addresses while keeping contracts neutral.
• Selective disclosure: viewing keys or audit keys for voluntary proofs to banks / exchanges.
• Rate limits / spending limits: reduce mixer abuse while preserving everyday privacy.
• Jurisdictional notices: warn users about local restrictions; collect no more data than necessary.

Further resources

• Cyfrin Updraft  security & advanced smart contract tracks (great for serious builders).
• Ethereum.org  Privacy  ecosystem overview.
• Chainlink Education  oracle best practices (critical for privacy-aware DeFi).
• Zcash Technology  shielded transactions, viewing keys, audits.
• Penumbra / private DeFi docs  ZK design patterns for DEX/DeFi.
• Trail of Bits Blog  practical security write-ups.