Your devices identify each other
Each account has public identity information that can be shared to protect messages. The matching private information stays on the device.
Inside Velixnet: keys, messages and trust.
These notes explain how VXN messaging works, what the delivery service can see, and which parts still need stronger testing. They describe the current Protocol V2 implementation—not a promise that any app can remove every risk.
Three parts of a private exchange.
Identity checks, message encryption and delivery have different jobs. A working connection alone does not prove you are talking to the intended person.
The message is locked on your device
Before upload, the app prepares protected message data using established encryption tools.
The service delivers protected message data
The delivery service checks routing information, queues the protected data, and makes it available to the intended recipient.
The building blocks behind VXN.
For readers who want the implementation details: the session protocol, message format, account identity and service responsibilities.
Protocol V2 cryptographic base
Active messages use vodozemac Olm sessions, identified as olm.v1.curve25519-aes-sha2. Curve25519 identity and one-time keys establish sessions; ratcheting advances message keys as the conversation continues. Recovery bundles use XChaCha20-Poly1305 separately—it is not the active V2 chat cipher.
Envelope format
An envelope contains Olm ciphertext—the encrypted message—and visible routing and session fields. The app checks those outer fields against account, saved identity, route and session state. This validation is not the same as cryptographic authentication: not all outer fields are bound as AEAD associated data.
Account identity
A Velix ID identifies your account without using a phone number or email address as the messaging identity. It is still an account identifier, not a guarantee of anonymity.
Delivery layer
The service manages accounts, public-key distribution, message queues, delivery acknowledgements, expiry and basic abuse controls. Its role is to deliver encrypted messages, not to maintain a readable conversation archive.
Where the protection stops.
Message integrity
Changed ciphertext, a wrong key or malformed message data should cause rejection. This checks the protected message; it does not establish whether its contents are truthful or safe to act on.
The device remains a trust boundary
Private keys and readable messages belong on the endpoints. End-to-end encryption cannot protect a conversation from someone who controls an unlocked or compromised device, or from a recipient who shares it.
Recovery needs care
Encrypted recovery and key-change handling are implemented. Restoring access must not silently turn a new or changed identity into a trusted one; re-verification remains part of that process.
Read the practical Recovery guide for lost phones, resets and the choice to continue without a backup.
Metadata still exists
The service processes account, sender and recipient IDs; message and client IDs; timing and approximate size; public identity/session fields; delivery state; and push-token associations. Network and abuse-control logs can also contain connection information. These records can reveal communication patterns even when message content is encrypted.
Verify the person you intend to contact
Comparing identity QR codes directly reduces reliance on the service's public-key response. It is an identity check between contacts, not a judgement about whether someone is trustworthy.
HTTPS is transport, not E2EE
HTTPS protects the connection to the website and service. End-to-end encryption is a separate layer that locks message content before delivery.
What supports these claims?
A sound design, working code and successful tests are different kinds of evidence. Using established encryption libraries does not automatically make the whole app secure.
Designed
Device-held keys, encrypted message content and a server delivery role define the intended trust boundaries. These design goals are not a security certification.
Implemented
The current V2 implementation includes Olm sessions, identity pinning, QR verification, protected local state and encrypted recovery. The checklist below describes these behaviours and their limits.
Internally tested
Project tests and recorded device checks cover session establishment, replies, ciphertext tampering, replay rejection and recovery. Coverage is incomplete; stronger device and failure-path testing is planned during closed testing.
Pending independent review
An independent security review is planned before wider release. It has not been completed, and the project does not claim independent audit approval or certification.
What is changing, and what is still planned.
Current limitations and the next testing priorities, separate from features that are not yet available.
V2 is the active protocol
Protocol V1 is retired from the active client and public messaging API. Older notes about per-message XChaCha encryption and separately wrapped message keys describe that earlier design, not today's Olm message path.
Reducing metadata
Reducing collection and retention remains ongoing work. The aim is to keep only what operation requires, without presenting that aim as a completed guarantee. See what the service currently sees and the privacy policy for data-handling details.
Temporary memory clearing
Selected recovery, legacy-compatibility and cryptographic buffers are explicitly cleared after use. The current code does not prove that every temporary key or plaintext copy across C++, Rust, Qt and operating-system memory is securely erased. This memory-handling limitation is separate from deleting saved messages.
Future deletion and Vault tools
A dedicated secret-message deletion tool and the Vault feature are roadmap items. They are not implemented and are not claimed as current Protocol V2 features. Normal server delivery acknowledgement and retention behaviour should not be described as guaranteed secure deletion from every device, log or backup.
Implemented; stronger closed testing planned
The planned Google Play closed test will give particular attention to four implemented areas: consistent sender/recipient IDs; saving outgoing messages before sending; saving received messages and session state before acknowledging delivery; and V2 QR identity verification. These need stronger evidence on real devices and when operations fail.
Operational evidence
Historical snapshot recorded on 10 September 2026—not a live status display or an availability guarantee.
- Linux host: more than a month of uninterrupted runtime.
- Operator-reported availability: 99.9%. A measurement period and independent monitoring record are not provided here.
- VXN panel certificate status: valid, with 36 days remaining at verification.
- External SSL checks confirmed a matching hostname, trusted certificate chain, non-self-signed certificate, acceptable public key and no detected weak signature.
What is implemented, and what still needs verification.
Public implementation and release-status checklist, based on the source review of 10 September 2026. A checkmark means implemented or observed—not independently audited. An empty box marks incomplete work or evidence. Implementation ticks do not replace the further testing described above; dated service observations are snapshots.
| Implementation block | Status |
|---|---|
| 1. Device creates or loads protected identity keys. | Completed |
| 2. Client normalizes the sender and recipient IDs. | Completed |
| 3. Client fetches and validates the recipient public key and saved identity pin. | Completed |
| 4. Client creates fresh message encryption or advances the ratchet session. | Completed |
| 5. Client encrypts the plaintext locally with authenticated encryption. | Completed |
| 6. Client validates outer protocol, sender, recipient and client fields against account, route, identity-pin and session state; these fields are not all cryptographically bound as AAD. | Implemented as validation, not cryptographic AAD |
| 7. Protocol V2 derives and advances message keys inside the Olm ratchet; the sender stores its protected local history. | Completed using the Protocol V2 design |
| 8. Client explicitly clears selected temporary cryptographic buffers; comprehensive clearing of every language and platform copy is not claimed. | Partially implemented |
| 9. Client validates envelope fields, sizes, encoding and UTF-8 boundaries. | Completed |
| 10. Client commits outbound ciphertext locally before network delivery. | Completed |
| Implementation block | Status |
|---|---|
| 11. Client sends the opaque envelope to the API over HTTPS. | Completed |
| 12. Public site and API are live over HTTPS. | Completed |
| 13. Certificate validity and external SSL checks were recorded on 10 September 2026; see the operational snapshot above. | Verified |
| 14. On 10 September 2026, the Linux host showed more than a month of uninterrupted runtime; the operator reported 99.9% availability. | Operator evidence supplied |
| 15. Server validates routing metadata without decrypting the message body. | Completed |
| 16. Server stores and queues the encrypted envelope for the intended recipient. | Completed |
| 17. Recipient client validates, decrypts and checks replay state locally. | Completed |
| 18. Recipient commits local plaintext/session state before acknowledging delivery. | Completed |
| 19. QR verification is available for direct contact identity checks. | Completed |
| 20. Recovery and key changes require deliberate state handling and re-verification rather than silent trust changes. | Completed |
| 21. Message content is encrypted. The service processes account, routing, timing, size, delivery, push and connection metadata. Reducing its collection and retention remains an ongoing task. | Metadata minimization remains ongoing |
More privacy for your connection.
A trusted VPN can add a layer of network privacy. When VXN traffic passes through it, the delivery service sees the VPN server’s IP address instead of your usual home or mobile address.
Your messages still rely on VXN’s end-to-end encryption. The service can still recognize your account and delivery activity, and you must trust the VPN provider with connection information. Check that the VPN covers the VXN app before relying on it.
Explore the network guideFrom the sender's message to the recipient's device.
This is the active Velixnet flow. Message content is protected on the endpoints, while the delivery service handles the limited visible information required to route the encrypted envelope.
Sender device
The sender writes a message. Private identity keys and protected Olm session state remain on the device.
Identity and session check
The app verifies the recipient's public identity against its saved pin, then creates or restores the Olm session.
Local Olm encryption
Olm encrypts and authenticates the message and advances the ratchet. The app saves updated state and pending ciphertext before sending.
V2 envelope over HTTPS
The app sends opaque Olm ciphertext plus required routing and session metadata over HTTPS.
VXN delivery service
VXN authenticates the sender, validates routing and queues the protected envelope. The server holds no Olm decryption key.
Recipient device
The recipient validates identity, session and replay state, decrypts locally, saves the message and updated state, then acknowledges delivery.
Content boundary: the server sees necessary delivery metadata and opaque ciphertext, not the readable message content handled by the sender and recipient devices.