How it works

Two claims are worth checking on any site that promises privacy: what it keeps, and what it can read. Here are both, without the marketing.

The door: a signature you check yourself

When you open a room you write down one address. Nothing is created anywhere — the address goes into the part of the URL after the #, which browsers are required never to send to a server. You then sign a short off-chain message, and that signed block of text is the room.

The other side signs a reply, and the check happens in your browser: it recovers the signing address from the signature itself and compares it to the address you wrote down. Nothing vouches for your counterparty — not us, not a database, not a session. The evidence is arithmetic performed on your own machine, on a signature no server ever saw.

The signed text also contains the SHA-256 fingerprint of that browser's one-off encryption certificate, which is the part that matters most. A signature on its own is a copyable string, so somebody who intercepted a reply could relay it and claim to be its author. They cannot relay the private key behind the fingerprint. So the statement does not say “I control this wallet” — it says “I control this wallet and I am the far end of this exact connection”, and if those two come apart, verification fails.

A forwarded link, a leaked group chat or a compromised inbox therefore gets an attacker as far as a page asking them to prove they hold a private key they do not hold. There is no invite code to guess, no password to phish, and no display name to imitate.

Getting the invitation across

Two browsers cannot find each other without exchanging one block of text each. There are two ways to move it. They differ in convenience, and in whether anything is stored at all — but not in what anybody else can read.

By hand, free. You copy the invitation and send it however you already talk to this person; they paste their reply back the same way. Nothing touches a server of ours at any point — there is no room record to leak, to hand over, or to forget to delete, because one was never made.

As a five-character link, on Pro. The link is bare — otc.fastlock.pro/s/x7Y2q, with nothing after it — which raises the fair question of where the key is, since the invitation itself is stored on our server. It is nowhere. Your browser and theirs agree one between themselves, by swapping public keys through that same five-character code: we carry both public halves, neither private half ever leaves a tab, and what we end up storing is a block we have no key for. Collecting it deletes it in the same database statement that reads it, so the row is gone before the page finishes loading and a second reader gets nothing. Anything left uncollected is swept after thirty minutes.

Encryption here also authenticates: a stranger who guessed the five characters and posted a fake reply produces something that will not decrypt, which your browser discards as noise and keeps waiting for the real one.

The limit, stated plainly. That key exchange is not authenticated, so a server willing to actively substitute its own keys into both halves could read the invitation — not a stored copy, but as it passes. It could not use it: the invitation carries a wallet signature over the connection's fingerprint, and that is checked in the other browser against the address you wrote down, which no server ever sees. What this rules out absolutely is the passive case — a dump, a backup, a subpoena, someone reading rows — where there is simply nothing stored to read. If you want the case with no exception at all, use the free link: it stores nothing anywhere.

The call: directly between the two browsers

Once both sides are in, the browsers open a WebRTC connection to each other. Audio and video are SRTP, chat rides SCTP, and both are keyed by a DTLS handshake performed between the two endpoints. That encryption is part of the standard and cannot be switched off. We hold none of those keys, and neither does anything else in the path.

Encrypted chat is free. Voice, video and screen sharing are the VIP tier — and worth being straight about, because that is a product decision rather than a security one. None of that media passes through a server of ours, so there is nothing there we could enforce even if we wanted to. What VIP genuinely buys is the relay below, which is checked on the server because it has to be.

Some pairs of networks cannot reach each other directly at all — two symmetric NATs, typically a mobile carrier or an office firewall. There is no clever fix for that; the packets have to be bounced through a relay, and a relay is bandwidth somebody pays for by the gigabyte, which is why it is the VIP tier. The relay forwards sealed records and holds none of the keys, so it cannot open them. It does see both IP addresses, which is the honest cost of using one.

The relay credential is minted per session, expires in two hours, and is issued only after the server has checked the plan. It is never built into the page — anything shipped to the browser at build time would be a standing password published to every visitor.

The room shows a safety number: six groups of four characters, derived from both browsers' DTLS certificate fingerprints. Read it aloud once. If the two screens match, nobody has inserted themselves between you — and you have verified that yourself rather than taking our word for it.

What is actually stored

Notice what is missing from that list: the room. There is no row representing a conversation, because the conversation exists only as an open connection between two browsers. Closing a tab ends it. Nobody has to remember to press anything, and there is no button whose job is to delete a transcript, because there is no transcript to delete.

The flip side is worth saying out loud: a room that drops cannot be recovered. Nothing is holding it open on our side, so there is nothing to reconnect to — you open a new one and send a fresh invitation.

What never reaches the server

• Anything you type in the room
• Any second of audio or video
• Anything on a shared screen
• A file, a recording, or a transcript
• The address you wrote down — on a free room it never leaves the page at all
• A readable invitation, even when a short link is storing one
• A readable wallet address inside one — both sit in the sealed part, never in a column
• An email address, a phone number or a name — there is no field for one
• An analytics or advertising identifier

The limits, stated plainly

A signature proves control of a private key. It does not prove that the person holding that key is honest, or that the key has not been stolen — verify the address the same way you would before sending funds to it.

Encryption protects the connection, not the endpoints. Either side can record their own screen, and no web application can prevent that. What is guaranteed is that nothing in between — this site included — is able to.

The connection reveals your IP address to your counterparty, as any direct connection does, and to the relay if one is used. If that matters for a particular deal, use a VPN.

The door checks an ordinary ECDSA signature, which covers the wallets almost everyone uses and does not cover smart-contract wallets such as Safe or Argent. Verifying one of those means asking a blockchain node, and a node is a server — which is the thing this design is built to do without. If your counterparty deals from a Safe, they will need an ordinary wallet for the handshake.