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, and what the token is for.

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: every connected peer gets a copy. That replication is what makes delivery resilient, and it means no single node is a chokepoint that can be pressured, and no single node going offline loses your message.

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
Who sent a message	No	No, sealed sender	Yes, the recipient
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 the sender details, then the whole envelope is sealed again under an ephemeral key generated fresh for this one message. Only the recipient can open the outer layer.
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.

IPFS is content-addressed, so a file is referenced by the hash of its encrypted bytes. Without the decryption key that ciphertext is opaque, which is what lets media be stored on a public network without exposing what is in it.

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.

How DChat protects you

Security claims are easy to make and hard to check, so here is what DChat actually does, in terms you can verify against the published specification.

• Nobody in the middle holds a key. Relays carry ciphertext. The chain carries identity. Neither can decrypt a conversation, and neither can DChat.
• No account to seize. There is no company database with your identity in it, so there is nothing to breach, subpoena or switch off. An operator cannot read your messages, suspend you or reset your phrase, because it never held your keys.
• Keys rotate automatically. Every 10,000 messages or 30 days, whichever comes first, so any single key covers a bounded window rather than your whole history. Several comparable apps never rotate at all.
• Your device is the vault. Plaintext lives only on the devices in the conversation, in an encrypted local database, with keys wrapped in the platform's own secure storage and an app lock on top.
• Group membership stays off the ledger. A public membership list would be a permanent public record of who is in which group, so DChat deliberately does not publish one.
• The cryptography is published. secp256k1, HKDF-SHA256, ChaCha20-Poly1305 with a 256-bit key and a fresh 96-bit nonce per message. Every primitive and parameter is in the specification, which most closed messengers never publish at all.

One thing worth knowing before you use it, because it changes how you should treat group calls: a call with more than two people routes through a media server so it can scale past a direct connection, which means group calls are encrypted in transit rather than end to end. One-to-one calls connect your two devices directly with no server in the media path. If a conversation is sensitive, make it a one-to-one call.

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.