Cryptix Messenger

Cryptix Messenger is a real decentralized Layer-1 on-chain messenger with local end-to-end encryption, not a server-based chat platform. Messages are transmitted through blockchain payload transactions, making communication censorship-resistant, unblockable, and unstoppable.

The mission is to protect the right to free communication without surveillance, censorship, or forced identity exposure, with full user anonymity by design. Whether for whistleblowers, privacy-focused users, or private conversations among friends, Cryptix Messenger keeps communication fully in the hands of users.

Messenger Integration

The Messenger is integrated directly into all wallets that are based on the Cryptix Web Wallet. It is available as a dedicated Messenger tab, so users can chat directly inside the wallet without additional applications.

The wallet-native flow also supports group chats. Users can create shared conversations and tip other users directly inside the chat without leaving the messenger.

User Experience

Contacts and Addressing

Messages can be sent using:

• Wallet addresses
• QR codes
• NFC
• Alias names
• Address book entries

Users see alias names or saved contact names instead of handling complex wallet strings. The workflow is intentionally simple and familiar, similar to modern chat apps.

UTXO Address Handling

Unlike account-based blockchains, UTXO wallets use multiple addresses within one wallet identity. New addresses appear through change outputs, privacy-driven address rotation, and transactions that combine multiple UTXOs.

To keep chats consistent, Cryptix Messenger identifies users by their wallet public key, not by a single sending address. No matter which wallet address is used for a transaction or message, all activity is mapped to the same chat identity.

For incoming messages, all wallet addresses remain valid receivers. In the messenger UI, the wallet's legacy (first) address is shown as the primary identifier, while every address belonging to the same wallet stays compatible for message delivery.

Interface

The layout follows a modern messenger pattern:

• Left side: existing chats, search field, and new chat option
• Right side: active chat view with message history
• Group chats: shared encrypted conversations for communities and teams
• Chat tipping: send CPAY tips directly to users from the conversation

Notifications

New messages trigger an audible sound notification. In addition, device and browser notifications are supported, comparable to the existing transaction notification flow.

Delivery Speed

Standard message delivery is about 1 second on average. With HFA Fastchain, near-instant messaging is possible in the range of 50 to 150 ms. Fastchain transactions include additional fees.

Version Scope

Version 1

Version 1 supports text messages only. Message and payload size is currently limited to 2 KB. In encrypted form (including overhead fields), this equals about 1.8 KB usable content, roughly 1800 characters or around 300 words.

Payload flooding is constrained by block size limits and fee mechanics, which prevents unlimited congestion attempts.

Version 2 (Planned)

Version 2 is planned to introduce voice messages and images with increased payload limits. The rollout will follow extensive mainnet stress testing and high-volume transaction simulations.

Fees and Cost Model

Payloads use a 4x higher base fee plus additional costs per byte. Every message therefore has a cost, and larger messages are more expensive.

This keeps payload-based DDoS attacks economically impractical. Extra fees are paid to miners. Fee impact is shown to users in real time while typing.

Security and Anti-Spam

Malicious Content Protection

Explorers and wallet systems only display sanitized content. Malicious inputs such as <script> tags or XSS attacks are automatically cleaned. Tracking methods are also immediately sorted out and filtered. We have considered all conceivable methods and tricks that could be used – including HTML entities. This ensures that no harmful content can be injected and executed in browsers. The messenger and payloads can also be completely deactivated optionally. Alternatively, a whitelist address filter can be used, so that messages are only received from desired people.

User-Controlled Spam Protection

Users have multiple tools to prevent spam:

• Block Button: Addresses can be blocked, preventing any further messages.
• Whitelist Option: Users can choose to receive messages only from approved addresses.

This provides maximum protection and control over incoming communication.

Anti-Spam Incentive Mechanism

Messenger messages require sending a minimum of 0.25 coins (or at least 0.1 to 0.2 coins if bypassed mechanisms apply).

• Every spam message costs the sender money.
• The receiver actually earns coins from spam.

Example: 10 spam messages = 2.5 CPAY earned (currently more than half a block reward). Over time, this becomes extremely expensive for spammers.

Users can even create a dedicated spam wallet, share the address publicly, and check it later while never seeing the spam messages. This effectively turns spam into a benefit.

Anonymity and Privacy

The wallet model is fundamentally anonymous: wallet addresses are not inherently tied to real-world identities, and third parties cannot determine who owns a specific address from the address itself.

In addition, our web wallet servers do not collect personal user data and cannot identify which person uses which wallet or map wallet activity to specific IP addresses.

For maximum privacy, users can run their own node or a fully self-hosted setup (for example via All in One). This removes external dependencies and makes IP-based origin tracking effectively impractical, because observers cannot reliably determine which node originally submitted a transaction.

Messenger content is end-to-end encrypted by design. No node, explorer, service operator, or developer can read plaintext messages. Only sender and recipient hold the keys required to decrypt message content.

Encryption Architecture

Encryption happens directly in the wallet, and transmission to the node is already encrypted.

• Data cannot be intercepted between wallet and node.
• Encryption methods remain flexible and replaceable.
• Developers can build their own messenger systems and encryption standards.

We created a dedicated messenger format to support this flexibility. Initially, encryption at the node level was considered, but client-side encryption proved to be the superior approach.

For the full technical architecture and key flow, see the dedicated messenger encryption reference page.

Optional Payloads and Unencrypted Data

Users can also send payloads and unencrypted messages or data. This is optional and only available in standard transactions.

These are not encrypted and are intended for:

• Payment notes (for example, transaction descriptions)
• Future use cases such as custom payloads triggering node behavior (for example, smart contract functionality)

Responsible Use Notice

Cryptix Messenger is built for lawful and legitimate communication and is not intended for criminal activity.

We cannot read private messages because message content is encrypted end-to-end by design. However, if there is credible suspicion of severe criminal misuse, we will use every available measure within the technical and legal scope to help prevent and limit such abuse.