Privacy Suite
Transaction Privacy

Complete Transaction Privacy

Multi-Layer Defense: DERO combines ring signatures, homomorphic encryption, bulletproofs, and TLS encryption. Even if one layer weakens, others protect your privacy.

How Privacy Layers Work Together

DERO's privacy is layered. Network encryption (TLS), anonymity-set membership, amount encryption, and zero-knowledge proofs each address a different observer and a different question. They are not four interchangeable locks against the same attack — they cover different surfaces.

📖

Naming note: "Ring signature" is the user-facing name DERO uses for what the source actually implements as an Anonymous Zether-style anonymity-set ZK proof (see cryptography/crypto/proof_generate.go and proof_verify.go). The user-facing term is colloquial; the construction is not a classical (Schnorr/LSAG/MLSAG) ring signature.

The Flow:

How They Interact:

When you send a transaction, each layer addresses a different observer at a different stage. Network encryption protects your traffic from ISPs. Anonymity-set membership hides which address sent the transaction. Homomorphic encryption keeps all amounts secret. Bulletproofs prove validity without revealing the underlying values — and, at the integrity layer, bulletproof soundness is the single cryptographic gate that prevents negative-transfer / wraparound mints. The privacy layers and the integrity gate are not "defense in depth" against the same attack; they cover different surfaces.

Source Code References:

  • Network: p2p/controller.go (TLS encryption)
  • Sender: cryptography/crypto/proof_verify.go (ring signatures)
  • Amount: cryptography/crypto/algebra_elgamal.go (homomorphic encryption)
  • Proofs: cryptography/crypto/proof_generate.go and cryptography/crypto/proof_innerproduct.go (range proof + inner product)

What Each Observer Sees

Understanding what different parties can and cannot see helps illustrate how DERO's privacy layers work together in practice.

ObserverCan SeeCannot SeeWhy Privacy Maintained
ISP/NetworkEncrypted traffic to DEROTransaction details, amounts, addressesTLS encryption hides content from passive observers. Caveat: the p2p layer uses tls.Config{InsecureSkipVerify: true} with self-signed certs (p2p/controller.go:398, cert at :551), so an active MITM (e.g., a hostile ISP that can intercept and present its own self-signed cert) is not defended against by TLS alone — the upstream code itself acknowledges this with the comment // NOTE: this does NOT protect from individual active man-in-the-middle attacks at p2p/controller.go:716.
BlockchainRing (2-128 members), encrypted commitmentsReal sender, actual amounts, balancesRing signatures + homomorphic encryption
ChainalysisTransaction patterns, metadataDefinitive sender, amounts, proof of sendingCannot prove specific sender identity
Bob (receiver)Amount, comment, sender positionAlice's balance, other transactionsOnly sees his own transaction details
Alice (sender)Everything (has private keys)-Controls own privacy through wallet

Real Transaction Example

Alice → Bob: 100 DERO

Balance: 500 DERO
Send: 100 DERO
To: Bob
Comment: "Coffee"

After send:
Balance: 400 DERO ✓

Privacy at Each Stage

StagePrivacy AddedSource Code
CreationLocal onlywalletapi/wallet_transfer.go:62
Ring FormationSender hidingcryptography/crypto/proof_generate.go
Encryption (ciphertext construction)Amount hidingcryptography/crypto/algebra_elgamal.go:44 (CommitElGamal)
Homomorphic addition (during balance update)Update encrypted balance without decryptingcryptography/crypto/algebra_elgamal.go:69 (Add)
ProofsZK validationcryptography/crypto/proof_generate.go + cryptography/crypto/proof_innerproduct.go
BroadcastNetwork encryptionp2p/controller.go:398 (TLS — self-signed, no client/server auth)
VerificationHomomorphic balance update applied to ciphertextsblockchain/transaction_execute.go:239 (nb.Balance.Add(echanges))

Key Takeaways

What's Protected:

  • Sender identity (hidden among ring_size/2 potential senders; naive guess probability is 1/(ring_size/2), e.g., 1/8 for ring size 16)
  • All amounts (encrypted with homomorphic encryption, never decrypted)
  • All balances (encrypted at all times)
  • Transaction linkage (unlinkable, independent rings per transaction)

What's Visible (Necessary for Function):

  • Transaction occurred (required for processing)
  • Ring member list (creates ambiguity, actually protects privacy)
  • Timing metadata (doesn't reveal transaction details)

DERO's Design: Privacy over third-party verification. Only you (with private keys) can prove you sent a transaction. Third parties cannot definitively prove sender identity—this is by design. Plausible deniability is a feature, not a bug.

⚠️

Remember: Privacy requires ambiguity. If you could prove to others you sent a transaction, your privacy would be broken. Plausible deniability is a feature, not a bug.

Related Pages

Privacy Technologies:

Understanding Transactions:

For Users: