Frequently asked questions

DChat is a messaging app built on its own the chain framework blockchain. Your identity is a key pair instead of a phone number, messages travel over a store-and-forward relay network called Swarmchat rather than a central server, and a built-in wallet lets you hold and send the network's token, DCHAT, from inside the same app.

Signal and Telegram tie your account to a phone number and run their own servers. DChat ties your account to a recovery phrase and routes messages through a network of independently operated relay ("service") nodes instead of one company's servers. DChat also uses sealed sender, so a relay forwards your message without learning which account sent it. See Privacy & metadata below for the specifics.

DChat is a messenger with a wallet attached, not a trading app. You can send and receive DCHAT inside a chat, stake it to help secure the network, and pay gas for transactions, but there is no exchange, no swap, and no speculative trading screen inside the app.

Downloading DChat and sending messages is free. The only costs are network gas fees when you send an on-chain payment or stake, and those are denominated in udchat (see Wallet & payments below).

DChat ships today on Android, minimum API 24 (Android 7.0). iOS, macOS (Mac Catalyst) and Windows builds exist in the source tree, but Android is the platform actually shipping.

The app is selectable in seven languages: English, Arabic, Persian/Farsi, Kurdish Sorani, Pashto, French and Spanish. Arabic, Farsi, Kurdish Sorani and Pashto are right-to-left, and the whole interface mirrors for them rather than only the text.

No. Your identity is a secp256k1 key pair generated on your device during onboarding; the only thing you choose is a username.

A username must be 3 to 32 characters, start with a letter, and contain only letters, digits and underscores; it cannot end with an underscore. The signup screen checks availability live as you type, and you can optionally enter a referral code.

Yes, any time, from Settings. Your display name is a label layered on top of your account address; changing it does not touch your address, your keys, or your message history.

It is a 24-word BIP-39 mnemonic (12 words is also supported) generated on your device during onboarding, giving 256 bits of entropy at the default length. It is the only way to restore your identity and wallet on a new device, and DChat never sees it or stores a copy anywhere.

dc1… is your account address: a bech32-encoded hash of your public key, using the dc prefix. It is the address your contacts send DCHAT payments to, derived the same way any purpose-built chain derives an address.

A DID (decentralized identifier) is a chain-native identity string built from your account, generally in the form did:dchat:…. You can share it, or your address or username, so someone can add you as a contact.

Your account address and your username. A username is required during setup, so every account has one and every account is in the public registry. A display name and avatar set on-chain are public too. Anyone can query the chain and resolve a username to a DID to a wallet address, and from there read that wallet's full transaction history. Treat the on-chain identity registry as a public directory, not a private record, and pick a username you are comfortable being public.

Install DChat, choose sign in, and paste your 24-word phrase. That restores your identity and wallet keys immediately. You are then offered a one-time Backup & Restore step to search DChat's cloud pointer or pick a local .dmbackup file for messages and contacts, nothing downloads automatically.

The recovery phrase alone restores your identity and wallet: your address, keys, and DCHAT balance. Messages, contacts and media only come back if you additionally restore a backup (cloud or local .dmbackup file) in the step that follows sign-in.

The cloud option looks up an IPNS pointer derived from your seed to find an encrypted backup stored on IPFS; the local option lets you pick a .dmbackup file you saved yourself. Both carry messages and contacts, and can optionally include media. Neither runs automatically, you choose one during the one-time restore step after signing in.

Go to Settings, Linked Devices, Link a Device, and scan the QR code shown at dchat.app on the new device. Your phone exports an encrypted provisioning bundle, registers the new device in an IPNS device registry, and triggers a fresh archive export so the new device gets your history.

Revoking a linked device from Settings, Linked Devices tombstones that device in the device registry and rotates your keys so it can no longer decrypt future messages. It cannot delete anything the device already downloaded before revocation.

There is no recovery path without it. Nobody, including DChat, can reset it or restore your account from anything else, because the phrase is the only thing that regenerates your private keys. Write it down and store it somewhere durable the moment you see it.

One grey tick means sent, two grey ticks means delivered to the recipient's device, and two blue ticks means read. Read and delivered receipts are sent back to you as ordinary encrypted messages, batched per conversation, the same way Telegram's read-history mechanism works.

The message is held as ciphertext by relay nodes and retried to your recipient's device for up to 30 minutes, once a minute, and again in full whenever their device reconnects. Nothing is lost just because someone was briefly offline.

A regular message is retained by relay nodes for up to 14 days; configuration messages (like key material) get 30 days. After that, undelivered ciphertext is deleted. Each account is also capped at 10,000 stored messages on a relay, oldest evicted first, and a cleanup sweep runs hourly.

Five options: Off, 24 hours, 7 days, 1 month, and 3 months. Turning it on only affects messages sent after you change the setting, it does not retroactively remove earlier history.

Yes. You can edit a message, delete it for yourself, or delete it for everyone. You can also reply, forward, copy, pin (in 1:1 chats, either "for me only" or "for both"), and star a message for later.

DChat has 10 animated reactions, Like, Love, Haha, Wow, Sad, Angry, Fire, Clap, Pray and Rocket, with 6 of them in the quick-pick bar and the rest one tap further.

Yes to both. Polls are anonymous by default with an option for multiple answers per voter. To-do lists are a separate message type shared and checked off within a chat.

Yes. You can send voice messages, video messages including round video notes, stickers (with a sticker store), GIFs, contact cards, and albums of 2 to 10 items in one bubble.

You can share your location once or as a live location for a duration you set, translate a message in place, and search within a chat. All three are built into the chat screen itself.

Drafts are saved automatically per chat as you type. Images are capped at 50 MB client-side before sending; thumbnails are capped at 150 KB and sent inline rather than through file storage.

No. DChat does not have a "send later" scheduling option, and there is no Saved Messages self-chat the way Telegram has one. If you want to keep a message for reference, starring it is the closest equivalent.

100 members, enforced in the app's member picker and stated on the group creation screen.

Exactly two: Member and Admin. There is no separate Owner role in the data model, whoever creates the group is simply an Admin, and can promote others.

An admin can share an invite link. Depending on how the group is configured, people who use it are added directly or placed into a join request that an admin has to approve.

You control this in Privacy settings under "Who Can Add Me to Groups": Everyone, My Contacts, Selected Contacts, or Nobody.

No. Someone added to a group cannot see messages sent before they joined. This is a consequence of the encryption, not just a policy choice: they were never given the sender keys used for earlier messages.

DChat rotates every remaining member's sender key and redistributes the new ones, so the departed member can't decrypt anything sent afterward, though they can still read whatever they already received. This rotation is something the DChat app does on your behalf when you remove someone, it is not enforced by the underlying protocol, so it depends on the client doing the right thing, and it is a best-effort operation per member rather than an all-or-nothing transaction.

Yes. Channels are broadcast to an audience that follows you, separate from groups. A group is a conversation capped at 100 members where everyone can post; a channel is one-to-many, for publishing to followers. Both are available in the app today.

Yes. One-to-one calls are peer-to-peer WebRTC connections secured with DTLS-SRTP directly between the two devices, no server sits in the media path.

Yes. Because 1:1 calls connect directly, your call partner, and the TURN server if the connection is relayed through it, can see your IP address. This is normal for peer-to-peer calling in general and isn't specific to DChat.

No, and it's worth being precise about why. Group calls run through a Janus SFU that terminates DTLS-SRTP with each participant individually, which means the SFU itself holds the decrypted media in the middle of the call. Group calls are encrypted between each participant and the SFU, not end-to-end between participants. One-to-one calls are the ones that are genuinely end-to-end encrypted.

The video room supports up to 25 participants.

Yes, DChat has a call history screen listing your past 1:1 and group calls.

Usually a network or NAT traversal issue: ICE negotiation between your device and the other side (or the TURN server) didn't complete in time. Retrying, or switching networks (Wi-Fi to mobile data or back), resolves most of these.

Yes. "New Call" from a multi-select contact picker starts a group call without needing an existing group chat.

Very little. The message body is encrypted, and the envelope around it is sealed again under an ephemeral key generated fresh for every message, so a relay cannot tell who sent it. What it handles is a blob it has no key for plus a value that looks random and changes every time. Your IP is visible to the node you connect to, as it is with any network.

Your key pair and DID aren't tied to your real name, and there is no phone number or email to tie them to one. Sealed sender means a relay cannot link your messages together over time or build a social graph from them. Your IP remains visible to the node you connect to, as with any network.

To a degree, yes. DChat does not pad messages to a fixed size, generate cover traffic, or delay messages to obscure timing, so someone watching network traffic can observe approximate message sizes and timing even without reading content.

You choose one of three delivery modes: Push Notifications (fastest, relies on platform push services waking the app), Battery Saving, or Always Connected (keeps a live connection open for the quickest delivery at the cost of battery). The faster and more convenient a mode is, the more it typically depends on a third-party push service knowing a notification was sent to you, even though it can't read the content.

Someone compelling a relay operator could obtain what that relay actually holds: ciphertext within its 14/30-day retention window, and connection IPs. They could not obtain message content, because no relay holds decryption keys; they could not learn who sent a message, because sealed sender puts that inside the encrypted envelope; and they could not obtain your recovery phrase or private keys, because those never leave your device.

No. Sealed sender puts the sender inside the encrypted envelope, so a relay sees a value that looks random and changes with every message. There is no stable identifier in relay traffic to correlate into a social graph.

Direct messages use static-static ECDH on secp256k1, HKDF-SHA256 to derive a key, and ChaCha20-Poly1305 (256-bit key, 96-bit nonce, 128-bit tag) to encrypt, not X25519, and not XChaCha20 or AES-GCM (AES-256-GCM is used only for avatar images). Groups use per-member 32-byte symmetric sender keys distributed over that same ECDH channel. Full parameter-level detail is in the cryptographic specification.

No. DChat uses static-static ECDH rather than a ratcheting protocol, so there are no ephemeral prekeys and no post-compromise self-healing. In practice this means forward secrecy is coarse-grained: if a chat key were compromised, an attacker could read that key generation's whole window, up to 10,000 messages or 30 days, rather than a single message, as they could with Signal's Double Ratchet.

By default, keys rotate after 10,000 messages or 30 days, whichever comes first. A Conservative policy rotates at 5,000 messages / 14 days, and a Relaxed policy at 20,000 messages / 60 days. You can also trigger an emergency rotation manually at any time.

Your keys are wrapped under a device master key held in platform secure storage (Android Keystore on Android), stretched with PBKDF2-HMAC-SHA256 at 250,000 iterations on native platforms. The message and contact database itself is a local SQLCipher-encrypted SQLite file owned by the app, not the SDK.

Yes, and it's disclosed rather than hidden: the WebAssembly build uses only 10,000 PBKDF2 iterations instead of 250,000, because WASM is single-threaded and 250,000 iterations would block the browser's event loop for two to three seconds. This is defensible because the PBKDF2 input is already a 256-bit random device key rather than a human password, but it is a real, platform-specific weakening.

Yes, DChat supports biometric app lock with a configurable timeout, set up from Settings. It is not enabled during onboarding, turn it on afterward if you want it.

Not yet. DChat's cryptography has not been through an independent audit or formal verification, and there is no bug bounty program currently running. This is stated plainly rather than implied otherwise, treat it as a real gap, not a formality.

Use the vulnerability report path linked from the Security page. Reports are read by a person, and the specification and known-weaknesses pages document exactly what has and hasn't been reviewed, so you know what you're checking against.

DCHAT is denominated on-chain in udchat, with 6 decimal places, 1 DCHAT equals 1,000,000 udchat. The app always displays balances as DCHAT.

When you send a transaction, you pick Slow (0 udchat gas price), Normal (0.025 udchat) or Fast (0.04 udchat) per unit of gas. The app simulates the transaction first and multiplies the estimate by 1.4 to build in headroom, then shows you the fee estimate before you confirm.

Yes. You can send a payment directly in a conversation and it appears as a payment bubble in the chat, alongside your regular messages.

Yes. Request Payment gives you a keypad to enter an amount and an optional note (up to 128 characters), and it shows up as a request bubble the other person can pay directly.

The Wallet screen's staking section shows your total staked balance, pending rewards with a "Claim All" button, your active delegations, and any unbonding entries still working through the network's 7-day unbonding period.

Yes. Your wallet key is derived from the same recovery phrase as your messaging identity. Anyone with your phrase controls your funds as fully as they control your account, so protect it accordingly.

Yes. Payments settle on-chain, so a payment sent to your address arrives whether or not your device is online at that moment; your balance updates the next time you open the app and it syncs with the chain.

Swarmchat is DChat's message transport network: the store-and-forward layer that carries encrypted messages between devices. It is the part of DChat that replaces the central server other messengers run. Swarmchat is made up of service nodes, and it is separate from the blockchain, which handles identity, staking and rewards and never carries message content. A message is encrypted on your device, handed to Swarmchat as ciphertext, replicated across several nodes so no single one going offline can lose it, and held for up to 14 days until the recipient collects it. No node can read what it carries.

A service node is a relay operator on the Swarmchat network, the store-and-forward infrastructure that holds and forwards message ciphertext between devices. Node operators stake DCHAT and are rewarded for keeping their node online and honest.

Running a service node requires a minimum stake of 10,000,000 DCHAT. The operator must supply at least a quarter of that themselves; up to 10 contributors can co-stake the rest, and the operator takes a configurable operator fee out of the rewards.

Nodes send a heartbeat every 300 seconds. Separately, an uptime-proof system picks a deterministic quorum of 10 verifier nodes (seeded by the block hash) every 720 blocks, and at least 7 of them must agree a node responded within a 4-second probe timeout, signed with the node's own key.

A node that fails its uptime proofs is slashed 5% and jailed for 720 blocks. There is also a decommission credit, an initial 240-block (roughly 2-hour) grace window, extendable up to 2,880 blocks (about 48 hours), for a node coming down for planned maintenance rather than failure.

You can earn DCHAT for messaging activity, up to a daily cap of 100 DCHAT (10 DCHAT/day for your first 14 days after verification). The reward pool pays out 0.0274% of its balance per day, counted per sender-recipient pair (capped at 20 messages per epoch, 100 per day), you can make one claim per day, and a messaging streak of at least 5 messages/day builds a multiplier up to 1.5x at 25 days.

Claiming message-mining rewards requires a bound proof-of-humanity nullifier (World ID, BrightID, or Gitcoin), so the reward pool pays real people messaging each other rather than bots or duplicate accounts farming the same wallet many times over.

Yes. Account addresses, registered usernames, and any display name or avatar you set on-chain are all publicly queryable, and anyone can resolve a username to a DID to a wallet address. Message content itself is never written to the chain, only identity and account data are.

The .NET DChatSDK covers identity and key management, message encryption and decryption, group sender-key handling, key rotation, relay (Swarmchat) connectivity, wallet operations, and at-rest storage of key material. It is what DChat's own Android client is built on.

The protocol itself is fully documented, see the cryptographic specification, but the SDK is not currently published as open source. There is no public repository and no NuGet package today.

You could build a client against the documented protocol and Swarmchat's gRPC interface, but be aware of what you would be taking on yourself: for example, post-removal group key rotation is something the DChat app calls explicitly, not something the SDK enforces automatically, so a third-party client that skips it leaves removed members able to decrypt group messages until the next routine rotation.

Yes. DChat's Enterprise offering ships the app as a white-label build under your brand, hosted in DChat's cloud or fully on your own infrastructure. See the Enterprise page for what that involves.

Start with the Help Center, which covers setup and common issues in more depth than this FAQ. The blockchain explorer, linked in the footer, lets you look up any address, username, or service node yourself. If you still need help, use Contact us.

Use the "Report a bug" link from Contact us, or from the Help Center. Include your platform, app version, and what you were doing when it happened, that is usually enough to reproduce it.

Use the vulnerability report path on the Security page. Security reports are handled separately from general support and are read by a person, not routed through a general ticket queue.

A person reads every message sent through the contact form, it isn't an automated ticket bot. Response time varies, but security reports and bug reports are prioritized over general questions.