The DChat whitepaper
The complete system specification: identity, message encryption, groups, the relay network, calls, the chain, node economics, and a full statement of the security properties DChat provides and the ones it does not. Written to be checked, not believed.
Abstract
DChat is an end-to-end encrypted messenger in which the account is a secp256k1 key pair rather than a phone number, message transport is a store-and-forward relay network run by staked independent operators rather than a company's servers, and the registry that maps a username to an account is a public Cosmos SDK blockchain rather than a private directory. A non-custodial wallet is built into the same client and derives from the same seed, so a payment is something you send inside a conversation rather than in another application.
Direct messages use secp256k1 ECDH, HKDF-SHA256 and ChaCha20-Poly1305. Group messages use per-member sender keys distributed over the pairwise channel, so a group is end-to-end encrypted with no server ever holding a group key. Keys rotate automatically after 10,000 messages or 30 days, which bounds the value of any single key compromise. Undelivered ciphertext is held by relay nodes for at most 14 days, under no key any operator holds.
31 July 2026 PDF · 20 pages
At a glance
Contents
What the paper says about its own limits
Section 13 states the security properties in full. The short version, so that nobody has to download 20 pages to find it.
- Confidentiality of direct and group message content against every party except the recipients
- End-to-end encrypted one-to-one calls
- Automatic key rotation bounding any key compromise to a 10,000 message or 30 day window
- Forward-secure group removal by sender-key rotation
- No phone number, email address or other third-party identifier at account creation
- No operator-held credential that could be compelled to decrypt traffic
- Non-custodial funds and encrypted local storage
- Per-message forward secrecy: rotation is generational, not a Double Ratchet
- Metadata protection: relays observe communication patterns
- Traffic-analysis resistance: no padding, cover traffic or mixing
- IP protection from service nodes: use a VPN or Tor if you need it
- End-to-end encrypted group calls: the SFU is inside the trust boundary
- Consensus-backed group state: membership is client-asserted by design
- Registry privacy: a username is required at setup and every username is public on the chain
- An independent audit: not yet commissioned
Read the rest
The whitepaper describes the system. The specification gives every parameter, and the security page gives the threat model and disclosure policy.