Frequently Asked Questions
Last Updated: December 6, 2025
zk.im is fundamentally different because it has no central servers. Unlike WhatsApp (Meta-owned) or Telegram (server-based), zk.im uses peer-to-peer communication where messages travel directly between users' devices. This means no company can read your messages, block your account, or shut down the service. Additionally, zk.im uses zero-knowledge architecture where even metadata (who you talk to, when) is never collected.
No installation required! zk.im runs entirely in your web browser. Simply visit zk.im and connect your existing crypto wallet (like MetaMask, Phantom, or any Web3 wallet). The platform works on desktop and mobile browsers. However, for the best experience on mobile, use HTTPS (the platform automatically handles this).
zk.im uses an 'Invisible Wallet' system with guardian-based recovery. You can designate trusted guardians (friends, family, or other devices) who can help you recover access. The system uses progressive security: small transactions don't require guardians, but larger ones do. This balances convenience with security. Unlike traditional wallets, your keys are never stored—they're constructed on-demand from multiple factors (wallet signature + TOTP + optional guardian approval).
Yes, core messaging is completely free. However, some advanced features have costs: username registration (free random usernames available, or pay for custom names), file storage via Pinning service (1GB free, then pay-as-you-go), and blockchain transaction fees (paid in native tokens like ETH, SOL, etc.) for wallet operations. The platform itself doesn't charge subscription fees.
Zero-knowledge means the platform can verify message integrity and authenticity without ever seeing the content. When you send a message, it's encrypted client-side using XChaCha20-Poly1305 (256-bit keys) before leaving your device. The encryption key is derived from multiple factors using Argon2id13 (memory-hard key derivation). The platform uses BLAKE3 hashing for content addressing, which means identical files are automatically deduplicated without revealing their content.
zk.im uses a hybrid approach: messages are stored in ZKIM CAS (Content Addressable Storage) encrypted with the recipient's public key. When the recipient comes online, their device queries the network for messages addressed to them. The P2P network uses relay nodes (users who opt-in to relay) to temporarily store encrypted messages. Since messages are encrypted, relay nodes cannot read them. This ensures message delivery even when both parties aren't simultaneously online.
The Invisible Wallet uses on-demand key construction. Your final encryption key is never stored anywhere—not on your device, not on servers, nowhere. Instead, the key is constructed from three components: (1) a static component from your wallet signature, (2) a dynamic TOTP code that changes every 30 seconds, and (3) optional guardian approval for high-value transactions. Even if malware steals one component, it cannot reconstruct the full key. The key is destroyed immediately after use.
zk.im is more resistant to blocking than centralized services, but not immune. Since there are no central servers to block, governments would need to block all P2P traffic (which would break many legitimate services). The platform uses WebRTC for direct connections and can route through relay nodes if direct connection fails. However, sophisticated network-level blocking (DPI - Deep Packet Inspection) could potentially identify and block P2P traffic patterns. The platform is designed to be censorship-resistant, not censorship-proof.
zk.im uses eventual consistency rather than strict delivery guarantees. Messages are stored in ZKIM CAS with the recipient's encrypted address. The system provides delivery receipts when messages are successfully decrypted by the recipient. However, if a recipient never comes online, messages remain in CAS indefinitely (encrypted). The platform doesn't guarantee 'exactly-once' delivery like traditional messaging—it uses a 'best-effort' model optimized for privacy and decentralization.
BLAKE3 is a cryptographic hash function that produces a deterministic output (ZOID - ZKIM Object Identifier) for identical inputs. When you upload a file, zk.im computes its BLAKE3 hash client-side. If that hash already exists in ZKIM CAS, the system knows the content is already stored and simply creates a reference instead of storing a duplicate. Since hashing is one-way, the hash doesn't reveal the content. However, identical files produce identical hashes, so if you know a file's hash, you can verify if it exists in the system (but not read it without the decryption key).
Currently, zk.im uses 'quantum-resistant' classical algorithms (XChaCha20-Poly1305 with 256-bit keys, Argon2id13) that provide resistance against quantum attacks due to their large key sizes. However, these are not NIST-standardized post-quantum algorithms. The platform plans to migrate to post-quantum algorithms (Kyber-768 for key exchange, Dilithium-3 for signatures) in the future. The current implementation provides strong security against classical and most quantum attacks, but true post-quantum migration is planned for future-proofing against advanced quantum computers.
The guardian system uses progressive thresholds based on transaction value. For high-value transactions (>$10,000), you need 5 out of 10 guardians to approve. This means an attacker would need to compromise at least 5 guardians simultaneously. Additionally, the system tracks guardian performance (approval rates, response times) and can automatically replace underperforming guardians. Guardians are notified of all approval requests, so suspicious patterns trigger alerts. The system also uses time-locked approvals to prevent rushed decisions.
ZKIM CAS uses a distributed storage model where content is stored across multiple peers in the P2P network. When you store data, it's encrypted and chunked using FastCDC (Fast Content-Defined Chunking), then distributed to available storage nodes. The system uses content addressing (BLAKE3 hashes) to locate chunks. If a storage node goes offline, the system can retrieve chunks from other nodes that have replicated them. However, there's no guarantee of permanent storage—data availability depends on network participation. For critical data, users can use the Pinning service which incentivizes long-term storage.
Client-side encryption adds overhead: ~5-20ms per operation for small files, but can be 100-500ms for large files (10MB+). The platform uses FastCDC chunking to break large files into smaller chunks (typically 1-4MB), which are encrypted in parallel. This reduces latency but increases complexity. For real-time chat, the overhead is acceptable (<100ms total). For file operations, users may experience 500ms-2s delays for large files. The trade-off is necessary for privacy—without client-side encryption, the platform would need to trust servers, which violates the zero-knowledge principle.
zk.im minimizes metadata leakage but cannot eliminate it completely in P2P networks. Network observers can see: (1) that you're participating in P2P traffic, (2) approximate message sizes (encrypted), (3) timing patterns (when you're active). However, the platform obscures: (1) message content (encrypted), (2) recipient identity (encrypted addresses), (3) message routing (uses relay nodes). Advanced attackers using traffic analysis could potentially correlate timing patterns, but this requires sophisticated resources. The platform prioritizes content privacy over perfect metadata privacy—a necessary trade-off for P2P functionality.
The 'last message problem' occurs when an attacker compromises a device and can read the last message sent before compromise. zk.im mitigates this through: (1) Perfect Forward Secrecy (PFS) using ephemeral keys that rotate frequently, (2) Immediate key destruction after use in Invisible Wallet, (3) TOTP codes that expire every 30 seconds. However, if an attacker has persistent access to your device, they could potentially intercept messages in real-time. The platform cannot prevent this—it's a fundamental limitation of client-side encryption. Users must secure their devices.
If XChaCha20-Poly1305 is broken (extremely unlikely but theoretically possible), all existing encrypted messages would be vulnerable. zk.im addresses this through: (1) Algorithm agility—the platform can migrate to new algorithms, (2) Key rotation—users can re-encrypt data with new keys, (3) Forward compatibility—the system supports multiple algorithm versions simultaneously. However, if a fundamental flaw is discovered, users would need to re-encrypt all their data. This is why the platform plans post-quantum migration—to future-proof against both quantum and classical attacks.
zk.im doesn't fully prevent Sybil attacks (creating many fake identities) because it's permissionless. However, it mitigates them through: (1) Proof-of-work for username registration (prevents mass username squatting), (2) Economic costs (transaction fees for operations), (3) Reputation systems for relay nodes (users rate relay performance), (4) Rate limiting on operations. A determined attacker could still create many identities, but they would need to pay transaction fees and maintain them. The platform prioritizes openness over strict Sybil resistance—a trade-off for decentralization.
No, zk.im cannot guarantee strict message ordering like centralized systems. In a P2P network, messages can arrive out of order due to network latency, routing paths, or relay node delays. The platform uses: (1) Timestamp-based ordering (client-side timestamps), (2) Sequence numbers for messages in a conversation, (3) Conflict resolution (last-write-wins for metadata conflicts). However, network partitions or relay failures can cause messages to arrive out of order. The platform prioritizes eventual consistency and message delivery over strict ordering—a necessary trade-off for decentralization.
The 'key escrow problem' occurs when recovery mechanisms create a backdoor. zk.im's guardian system mitigates this through: (1) No key storage—guardians don't store keys, they provide approval signatures, (2) Progressive thresholds—more guardians required for higher-value transactions, (3) Time-locked approvals—guardians have a window to approve, preventing rushed decisions, (4) Performance tracking—underperforming guardians are automatically replaced. However, if all guardians collude, they could approve unauthorized transactions. The system balances security with usability—users can choose guardian-free mode for maximum security (but lose recovery).
Yes! zk.im works on mobile browsers (iOS Safari, Chrome, Firefox). Simply visit zk.im in your mobile browser and connect your wallet. The platform automatically handles HTTPS for secure connections. For the best mobile experience, use a modern browser with WebRTC support. No app installation is required—everything runs in your browser.
zk.im supports any Web3 wallet that can sign messages, including MetaMask, Phantom, WalletConnect-compatible wallets, and hardware wallets (Ledger, Trezor). The platform uses wallet signatures for authentication, so any wallet that supports message signing will work. You don't need a specific wallet—use whatever you already have.
Custom usernames require a one-time registration fee (paid in native blockchain tokens). Visit your profile settings, choose 'Register Username', enter your desired username (3-20 characters, alphanumeric), and pay the registration fee. The username is permanently registered on Arweave, ensuring it's yours forever. Free random usernames are also available if you don't want to pay.
No, both parties need zk.im accounts to communicate. This is because messages are encrypted end-to-end and require both users to have the platform's encryption keys. However, you can invite others to join zk.im by sharing your username or a referral link. The platform is free to use, so inviting friends is easy.
Messages are stored in ZKIM CAS (encrypted) and persist even after closing your browser. When you log back in, your messages will be available. However, you need to remember your username and have access to your TOTP code to decrypt messages. Messages are tied to your account, not your browser session.
Still have questions? Check out our Whitepaper or Blog for more technical details.