What is DChat? All you need to know about decentralized messaging

Almost every messenger you already use answers three questions the same way. Your account is a phone number. One company runs the servers. Money is somebody else's app. Those three answers decide what a messenger really is, and everything else - the sticker packs, the themes, the reaction emoji - sits on top of them.

The consequences show up whenever the arrangement is stressed. A phone number ties a supposedly private account to a SIM registry and a carrier. A single operator is a single place to breach, to subpoena and to switch off. And a conversation about paying someone has to leave the conversation to actually pay them.

DChat answers all three differently. This article explains how, in the order most people want it: what the thing is, how it works underneath, what you can do with it, what the token is for, and what it does not protect you against. That last section is not a formality. A messenger that only lists its strengths is not telling you enough to trust it.

What is DChat?

DChat is a decentralized, end-to-end encrypted messenger built on its own blockchain. It does the things you expect a modern messenger to do - text, photos, albums, voice messages, video messages, files, locations, replies, reactions, edits, disappearing messages, groups, voice and video calls - and it does them without a company account behind you.

When you open the app for the first time, your device generates a key pair and shows you a recovery phrase. You pick a username, which is required and is registered on the public ledger, and that is the whole signup. There is no phone number, no email address, no password and no profile sitting in a database that could be leaked, reset or handed over. What you get is:

• A username registered on chain, globally unique because a public ledger decides who owns it rather than a company support desk.
• A wallet address beginning dc1, which is your on-chain identity and your payment address at the same time.
• A decentralized identifier in the form did:dchat:yourname, used app-wide.
• A recovery phrase of 12 or 24 words, defaulting to 24. It is the only backup of the account, and nobody can reset it for you.

That last point is the trade, stated plainly: because there is no company holding your credentials, there is no company that can be compelled to hand them over, and equally none that can restore your account if you lose both the phrase and every device you were signed in on. There is no back door. That is the point, and it is also the risk.

How does DChat work? The architecture

The most common misreading of any blockchain messenger is that messages travel through the chain. In DChat they do not, and the design only makes sense once you see it as three separate systems wired together, each doing one job.

The chain

DChat runs its own proof-of-stake ledger. It carries exactly four things: account addresses, usernames and DIDs, service-node registration and staking, and reward accounting. That is the entire job of the chain. Message content is never written to it.

The chain does have one direct role in messaging, though, and it is a useful one: every message is signed with the sender's chain-registered identity key, and the recipient's app verifies that signature against the on-chain record. Impersonation therefore fails without anyone having to trust a server's word about who sent what.

The relay network

Ciphertext travels over a separate store-and-forward relay that runs alongside the ledger rather than through it. Nodes speak to each other peer to peer and expose a streaming front door that clients connect to directly. Each node keeps a local pool of ciphertext, holds it for a bounded window, and floods it to every peer it is connected to.

Worth being precise about, because the marketing word for this is usually wrong: it is a flood, not a route. There is no per-user swarm assignment, no sharding, no onion routing and no mixnet. Every connected peer gets a copy. That is genuinely decentralized transport, and it is also why metadata rather than content is the honest privacy concern here.

The clients

Every key that could decrypt anything lives only on a device. Five distinct key types exist and are never interchanged: the identity and wallet key, the chat key used for message key agreement, per-group sender keys, an account rotating key shared between your own linked devices, and an Ed25519 key that signs IPNS pointer records. Nothing off-device can decrypt a conversation - not the relay, not the chain, not DChat's own infrastructure.

The practical consequence is that DChat has three different trust surfaces, and conflating them is how people end up with the wrong idea of what is public.

Data	Chain	Relay pool	Your device
Message content	No	Ciphertext only, 14 days	Yes, encrypted database
Envelope metadata (sender DID, public key, chat id)	No	Yes, in cleartext	Yes
Username and dc1 address	Yes, public	No	Yes
Group membership and roles	No	No	Yes, client-held
Recovery phrase and private keys	No	No	Yes, never transmitted
Token balances and transfers	Yes, public	No	Yes

How a message actually travels

The path is the same every time, and every step of it is either cryptographically closed or openly disclosed as metadata. There is no middle category.

1. Encrypt on device. Your chat private key and the recipient's chat public key run through static-static ECDH on secp256k1. The shared secret is stretched with HKDF-SHA256, and the plaintext is sealed with ChaCha20-Poly1305 under a fresh 96-bit nonce drawn per message.
2. Assemble the envelope. The ciphertext, nonce and authentication tag are packaged with routing fields: sender DID, sender public key, chat id, key generation and encryption mode.
3. Stream to a service node. The envelope goes out over an authenticated two-way stream to whichever node your device is connected to.
4. Persist, then flood. That node writes the ciphertext to its own pool, delivers it immediately to any of the recipient's devices with a live stream open, and forwards it to every peer it is connected to.
5. Drain or expire. An offline recipient collects the message from any peer's pool on reconnect, until the retention window closes.

The numbers behind that are fixed and public. An undelivered regular message is retained for up to 14 days; configuration messages carrying key material get 30 days. Each account is capped at 10,000 stored messages per relay, oldest evicted first. Pending sends retry for up to 30 minutes, and duplicate delivery is suppressed by a 45-minute seen-set. Ephemeral traffic such as call signalling, typing indicators and presence is never written to a pool at all.

Encryption keys are not permanent either. Chat keys rotate automatically after 10,000 messages or 30 days, so a key that was somehow stolen exposes that window rather than your entire history. Several comparable apps do not rotate at all.

What people actually use it for

• Private one-to-one and group conversation. The everyday case. Text, images and albums, voice messages with waveforms, video messages, files, contact cards, static and live location, link previews, replies, reactions, edits, pins, forwarding with or without attribution, and disappearing messages.
• Communication that does not require identifying yourself. Journalists, researchers and anyone whose phone number is itself sensitive can hold an account with no number, no email and no billing relationship attached to it.
• Payments inside the conversation. Sending value to the person you are already talking to, as a payment bubble in the thread rather than an address copied into a different app.
• Running network infrastructure. Operators stake and run service nodes, carrying the relay pool and answering client requests, and are paid for verified uptime.
• Building on top of it. The SDK exposes identity, messaging and wallet primitives to other applications, with an enterprise track for white-label deployments.

Main features

Identity without a phone number

Signup is a username plus a recovery phrase. Derivation follows the same BIP-39 and BIP-44 standards a hardware wallet uses, on the secp256k1 curve, producing an address under the dc prefix. Every generated mnemonic is round-tripped through derivation before it is shown, so a phrase that would fail to restore is discarded rather than displayed.

The public part of this deserves its own sentence, because it is a real trade rather than a footnote. Your username lives on a public ledger, which is how it can be globally unique without a company adjudicating ownership, and it also means anyone can look that username up, find the wallet address behind it, and read that wallet's full transaction history. Pick a name you are comfortable being public, and do not treat the attached wallet as private.

Messaging and contact control

Strangers cannot message you until you accept a contact request, and blocking is silent - the person who was blocked gets no signal that it happened. Online status, last seen and typing indicators are not shared with people who are not your contacts. Delivery state is a small, precise machine: one tick means a relay accepted the envelope, two grey ticks mean the recipient's device pulled and decrypted it, two blue ticks mean they opened it. Read receipts are themselves ordinary encrypted messages travelling back to you, not a side channel.

Groups

Groups use an N-sender-keys model rather than one shared group key: every member holds their own 32-byte sending key, delivered to the other members over the same pairwise encrypted channel used for direct messages. No server ever handles a sender key in the clear. Groups hold up to 100 people with member and admin roles, and invite links create join requests an admin approves.

New members cannot read anything sent before they arrived, because they do not hold the earlier keys. When someone leaves or is removed, the remaining members' keys are rotated and redistributed, so the departed member cannot read what follows. Membership itself is deliberately not written to the ledger: a public membership list would be a permanent public record of who is in which group.

Voice and video calls

This is the one place where two features that look alike behave differently, so it is worth stating without hedging.

A one-to-one call is WebRTC connecting the two devices directly, peer to peer, with DTLS-SRTP securing the media end to end. No server sits in the media path, and call signalling is ephemeral and never written to a pool. The unavoidable consequence of connecting directly is that your IP address is visible to the person you are calling, and to the relay server if the call has to route through one. That is inherent to direct calling in any app, but it is real.

Group calls work differently. They run through a selective forwarding unit supporting up to 25 participants, which terminates the encrypted connection with each participant and re-encrypts outward to everyone else. That is what lets a call scale past two people at all, and it means the media server sees plaintext audio and video in the middle of the call. Group calls are encrypted in transit, not end-to-end. They have the trust profile of a conference bridge. If something should not be heard by the operator of that bridge, use a one-to-one call.

Files, photos and IPFS

Media reuses the same envelope as text: the bytes are encrypted with the same ECDH-agreed, HKDF-derived, ChaCha20-Poly1305-sealed construction, the envelope is signed with the sender's identity key, and the signed package is uploaded to IPFS through an authenticated middleware API. Photos, videos, voice messages, video notes, stickers and GIFs all take the identical path. Thumbnails are capped at 150 KB and travel inline, which is why a preview appears before the full image loads; full images are capped client-side at 50 MB.

"The hash is public, the content is not" is accurate, with one limit worth naming. IPFS is content-addressed, so the hash of the encrypted bytes is genuinely public. Without the key the ciphertext behind it is opaque, but an observer who already holds the exact same file can encrypt their own copy and check for a match. That is a property of content-addressed storage generally, not a DChat-specific flaw, and it means "public hash" should be read as "the content stays opaque", not "nothing can ever be inferred".

Wallet in the conversation

The wallet is non-custodial and built in, sharing the identity key you already have. It shows your balance, sends and receives by address or QR, keeps a transaction history, and renders in-chat payments as a dedicated bubble in the thread. The bubble and the wallet history are two views of the same transaction, so they cannot disagree about its state. An app lock with PIN or biometrics sits on top.

On the device

Plaintext lives only on participants' own devices, in an encrypted local database. Keys are wrapped under a device master key held in the platform's own secure storage and stretched with a key-derivation function before use. An attacker holding a locked device without the unlock credential does not get the keys.

What is the DCHAT token for?

DCHAT is the network's utility token. Its base denomination is udchat with six decimals, so one DCHAT is 1,000,000 udchat, and it is always displayed to users simply as DChat. It has three jobs and no others.

Network fees. Transactions carry a small gas cost, with three price tiers offered in the app and gas simulated before sending. New accounts are funded automatically from the network faucet at registration, so nobody has to acquire anything before they can start chatting.

Payments between people. Peer-to-peer transfers, including the in-chat payment bubbles described above, and payment request links and QR codes.

Paying for the network to exist. Two separate reward systems run on chain. Service-node operators register with a minimum stake of 10,000,000 DCHAT, of which the operator supplies at least a quarter and up to ten contributors can co-stake the rest. Nodes heartbeat every 300 seconds, unstaking triggers a 7-day unbonding period, and uptime is proven rather than claimed: a deterministic quorum of ten verifier nodes, seeded by the block hash so nobody picks their own verifiers, probes each node periodically and at least seven must agree it responded. Failing uptime costs a 5% slash and a temporary jail; planned maintenance gets a decommission credit instead.

The second system pays ordinary users for messaging activity, gated behind a proof-of-humanity nullifier so the pool pays distinct people rather than one wallet farming itself. It is capped hard: 100 DCHAT per day, reduced to 10 for a new user's first 14 days, counted per sender-recipient pair with per-pair limits, matured for 7 days before a claim can be collected, with referrals worth 5 DCHAT each up to 50 referrals, and a messaging streak multiplier topping out at 1.5x.

What DChat does not protect against

A threat model is only useful if it names the adversary on both sides of the line. DChat's architecture removes the operator as a point of trust, and that is the part it does well. The following are the parts it does not, kept here in the body of the article rather than moved into small print.

• Traffic analysis. There is no padding to fixed sizes, no cover traffic and no delay mixing. Message timing and approximate size are observable to anyone watching the network.
• Social-graph inference by a relay. Sender DID, sender public key and chat id travel in cleartext on every envelope. A relay can link messages to the same sender over time without decrypting a single one.
• A compromised endpoint. Malware or physical access to an unlocked device reads everything, because at that point it is effectively you. No messenger solves this.
• Post-compromise security. Key agreement is static-static ECDH with no double ratchet. A stolen chat key exposes that whole rotation window - up to 10,000 messages or 30 days - rather than a single message.
• Group-call media. As described above, the media server for group calls sees plaintext. Only one-to-one calls are end-to-end encrypted.
• Anything you make public. Your username and its wallet's transaction history are on a public ledger by design.

And the disclosure that matters most: none of this has been independently audited. No outside cryptographer or security firm has reviewed the protocol, there is no formal verification, and there is no paid bug bounty. Reports are welcomed and credited, but that is a different thing. Treat the design as reasoned about, not as externally tested. The full parameter-level detail, including the known weaknesses, is published in the cryptographic specification.

How to start using DChat

1. Install it. Android from Google Play, the web app at dchat.online, or the desktop build for Windows, macOS or Linux.
2. Pick a username. Lowercase letters, numbers and underscores. It is registered on chain, so it is globally unique and permanent. Choose one you are comfortable being public.
3. Write the recovery phrase down on paper. Not a screenshot, not a note in a cloud drive. It is the only way back into the account, and nobody can reissue it.
4. Start chatting. Your dc1 address and DID are created automatically and the account is funded from the faucet, so there is nothing to buy first. Add a contact by QR code or username and send a message.

Where to go next

If you want the plain-language version of the whole system in about ten minutes, read the litepaper. If you want the architecture in more depth, the guides break it into nine explainers. If you want to attack it, the specification lists every primitive, parameter and wire format, and the security page states the audit position and the disclosure policy. And if you just want to see the chain doing its job, the block explorer is live.