How DChat is put together
Three layers: a chain that carries identity, a relay network that carries ciphertext, and clients that hold every key.
How DChat is put together
DChat is not a messenger bolted onto a blockchain, and it is not a blockchain that happens to send messages. It is three separate systems wired together, each doing one job. Most of the confusion around the project comes from collapsing those three into one.
The chain. DChat runs a Cosmos SDK chain (v0.50.13) on a vendored CometBFT fork (v0.38.17). The modules actually implemented are identity profile servicenode clientreward and grpc. They carry account addresses, usernames and DIDs, service-node registration and staking, and the client-reward accounting described in the network guide below. Two other modules, message and messaging exist in the source tree but are unimplemented scaffold stubs - they do nothing. Message content is never written to consensus state. If a description of DChat calls it "a messenger on a blockchain," that is backwards: the chain is a public ledger for identity and stake, not a channel for conversation.
The relay network, "swarmchat." The actual transport for message ciphertext is a store-and-forward relay layered onto the same vendored CometBFT fork - but running alongside its consensus engine, not through it. Nodes talk to each other over a P2P reactor on channel 0x50 and each node exposes a gRPC front door on port 9091 for clients: native bidirectional streaming on Android, gRPC-Web server streaming in WebAssembly. Every node keeps a local LevelDB pool of ciphertext, holds it for a bounded retention window, and floods it to every peer it is connected to. That is a genuinely decentralized transport, but it is a flood, not a route: there is no per-user swarm assignment, no sharding, no onion routing and no mixnet. See the messaging guide for the retention numbers and what "flood" means in practice.
The clients. Every key that could decrypt a message lives only on a device: the identity/wallet key, the chat key used for message key agreement, per-group sender keys, an account rotating key shared across a user's own linked devices, and an Ed25519 key that signs IPNS pointers. Nothing off-device can decrypt a conversation - not the relay, not the chain, not DChat's own infrastructure.
The practical consequence: identity and stake are public and permanent, on a ledger anyone can query. Message transport is decentralized but time-bounded and metadata-leaky. Message content and key custody are exclusively client-side. Those are three different trust surfaces, and conflating them is the single most common misreading of the project.
| Data | Chain | Relay pool | Your device | IPFS |
|---|---|---|---|---|
| Message content | No | No ciphertext only, 14 days | Yes SQLCipher database | No |
| Envelope metadata (sender DID, sender public key, chat id) | No | Yes - cleartext | Yes | No |
Account address (dc1…) | Yes - public | No | Yes | No |
| Username, required at signup | Yes - public | No | Yes | No |
| Group membership and roles | No | No | Yes - client-asserted | Partial - offline-recovery pointer only |
| Media files | No | No | Yes | Yes - encrypted, hash public |
| Private key / recovery phrase | No | No | Yes - never transmitted | No |
| Service-node stake and rewards | Yes - public | No | No | No |
Related: Spec §7 - what reaches the chain · FAQ - is the blockchain state public?