$CHAIN Auction
A message addressed to the same destination every day, for a year, produces a trail. Anyone observing the routing layer sees traffic accumulating against that destination identifier, and the traffic pattern reveals the activity level, the regular correspondents, and the general shape of the account's usage. Encryption hides the content. It does not hide that the account exists, is active, and is receiving messages. This is the core of metadata surveillance.
Stealth addresses solve this by giving every incoming message a fresh, unique, one-time destination. No two messages arrive at the same observable address, even if they are for the same recipient. Only the recipient can recognize which stealth addresses are theirs, by running a cryptographic check against their private key. For anyone else, the stealth addresses look like unrelated random identifiers scattered across the network.
The construction was popularized by the Monero cryptocurrency as a way to give every transaction a unique output address. Zentalk applies the same mathematics to messaging, turning recipient unlinkability into a default property of every message delivered through the network.
Why addresses leak
A classical routing address is stable. A user publishes one address, contacts use it repeatedly, and the routing layer sees every message destined for that address converge on the same identifier. The identifier becomes a persistent pseudonym — unreadable to the casual observer, but trivially trackable by an infrastructure observer who can count how many packets arrive at it and from where.
The pseudonym is the leak. An adversary does not need to know who the real recipient is to track their activity. The adversary needs only the pseudonym, which is public by necessity, and watches traffic aggregate against it.
The construction
A stealth address is derived from the recipient's wallet-based identity public key plus a fresh ephemeral value provided by the sender. The recipient publishes a single public key once, long-term. The sender generates an ephemeral keypair for each message. The sender uses their ephemeral private key and the recipient's public key to derive a shared secret through Diffie-Hellman. That shared secret feeds a key-derivation function that produces the stealth address and the associated encryption key for the message.
Ephemeral Keypair:
Generated fresh for every message by the sender, used once, then discarded. The ephemeral public key is included with the message so the recipient can perform the matching computation.
The recipient, holding their long-term private key, can take any observed ephemeral public key, perform the same Diffie-Hellman, and derive the same stealth address. If the stealth address matches something in their inbox, the message is for them. If not, the message is for someone else.
Recipient Scan:
For each observed ephemeral public key in the routing stream, the client performs one elliptic-curve operation to derive a candidate stealth address and checks whether it has been delivered to. A few thousand messages per day means a few thousand scans — negligible load on modern hardware.
The elegant property is that only the holder of the long-term private key can perform the match. An observer, even with full visibility into every stealth address on the network, cannot determine which ones correspond to which long-term recipient. The linkability chain is cryptographically broken at the address layer.
Sender overhead
Not much, operationally. The sender performs a Diffie-Hellman and a KDF, both inexpensive, and produces a stealth address as part of composing each message. The ephemeral keypair is generated, used once, and discarded. The computation adds negligible latency and is invisible to the user.
The sender still knows the long-term public key of the recipient. What they do not know is how many other people are also sending messages to the same recipient, because none of those other messages appear at the same stealth address.
Network effects
From the network's perspective, every message is addressed to a different stealth address. Routing tables see a uniform distribution of destinations rather than a concentrated distribution around popular accounts. Storage allocation, shard placement, and validator workload distribute more evenly. The network cannot build heat-maps of popular recipients, because no recipient has a stable observable identifier.
Validator Blindness:
Validators route packets by stealth address, which is a well-formed destination identifier as far as the routing layer is concerned. Nothing about the construction requires validators to participate in the stealth-address logic; the math is entirely sender-side and recipient-side.
Cover traffic hides the existence of any particular message. Each layer addresses a different linkability vector, and stealth addresses specifically address the one that accumulates over time: the fact that a single pseudonym, used repeatedly, becomes a tracked identity even without name attribution.
Performance reality
Per-message cost: one elliptic-curve Diffie-Hellman, one KDF on the sender, and a matching pair on the recipient. Both operations complete in sub-millisecond time on modern hardware. The bandwidth overhead is negligible — an additional 32-byte ephemeral public key per message. No part of the construction scales with the volume of historical traffic, so the cost remains constant regardless of how long the account has been active.
Known limits
Stealth addresses do not hide the fact that a message exists on the network. An observer sees traffic flowing, unable to attribute it to specific accounts, but aware that the network is carrying traffic. Combined with cover traffic, this becomes harder to exploit, but it is not eliminated.
They do not hide the sender if the routing layer is single-hop. The routing addresses sender-unlinkability at the routing layer separately. The outermost packet still has to have a source address on the wire. Sealed-sender and onion-routing layers address that separately. They do not retroactively hide addresses published before the construction was enabled. Fresh identities generated under the stealth-address system are clean from the start.
Default behavior
Stealth addresses are the default, not an opt-in. A Zentalk user's public key is meant to be shared; the stealth-address derivation happens automatically for every message exchange. The user does not configure anything, toggle any setting, or choose any mode. The unlinkability is structural.
That is the design principle that runs through the entire Zentalk threat model: privacy that requires user effort is privacy for enthusiasts. Privacy that is the default is privacy for everyone.
Thanks & Best Regards Zentachain Team!
