Operalytix Not ready for high-risk use. Operalytix is pre-release software. Its code was written almost entirely by AI models, and it has not yet had an independent human security audit. Do not rely on it where a failure could put people at risk, for example to protect a source, an activist or anyone facing a well-resourced adversary, until an independent audit has been completed and published.
In short
- Messages, files and calls are end-to-end encrypted. Message keys combine a post-quantum and a classical algorithm.
- There is no phone number, e-mail address or account, and relays are reached through Tor.
- Servers can still learn some things, such as when mailboxes are used. We list them all below.
- Two internal, AI-assisted audits and a follow-up check found 204 issues. 148 are fixed and their fixes reviewed; the rest are being worked on.
- No independent human audit has been done yet. One is planned before version 1.0.
What is protected
Against relays, push services, network observers and Apple, which the design treats as possible adversaries:
- What you say. Messages, attachments and calls are end-to-end encrypted. Only the members of a chat can read them.
- Recorded today, broken later. Message keys are agreed with a post-quantum algorithm (ML-KEM-1024) and a classical one (P-384) together, so an attacker who records traffic now must break both. Calls are the exception (see the known limits).
- Who sent a message. Relays receive sealed envelopes of one fixed size, which do not show the sender or the kind of message.
- Who you are. There is no phone number, e-mail address or account. The app reaches relays through Tor, so relays and network observers do not see your IP address on message traffic.
- A seized relay. The reference relay keeps no accounts and no request logs; by default its data lives only in memory.
- A locked phone. The message database, keys and recovery phrase cannot be read from storage while the phone is locked. Notification previews are the exception if you turn them on.
Known limits
These are not bugs. They are limits of the current design, stated so nobody relies on more than the code provides.
Relays see mailbox activity
A relay sees which of its mailboxes are read and written, when, and how many envelopes a message takes. It can drop or delay traffic.
Calls use classical encryption
Call audio and video rely on WebRTC’s classical encryption (AES-128 inside DTLS-SRTP). They are not protected against a future quantum computer the way messages are.
Messages are not deniable
Every message is signed. Anyone you write to can prove to others that you wrote it, even after it has disappeared from your phone.
Fast call mode shows your IP address
Calls go through Tor by default. In fast mode, which you turn on yourself after a warning, the call server’s operator sees your IP address.
Push timing
Push is off by default. When on, the push gateway holds your push token, and it and Apple see when pushes arrive. In instant mode they can tell which push users share a chat.
When you use the app
Cover traffic runs only while the app runs, so an observer can still see when it is in use.
Your own phone and contacts
Nothing protects you from malware on an unlocked phone, or from a contact who takes screenshots.
Prebuilt components
The call engine (LiveKit WebRTC) and the Tor bridge component (IPtProxy) are prebuilt third-party binaries. They are pinned by checksum but not yet rebuilt from source.
The audits
Two internal security audits reviewed the code, followed by a re-check of every fix. They were carried out by AI models (Claude) working for the project, not by an independent firm.
The first two audits found 179 issues; the re-check of their fixes found 25 more. Of the 25 issues rated high severity, 19 are fixed and reviewed and 6 are only partly fixed.
The 43 open items include 5 that were deferred on purpose (described below). The rest are partly fixed issues where some risk remains, and one newer issue still open. They are being worked on. We do not publish technical details of open weaknesses until they are fixed.
An internal AI-assisted audit is not a substitute for an independent one. It can miss whole classes of problems, and the same kind of model that wrote the code also reviewed it.
AI-written code
Almost all of Operalytix, including its cryptography, was written by AI models: first MiMo, then Claude agents. The maintainers treat that code as untrusted.
The project’s rules require a signed, line-by-line human review of every change to security-critical code before a release, and an independent audit before version 1.0. Those reviews have not been signed yet, so the release checks currently refuse to ship a release.
Deferred on purpose
Five items are deliberately left for later, in three groups, because they need a larger rebuild or a product decision:
- Call encryption. Call media relies on WebRTC’s classical encryption, with 128-bit keys. Moving beyond that needs the call engine to be rebuilt from source, which also covers the next point.
- The prebuilt call engine. All call cryptography comes from LiveKit’s prebuilt WebRTC library. It is pinned by checksum and its remaining trust is documented, but it has not been rebuilt independently.
- Deniability. Messages are not deniable. The MLS standard has no deniable mode, and changing this needs a product decision and cryptographic review.
Still being worked on
At a high level, the open and partly fixed items concern:
- how much relays and network observers can infer from traffic patterns, such as timing and message sizes;
- detecting misbehaving relays and group members, and limiting how much a single bad actor can disrupt;
- handling a stolen or cloned device and its keys;
- privacy details in notifications, call logs and abuse reports;
- release signing, review records and reproducible builds.
Before version 1.0
- An independent, human security audit, with the results published.
- Signed line-by-line human reviews of all security-critical code.
- Production signing keys and a signed release.
- A public source repository.
- Relays and call servers run by independent operators.
Report a vulnerability
Please e-mail contact@operalytix.com with “Security” in the subject, and never open a public issue for a vulnerability. Include the affected component and version, steps to reproduce, and the impact.
We aim to acknowledge reports within 3 business days, give a first assessment within 10, and fix within 90 days, sooner for critical issues. Good-faith research that follows this policy will not be pursued legally. Any claim on this site or in the app that promises more than the code provides is in scope too.
Based on the project’s final internal audit report of 2 November 2026.