Features Technology Compare Pricing
Gaming & eSports
Privacy
Communities
Blog Download
Trust

Where our claims come from.

Every meaningful, contestable claim on this site has a source. Performance numbers come from documented measurements; crypto names point to the public RFCs and standards we implement; competitor cells link to the docs or community threads we read to write them. The Voidcom server and client are not open-source today — where a claim is about our own implementation, we say so and link to our engineering blog instead.

Last reviewed:

Why we publish this

The discrepancy between what a marketing page says and what the product actually does is usually invisible to visitors. We'd rather make it impossible for ourselves to slip — every entry below names where the claim appears on the site, and what we'd cite if someone disputed it. If a claim turns out to be wrong, we change it here and on the page where it lives, in the same change.

Performance claims

All RAM and startup numbers shown on the site come from real measurements on the same Windows 11 machine, not synthetic benchmarks.

  1. ~170 MB idle RAM (Voidcom) vs ~560 MB (Discord)

    On the site: PerformanceFeature on /, /technology, /use-cases/gaming

  2. ~3× less memory than Discord

    On the site: PerformanceFeature ratio callout

    Headline uses the conservative idle row (3.2×). Voice-connected ratio is 2.8×; voice + webcam is 2.4×; both are documented in the methodology table.

  3. 5 ms audio frames (Esports preset)

    On the site: VoiceFeature, FeatureCards, /features/voice

    The 5 ms figure is the Esports preset only. Default preset is 20 ms. The site qualifies the claim wherever the number appears.

Cryptography

Every algorithm and standard we name on the site is implemented in voidcom_crypto and used by the server. The links below point to the canonical specification.

  1. Hybrid X25519 + ML-KEM-768 key exchange (XWing combiner)

    On the site: TechnologyCards, /features/security, /safety, /privacy

    DM and voice both use AWS LC's HPKE primitive with the ML_KEM_768_X25519 ciphersuite (the XWing combiner). One audited cryptographic core is shared between DM channel-key wrap, per-recipient file-key wrap, and MLS voice keying — replacing earlier custom combiner code.

  2. MLS 1.0 (RFC 9420) for voice group keying

    On the site: ComparisonTable, /features/security, /faq, /privacy, /compare, /use-cases/privacy, /blog/voice-mls-pq

    Voice channels with up to 99 participants and DM voice are keyed by MLS — the same protocol family Discord DAVE, Wire, and Element use. The voice gateway acts as MLS Delivery Service and sole authorized External Sender, mirroring the DAVE architecture. We chose the ML_KEM_768_X25519 ciphersuite (XWing) where DAVE uses classical P-256.

  3. AWS LC HPKE primitive (FIPS 140-3 validated) for DM and voice

    On the site: TechnologyCards, /features/security, StackTable

    AWS LC provides the audited cryptographic core for both DM channel-key wrap and MLS voice keying. The post-quantum hybrid HPKE (ML-KEM-768 + X25519) is the same primitive across all PQ-resistant key exchanges in Voidcom.

  4. XChaCha20-Poly1305 AEAD for message and voice frame payloads

    On the site: /features/security, TechnologyCards, StackTable

    Voice frames are AEAD-encrypted with a per-epoch key exported from the MLS group state. DM messages are AEAD-encrypted with the per-channel key delivered via AWS LC HPKE. The AEAD primitive is the same in both paths.

  5. Stage rooms (voice >99 participants) are server-mediated, not E2E

    On the site: ComparisonTable footnote, /features/security, /privacy, /faq

    Same posture Discord takes for Stage channels: DAVE applies to non-Stage voice only. Voidcom's Stage tier is clearly distinguished in the UI from regular voice channels (which remain E2E).

  6. Argon2id password hashing

    On the site: /features/security, /privacy

    OWASP-recommended parameters: 64 MB memory, 3 iterations, 4 lanes.

  7. BSI TR-02102-1 compliance for the post-quantum key exchange

    On the site: TechnologyCards "BSI TR-02102-1" tag

    TR-02102-1 lists hybrid X25519 + ML-KEM-768 as the recommended PQ-secure key agreement.

Architecture

Claims about how Voidcom is built — Rust core, QUIC SFU, EU-hosted persistent data. The Voidcom server and client are not open-source today, so the citations below point to public specifications and our own engineering blog rather than to the implementation. We're aware that means asking you to take our word for it on the parts that aren't externally verifiable; if and when we publish a third-party audit, it will land here first.

  1. gRPC signaling on tonic, QUIC voice/video on quinn

    On the site: TechnologyCards, /features/voice, /technology

    Our backend is a Rust server built on these two crates. The implementation itself is closed-source today.

  2. Voice/video uses an SFU (selective forwarding unit), not P2P

    On the site: ComparisonTable "Video / screen share" row, /features/video

    Single SFU process per region forwards packets between participants. Each sender uploads one stream — bandwidth scales linearly with senders, not with viewers, which is the architectural difference vs. TeamSpeak 6 today.

  3. Native desktop client — Flutter UI on a Rust core

    On the site: FeatureCards "Featherweight Client", TechnologyCards "Rust Core"

    The desktop client uses Flutter for the UI layer and calls into Rust libraries (audio, video, crypto) over FFI. The /blog/perf-methodology measurements verify the resource-usage outcome of that choice.

  4. Account data, messages, and files hosted in the EU

    On the site: BuiltForSection, PrivacyFeature, beta CTA badge

    Backend is designed to run across multiple EU providers in Germany (Hetzner, OVH, IONOS, Leaseweb) with cross-provider failover.

  5. Voice SFU regions shown on the world map

    On the site: /technology — SfuMap

    Status is tracked per region in our website data file: "online" today is EU only; "planned" markers (US, Canada, Japan, Singapore, Australia) are infrastructure we have committed to but have not deployed yet.

Competitor claims

Every cell in the comparison table on /compare reflects what each competitor publicly advertises or documents on their own site or community forum, last reviewed on the date above.

  1. Discord uses DAVE for E2E voice and video; mandatory since 2 March 2026

    On the site: ComparisonTable, /use-cases/privacy, /blog/welcome

    Discord text DMs are still not E2E encrypted.

  2. Discord free voice channels are capped at 96 kbps

    On the site: ComparisonTable "Voice quality presets"

  3. Discord free file upload limit: 10 MB

    On the site: ComparisonTable "File sharing"

  4. TeamSpeak 6 has opt-in per-chat E2E encryption (DMs only, not voice)

    On the site: ComparisonTable, /use-cases/privacy, /blog/welcome

    TeamSpeak 6's voice is still transport-only AES — the encrypt-chat feature only protects the selected DM/group conversation.

  5. TeamSpeak 6 video / screen share is P2P only — no server-side SFU yet

    On the site: ComparisonTable "Video / screen share"

  6. TeamSpeak ships file sharing

    On the site: ComparisonTable "File sharing"

  7. Mumble uses TLS for control + AES-OCB / AES-GCM over UDP for audio (not E2E)

    On the site: ComparisonTable, /use-cases/privacy

    The server can decrypt audio. There is no E2E mode for voice; file sharing and video are also not built in.

Found a wrong claim?

If something on the site reads off, doesn't match the source, or doesn't match the code — please tell us. Send a note to max@voidcom.app with the page and the issue. We'll fix it and credit you in the next change to this page.