Most messaging apps describe themselves as secure. What they mean is that your data is encrypted while it travels between you and their server. The server, however, decrypts it, reads it, stores it, and re-encrypts it before forwarding it to your friend. The server is the postman who opens every letter.
At DaoDial, the server never sees plaintext. It never holds the keys. It is a zero-knowledge relay — it moves encrypted packets between addresses without any ability to understand what those packets contain.
The problem with phone numbers
Every major encrypted messenger — Signal, WhatsApp, iMessage — requires a phone number as your identity. That creates a hard dependency on a telecom provider. It leaks metadata. It ties a cryptographic identity to a piece of personally identifiable information that can be ported, spoofed, or legally compelled from a carrier.
In Web3, you already have an identity that is mathematically unforgeable: your wallet. When you connect to DaoDial, your wallet signs a domain-separated string:
DaoDial Signal Protocol Key Generation v2That signature becomes the entropy source for all your encryption keys. Only the person holding the wallet private key can produce that signature — and therefore only they can generate the corresponding encryption identity. No phone number. No email. No external identity provider. Your cryptographic self is bound to your on-chain self.
The asynchronous problem
Standard encrypted handshakes require both parties to be online simultaneously. That is not how messaging works in practice. You need to be able to send a message to someone who is asleep, on a plane, or has never opened the app.
We implemented the X3DH (Extended Triple Diffie-Hellman) protocol from the Signal specification. Before a user ever goes offline, their client generates and uploads a pool of One-Time Pre-Keys to the server — the public halves only. When you want to message them, you fetch one of those keys, perform four Diffie-Hellman operations locally, and derive a shared secret entirely on your device. The server hands over the key and immediately deletes it. The key ceases to exist the moment it is consumed.
This is forward secrecy: even if a server is compromised in the future, the keys used to lock past messages no longer exist anywhere.
The Double Ratchet
Once the handshake establishes an initial shared secret, every subsequent message advances a ratchet. Two ratchets run in parallel: a symmetric ratchet that derives a new key for every single message, and a Diffie-Hellman ratchet that refreshes the root key with every reply. The result is that a key compromised for message fifty cannot decrypt message forty-nine or message fifty-one. The system heals itself with every exchange.
Messaging wallets that have never registered
One of the harder engineering problems in encrypted social networks is the cold-start problem. You cannot encrypt a message to someone who has not yet generated their keys.
We built a Ghost User Protocol. You can send a message to any wallet address even if that wallet has never touched DaoDial. The server stores the encrypted metadata in a queued state. The moment that wallet connects and registers its pre-keys, the server broadcasts a migration event. Your client fetches the new keys, re-encrypts the queued messages locally, and delivers them through the freshly established session. The server at no point holds decryptable content.
What the server cannot do
We think it is worth being explicit about the limits of our own access:
- We cannot read your messages — they are encrypted with keys that never leave your device
- We cannot forge a message from you — we do not hold your private keys
- We cannot decrypt old messages — the message keys are deleted after a single use
The server sees encrypted blobs, timestamps, and the public keys used for routing. That is all.
For the full technical specification — X3DH sequence diagrams, Double Ratchet state tables, multi-device key synchronisation, and the interactive protocol simulator — read the complete protocol paper.