$CHAIN Auction
A group with five hundred members is a surveillance target. Every message a sender re-encrypts five hundred times leaves five hundred routing records, five hundred timing signals, and five hundred opportunities for a passive observer to map the group's membership — all without cracking a single cipher. The metadata leaks before the content ever does.
Encrypting a message between two people is a problem the cryptographic community solved two decades ago. Encrypting the same message to a thousand people at the same time, without leaking who is in the group, without the sender's phone having to re-encrypt the payload a thousand separate times, and without blowing up the network with duplicate ciphertexts, is a different problem. It is the problem that keeps end-to-end encryption mostly confined to small groups on most platforms, and the reason large communities live in plaintext or give up on privacy entirely.
Zentalk implements the Sender Key Protocol, an extension of the original Signal group design, adapted for a decentralized network. The short version: one symmetric key per sender per group, rotated after each membership change, delivered to every member through their existing pairwise sessions. The long version is the rest of this article.
The pairwise problem
The source of that metadata leak is the default architecture for group encryption: pairwise re-encryption. If Alice wants to send a message to a group of 500 people, her device establishes a separate end-to-end session with each of the 500, encrypts the message 500 times, and transmits 500 separate ciphertexts. It is correct. It is also unusable at scale. Battery, bandwidth, and latency all blow up as a function of group size.
Worse, the pattern leaks metadata. An adversary watching the network sees 500 encrypted deliveries originating from Alice's device within milliseconds of each other, to 500 distinct destinations. Even without decrypting anything, the adversary now knows Alice posted to a group, the group has at least 500 members, and a list of candidate recipients sits in the relay logs. Pairwise group messaging is a metadata broadcast.
The Sender Key idea
Sender Key replaces the per-message pairwise re-encryption with a symmetric key shared across the group. Each sender holds their own symmetric key — their Sender Key — and every group message that sender produces is encrypted once with that key and distributed to the group as a single ciphertext.
Sender Key Distribution:
The symmetric key is delivered to each group member privately, once, through the pairwise end-to-end session that already exists between sender and recipient. After delivery, group messaging costs O(1) per message rather than O(group size).
The key itself is not distributed through a broadcast. It is delivered to each group member privately, once, through the pairwise end-to-end session that already exists between sender and recipient. After delivery, group messaging shifts from pairwise to one-to-many: one encryption, one ciphertext, one network transmission, decryption performed locally by each recipient using the shared key they already have.
The cost model flips from O(group size) per message to O(1) per message, with a one-time O(group size) setup when the sender joins or the membership changes. For a group that exchanges thousands of messages over its lifetime, the savings are several orders of magnitude.
Forward secrecy
A shared symmetric key that never rotates would trade performance for weaker security. Zentalk preserves forward secrecy at the group level by running a hash-chain ratchet on the Sender Key itself. Each time a sender produces a new group message, the current Sender Key is derived from the previous one via a one-way KDF, and the previous key is discarded.
Hash-Chain Ratchet:
Every group message is encrypted under a key derived from — and replacing — the previous key. An attacker who captures the current key cannot derive any earlier key, because the derivation is one-way and prior keys have been deleted.
The result is that every group message is encrypted under a key that exists only for that message. An attacker who captures the current key of a sender cannot decrypt any prior group message from that sender, because the prior keys have been cryptographically forgotten. Compromise of a Sender Key at time T does not expose messages from before T.
Membership changes
Adding a member to a group requires distributing the current Sender Keys of every existing member to the new joiner. Removing a member is the harder case: the network cannot force the removed member to forget the keys they already have, so the only way to restore privacy is to rotate every Sender Key and redistribute to the remaining members.
Zentalk performs this rotation automatically on every remove event. The group interface shows someone leaving and the next message uses new keys. The removed member's client continues to receive ciphertexts on the channel until the rotation propagates, but those ciphertexts are encrypted under keys that client does not hold, cannot derive, and cannot forge. The exit takes effect at the speed of the key rotation, which is typically under a second.
What validators see
A group message on the Zentalk network is a single ciphertext with a routing header that identifies the group channel, not the membership list. Validators forward the ciphertext to the group's subscriber set using the same blind-relay mechanism that handles one-on-one messages. No validator observes who is in the group, how large the group is, or who originated the message.
The address-hashing and sealed-sender mechanisms extend to group messaging without modification. The group's identifier on the network is a hash. The member list is held only on subscribing clients. The sender's identity is sealed inside the payload, not on the envelope. From the validator's perspective, a one-on-one message and a group message are distinguishable only by the fact that more clients subscribe to the latter.
Scaling past the ceiling
Most mainstream end-to-end-encrypted messengers cap group size somewhere between 256 and 1024. The cap exists because the pairwise encryption model does not scale past it without unacceptable client performance. Cover traffic and stealth addresses address separate metadata vectors, but neither replaces the sender-key approach to group scale.. The ceiling reflects the architecture, not a privacy choice.
Sender Key removes the architectural bottleneck. Zentalk's group capacity is bounded by network delivery capacity and client storage, not by per-message encryption cost. In practice, groups of up to 1,000 members (confirmed on zentachain.io/faq) operate without the latency or battery penalties that traditional pairwise encryption imposes.
This matters for specific classes of community — decentralized organizations, open-source projects, activist networks, professional communities — that have historically had to choose between privacy and scale. Sender Key makes the choice unnecessary. The privacy guarantee is identical to the one-on-one case. The scale is limited only by how many people the community actually has.
Verify, do not trust
The Sender Key implementation in Zentalk follows the public Signal Protocol group specification with Zentalk-specific adaptations documented. The ratchet is testable. The key distribution is observable in the handshake traces. The rotation on membership change is measurable. You can audit the claims rather than take them on faith, which is the baseline expectation for any encryption system that asks you to trust it with a thousand conversations at once.
Thanks & Best Regards Zentachain Team!
