Decoding DAVE: Discord's End-to-End Encryption for Voice and Video
What DAVE Is (and Is Not)
DAVE is not a wholesale replacement for Discord's voice and video stack. Instead, it functions as a cryptographic layer integrated into the existing pipeline. The underlying technologies, like WebRTC for encoding, transport, and congestion control, continue to operate as before. Discord's Selective Forwarding Units (SFUs) also remain in place to efficiently route media packets between participants.
The crucial change is that DAVE encrypts the already-encoded media frames before they leave a user's device. This encryption is end-to-end, meaning only other participants in the call possess the keys to decrypt it. It is essential to note the scope of this protection: DAVE currently secures audio and video media only. Text-based communication—including direct messages and server channel chats—is not end-to-end encrypted and remains visible to Discord's servers for moderation and operational purposes.
How DAVE Works: MLS and WebRTC Transforms
DAVE's design cleverly combines two established technologies. For the complex task of managing encryption keys within a dynamic group, it uses the Messaging Layer Security (MLS) protocol. When a call begins or a participant joins, the clients perform an MLS handshake to establish a shared cryptographic state. Each time someone joins or leaves, the protocol advances to a new "epoch," which rotates the encryption material. This process provides critical security properties: forward secrecy, which prevents new members from decrypting past call data, and post-leave security, which ensures departed members cannot access future communications.
The actual encryption of audio and video is handled by the WebRTC Encoded Transform API. This browser standard allows Discord to insert an encryption step after a media frame is encoded by the codec but before it is packaged into network packets. Conversely, decryption happens immediately after packets are received and before the frame is decoded.
Negotiating the Green Lock
The appearance of the green lock icon is not automatic; it is the result of a capability negotiation. DAVE is only enabled for a call if every single participant's client supports it. The voice gateway checks for this by looking at a max_dave_protocol_version field advertised by each client and selects the lowest common version. If all clients announce support, the call negotiates E2EE and the lock appears.
Transparency, Audits, and Intentional Limits
Discord has approached DAVE with a commendable level of transparency. The company has published a protocol whitepaper detailing the cryptographic design, released the core libdave library as open-source code, and commissioned independent third-party security audits from firms like Trail of Bits. These materials allow for public scrutiny and verification of the protocol's security claims.
What This Means for Developers and Bots
For developers interested in Discord's voice technology, DAVE introduces new constraints. Any tool or bot that previously relied on accessing audio packets from the voice gateway will fail to decode audio from a DAVE-protected call. To access the decrypted media, a client must fully implement the DAVE protocol stack: participate in the MLS group handshake, manage epoch changes, and perform the WebRTC encoded transforms.
The Bottom Line
DAVE successfully brings robust, standards-based end-to-end encryption to Discord's real-time audio and video calls. It is a meaningful privacy upgrade that protects the content of conversations from interception, including by Discord itself, without requiring an overhaul of the platform's proven media routing infrastructure. For developers and technically-inclined users, it is best understood as a carefully scoped cryptographic overlay.