Technology
How Verus is built, and what it can be checked against
Nobody should need to know what X25519 is to want a private messenger, which is why none of this is on the homepage. It is all here instead, in one place, with the parts that are not built named as not built and the central claim readable live from the running server rather than taken on trust.
Four things on this page can be checked without believing anything written on it. The deployment schema is read from the live server by your own browser. The verifier checks a real identity claim the same way. The security page attributes every certification to the organisation that actually holds it. And the state of the build below separates what runs today from what has merely been started.
The cryptography
Standard constructions, used the way they are meant to be used. There is nothing invented here, which is deliberate: a new primitive in a messenger is a liability rather than a feature.
| Component | Standard | Purpose |
|---|---|---|
| Key exchange | X25519 ECDH, RFC 7748 | Session key establishment with forward secrecy |
| Symmetric encryption | AES-256-GCM, NIST FIPS 197 | Message content and file encryption |
| Message protocol | Signal protocol, Double Ratchet | Forward secrecy and break in recovery |
| Digital signatures | Ed25519, RFC 8032 | Identity claims, key publication, VCode integrity |
| Integrity | HMAC-SHA256, RFC 2104 | Message and metadata integrity |
| Device keys, iOS | Secure Enclave | Hardware backed key protection, biometric binding |
| Device keys, Android | StrongBox, Android 9 and later | Hardware security module key storage |
Why an address is twenty four characters
An address is a fingerprint of a key, and its length is the only thing stopping somebody manufacturing a different key that matches it. The times below are for the entire Bitcoin network working on nothing else. Every character removed halves them.
| Length | To forge one | Verdict |
|---|---|---|
| 16 | 20 minutes | Broken |
| 20 | 50 years | A state could plan for it |
| 24 | 53 million years | What Verus uses |
Nobody should ever type one. Scan a code, send a link, and call people whatever you like once they are in.
What is held, and what is never held
The interesting column is the third one. A message nobody can read is a solved problem; a record of who sent it, to whom, and when is the part almost every platform still keeps, and the part a court order actually reaches.
| Layer | Held | Never held |
|---|---|---|
| Anonymous account | Public key only | Name, phone number, email address |
| Device trust | Attestation certificate hash | Device contents or usage logs |
| Attestation | Signed claim token | Biometric data, which stays on the device |
| Verified identity | Only the attributes chosen | Any attribute not chosen to share |
| Messages | Ciphertext, until collected | Content, or which account sent it |
Read from the running deployment, not from this page
A claim about what a database does not contain is checkable, so it is published as something you can check. What follows is fetched by your own browser from api.verusapp.co.uk/v1/deployment, which is open, needs no account and carries the headers that let any page call it. This site is not in the path and never learns that you looked.
Reading the live deployment…
That endpoint is open, carries CORS headers and needs no key, so you can call it from your own page. It is documented, with the other two open routes and how a signed request is formed, on the developer page.
The mechanism that derives that answer from the live schema, so the claim withdraws itself the moment it stops being true, is the subject of the first of fifteen United Kingdom patent applications in one family. The other four carry it into the parts of a messenger that would otherwise have to keep a record with somebody's name on it: enforcing that list rather than only reporting it, letting an app refuse to send what a server could keep, metering calls without a record that a call was made, and taking an abuse report without learning who made it.
Deployment
Your organisation can deploy Verus in three ways, depending on how much control it needs. Every option runs the same software with the same encryption. None of them keeps a record of who talks to whom.
Shared cloud
We host and operate Verus for you on our managed service, with data held in the UK and a live copy in the EU. There are no servers to run on your side.
Dedicated cloud
A deployment of your own in your organisation's cloud account, under your control. Your keys and your region, shared with nobody else.
Sovereign
The whole system on servers you own, in the jurisdiction you choose, with full data sovereignty. It does not depend on us to keep running.
Where the managed service runs and which certifications cover that infrastructure are set out on the security and compliance page, each attributed to whoever holds it. Verus does not yet hold an ISO 27001 certificate or a SOC 2 report of its own. A penetration test is still to come.
What is built, and what is not
Four states rather than two, because "running" and "not built yet" put software that exists and runs on real handsets in the same box as software nobody has started. Anything not in the first group is not on the homepage.
Running today
In the live deployment, exercised from the apps.
- Anonymous addressesCreated on the device, burnt on request, and deleted after thirty idle days.
- Confrmo verificationA real signed claim against a real relying party credential, expiring and revocable.
- Contact requestsAllow, decline or block, with a local name that is never transmitted.
- Messaging across devicesEncrypted separately for each device, delivered on a held connection.
- GroupsClient side, fanned out over pairwise sessions. The relay never sees a group.
- Disappearing messagesPer conversation. The timer travels inside the ciphertext.
- On device translationIn twenty languages, with the original kept beside it if you want it.
- Screen protectionScreen recording and mirroring are blocked. iOS gives no way to stop a screenshot, so one is detected and the sender told; Android refuses outright.
- AttachmentsEncrypted before upload, and only from people who have identified themselves.
- Lock screen notificationsAn empty push wakes the app, from Apple on iPhone and Mac and from Google Firebase on Android. The message is then fetched and opened on the device.
- Block and reportReports carry evidence the reporter chooses, not the conversation.
Built, not publicly distributed
Software that exists and runs. It is not in a store yet, so it is not something you can download here. The Mac and Android have left this list and are on the download page.
- iPhoneSwiftUI, no third party dependencies. Runs on handsets and against the live deployment, and is with Apple for review.
- Voice callsProven on real phones in both directions, iPhone to Android and back, sealed end to end and carried by a Verus Relay, so neither phone learns where the other is. Reaching each app with its next update. Video calls are coming soon.
- WindowsElectron against the JavaScript implementation of the protocol, not a port of the Apple code. It runs, it holds an account and it messages the same deployment. It is not released because it has no code signing certificate yet, and an unsigned installer is one Windows tells people not to run.
In development
Started, incomplete, and named here rather than implied by a feature list.
- Proofmarks in a conversationBuilt on this side, waiting on Confrmo to disclose them to a relying party.
Roadmap
Not started. Listed so that nothing above has to be read as a promise.
- Lokka document layerSpecified, not built.
- Key transparency logNot built. The threat model says what that leaves open.
- Group membership agreementGroups have no cryptographic membership agreement yet. Recorded as T-11.
iPhone
Built and running · With Apple for review
SwiftUI and CryptoKit, no third party dependencies. Keys are held on the device, recording and mirroring are blocked, and a screenshot, which iOS gives no application a way to prevent, is detected and reported to the other person.
Mac
Built and running · Download it
The same code as the phone rather than a second implementation, so a conversation can move between a laptop and a handset without either side being a different product.
Android
Built and running · Get it on Google Play
Kotlin, with the ratchet, X3DH and request signing written against the same constants as the reference implementation rather than against a description of it.
Windows
Early release · Download for Windows
A separate build against the same protocol rather than a port of the phone, written in JavaScript against the same constants as the reference implementation. It holds its own keys and talks to the same deployment. Its signing certificate is pending, so Windows warns before it opens: how to get past that, and how to check the file is ours, is on the download page.
Where this sits
Verus has a place of its own: anonymous by default, provable when it matters and able to run on infrastructure you control.
Consumer messaging at enormous scale, tied to a phone number.
Signal
Privacy first consumer messaging, tied to a phone number.
Wire
Secure collaboration for an organisation, administered centrally.
Verus
Anonymous by default, with an identity you can prove when it matters and take off when it does not, on infrastructure you can run yourself.
| Platform | End to end encrypted | No phone number | Verified identity | Metadata control | Sovereign | Documents |
|---|---|---|---|---|---|---|
| Verus | Yes | Yes | Confrmo | Yes | Yes | Lokka |
| Signal | Yes | No | No | Partial | No | No |
| Yes | No | No | No | No | No | |
| Wire Enterprise | Yes | Yes | Limited | Partial | Partial | No |
| Element, Matrix | Yes | Yes | No | Partial | Yes | No |
Assessed against publicly available documentation. Last reviewed August 2026. User counts are deliberately left out: they date quickly and they are not our measurement to publish.
Do not take our word for it
Check a claim against the deployment that issued it
The verifier calls the running server from your browser, so this site never learns which claims are checked. It separates live, expired, revoked, forged and unknown rather than answering yes or no, because a revoked claim still has a valid signature and a verifier that cannot tell you so is not telling you much.