# Bitmail: A Decentralized Privacy-Preserving Messaging Protocol

Abstract – We propose Bitmail, a peer-to-peer encrypted messaging protocol that leverages blockchain and distributed storage to achieve end-to-end secure email-like communication without trusted servers. Bitmail is motivated by the shortcomings of traditional email: a large fraction of global email is spam or phishing, and much of it traverses the internet without strong encryption [1][2]. Conventional email’s reliance on centralized servers and opportunistic TLS means that messages (and their metadata) can be intercepted or surveilled, and subject lines and other headers remain exposed [3].

Bitmail addresses these issues with a novel architecture: message content is encrypted with the recipient’s public key and stored off-chain (e.g., on IPFS), while a short encrypted hashlink pointing to that content is itself encrypted to the recipient’s public key and published on a Cosmos-SDK blockchain. Only the intended recipient can decrypt this on-chain pointer to retrieve and decrypt the actual message, preventing third parties from reading or even identifying the communication.

Using a dedicated Cosmos-based blockchain for Bitmail provides low-cost, high-throughput transaction processing, avoiding the congestion and fees of general-purpose networks [4]. Every Bitmail message is an on-chain transaction, which inherently requires the sender to spend a small fee, creating an economic disincentive for spam. We describe the Bitmail protocol in detail, including its encrypted hashlink transaction design (EHL transactions), the integration of distributed storage backends (IPFS by default), and the client application layer for key management, identity discovery, and inbox management.

We analyze how Bitmail achieves privacy (strong encryption, no third-party access to content), security (censorship-resistance and spam mitigation via fees), and discuss potential threats and mitigations. Bitmail is not a mere clone of email nor a general file-sharing system – it represents a new class of communication protocol optimized for confidentiality and resilience against surveillance and censorship.

# 1. Introduction

Email is one of the most ubiquitous communication methods, with over 300 billion emails sent every day [5]. Yet the email ecosystem suffers from severe privacy and security issues. A substantial portion of all email traffic consists of unsolicited or malicious messages: recent surveys indicate roughly 45–56% of global emails are spam [1], amounting to around 160 billion junk messages sent daily [1].

Phishing – emails designed to impersonate trusted senders and deceive recipients – is also rampant. By 2025 phishing emails made up an estimated 1.2% of all email traffic (over 3.4 billion fraudulent emails per day), contributing to over a trillion phishing messages each year [2]. It is therefore no surprise that email remains the top attack vector for cybercrime; an estimated 94% of cyberattacks originate from malicious emails [5], through phishing links or malware-laden attachments.

Beyond spam and phishing, traditional email has inherent privacy weaknesses. The original email protocols (SMTP, IMAP, POP3) were not designed with end-to-end encryption. While Transport Layer Security (TLS) encryption is now used opportunistically to protect emails in transit between mail servers, it is not universal – as of early 2025 about 90% of Gmail-to-provider emails were sent over encrypted channels, leaving the remainder (tens of billions of messages daily) in plaintext [6].

More critically, true end-to-end encryption (where only sender and recipient can read the content) is extremely rare in email. Services like Gmail and Outlook generally can access the content of emails, and standard emails stored on servers can be read by those providers or anyone who gains access. PGP or S/MIME can provide end-to-end encryption, but they are cumbersome and barely used by the general public (and even when used, the metadata like sender, recipient, and subject line remain exposed in email headers [3]).

This means that today, a large fraction of email correspondence is either outright unencrypted or only protected in transit, leaving it vulnerable to storage hacks, service provider surveillance, and government subpoenas or censorship. These realities highlight the need for a new approach to digital messaging – one that inherently assures confidentiality, integrity, and resistance to spam and surveillance.

In this paper, we present Bitmail, an end-to-end encrypted messaging protocol built on a decentralized infrastructure. Inspired in spirit by the design philosophy of Bitcoin (removing reliance on centralized intermediaries), Bitmail replaces the role of email servers with a combination of a blockchain ledger and distributed storage network. Bitmail’s design goals include:

Privacy: Only senders and intended recipients can read messages. Bitmail achieves this by encrypting messages with the recipient’s public key and by also encrypting any message references or metadata that are posted to the network. No third-party (not even blockchain validators or storage nodes) can decrypt the content or even discern the subject or context of the communication.
Spam and Abuse Mitigation: Unsolicited bulk messaging is discouraged at the protocol level by requiring a small fee per message (recorded as a blockchain transaction). Unlike email, where sending millions of messages is virtually free for spammers, Bitmail’s use of on-chain transactions imposes a cost on every message. The use of per-recipient encryption of message pointers also means there is no global “directory” of addresses to scrape for targets, further reducing spam susceptibility.
Censorship Resistance: There is no central server or authority that can arbitrarily block or filter Bitmail messages. Message metadata (encrypted pointers) are stored on a Cosmos SDK blockchain that is maintained by a distributed network of validators, making it tamper-evident and resilient to takedown. The actual message contents are stored in decentralized content-addressable storage (IPFS by default), which has no single point of failure. This design makes Bitmail communication difficult to censor – an adversary would have to censor the entire global network or blockchain rather than simply pressure an email provider.
End-to-End Security with Familiar Usability: The Bitmail client application provides a user experience analogous to email (with features like inbox management, contacts, subject lines, etc.) but under the hood it operates as a crypto wallet and secure messenger. Keys are managed by users (each user has a public/private keypair like a blockchain account), and message encryption/decryption is handled automatically. Bitmail is not intended to interoperate with legacy email protocols; instead it reimagines “electronic mail” as a blockchain-based protocol that prioritizes security. It is likewise not a general file sharing network – while it does transfer files (messages and attachments) via IPFS, these are tied to communications between known parties rather than public file distribution.

In the following sections, we detail Bitmail’s architecture and components. Section 2 provides a technical overview of the Encrypted Hashlink scheme and the overall system architecture, including the role of the Cosmos SDK blockchain and IPFS storage. Section 3 discusses the rationale for choosing a Cosmos SDK blockchain over an Ethereum-based solution, comparing aspects like fees, throughput and design flexibility. Section 4 offers a step-by-step protocol walkthrough of how a message is sent from Alice to Bob in Bitmail, illustrating the encryption and transaction flow. Section 5 analyzes potential threats and attack vectors – from spam and denial-of-service to metadata analysis – and how Bitmail’s design mitigates them. We conclude with a discussion of Bitmail’s significance as a new class of private communication protocol, distinct from both traditional email and existing blockchain messaging apps.

# 2. Bitmail Architecture Overview

Bitmail can be viewed as a three-layer architecture comprising:
(a) an on-chain transaction layer (the Bitmail blockchain) that handles message metadata and routing via encrypted pointers;
(b) an off-chain storage layer (the “vaults” such as IPFS) that holds the encrypted message payloads; and
(c) an application layer (Bitmail client software) that provides the user-facing interface, key management, and encryption/decryption operations.

In this section we describe each component and the novel Encrypted Hashlink mechanism tying them together.

# 2.1 Encrypted Hashlinks on the Blockchain

At the core of Bitmail is the concept of the Encrypted Hashlink (EHL). An encrypted hashlink is essentially a reference (content hash) to a message that is stored off-chain, with the twist that this reference is encrypted such that only the message’s intended recipient can decrypt it. The Bitmail blockchain is used to record these encrypted hashlinks as transactions, thereby serving as a decentralized mail delivery ledger.

Concretely, when a user Alice wants to send a message to Bob, the Bitmail application will create a special transaction – call it a MsgCreateHashCid transaction – on the Bitmail blockchain. This transaction contains the following fields: creator (Alice’s address), receiver (Bob’s address), hashlink (the encrypted reference to the message content), and vaultID (an identifier for which storage backend holds the content). The hashlink is the centerpiece: it holds an encrypted content identifier (CID) that points to the actual message data stored in the IPFS network (or other storage vault). Because this CID is encrypted with Bob’s public key, only Bob can recover it and learn where the content resides. Anyone observing the blockchain sees only an opaque blob of data for the hashlink field – they cannot discern the content hash or any message details from it.

On-Chain Delivery Mechanism: By posting the encrypted hashlink on-chain, Bitmail ensures delivery in a decentralized manner. The blockchain acts as a globally accessible (and append-only) bulletin board for new messages. Bob does not need to be online at the exact moment Alice sends the message; whenever Bob next checks the Bitmail blockchain (via his Bitmail client), he can scan for transactions addressed to his account. If a transaction’s receiver matches Bob’s address, Bob’s client will fetch the encrypted hashlink from that transaction and attempt to decrypt it with Bob’s private key. Upon successful decryption, Bob obtains the content hash (CID) of the message.

Notably, because the receiver field is stored in plaintext (as a blockchain address) to allow efficient routing, observers of the blockchain can see which Bitmail addresses are communicating. (We discuss metadata privacy in Section 5.) The content of the communication, however – including the message text, attachments, and even the subject line – is never posted in the clear. Those remain encrypted in the off-chain payload, which only Bob can retrieve and decrypt.

Spam Prevention via Costs: Every Bitmail message transaction requires paying a small transaction fee in the Bitmail blockchain’s native currency (a token often denoted as BMTL, with a micro-denomination like “ubtml” used for fee accounting). This fee is deliberately set low for normal use (on the order of fractions of a cent or less), so that users sending individual messages will hardly notice it, but it presents a hurdle to would-be spammers. To flood users with unwanted messages, an attacker would need to acquire and spend tokens for each on-chain transaction. The decentralized network of validators will include the transactions only if the fee is provided, and there is no way to send “free” messages outside of the chain.

This economic model is akin to requiring a postage stamp for each letter – trivial for genuine users, but prohibitive for mass spam operations, especially when combined with the fact that valid recipient addresses are not easily guessable. In Bitmail, addresses are essentially cryptographic public keys (e.g., Cosmos-style addresses), which are long random strings. Spammers cannot enumerate all possible addresses in use in order to target victims the way they scrape email addresses; they would at best see some addresses on the public chain and could try sending to those, burning fees each time.

Moreover, because each hashlink is encrypted to its recipient’s key, a spammer cannot compose one generic message and broadcast it widely – they would have to create a distinct transaction (and perform encryption) separately for each target. These measures make large-scale unsolicited messaging economically and computationally inefficient.

Comparison to Ethereum-based Messaging: Notably, storing message pointers on a purpose-built Cosmos SDK blockchain affords Bitmail much more flexibility and efficiency than trying to piggyback on a general network like Ethereum. In Ethereum-based messaging dApps, one might use smart contracts or logs to announce messages, but doing so on Ethereum Mainnet would incur high gas costs and expose all message references to the public. Some projects (e.g., Ethereum’s Whisper protocol) attempted off-chain relay with proof-of-work to throttle spam [7], or use mailboxes that are publicly readable (with or without encryption). By contrast, Bitmail’s on-chain pointers are individually encrypted per recipient, preventing any third-party from even identifying the content address. There is no “open mailbox” to scrape, and no need for inefficient proof-of-work puzzles – the blockchain’s native fee and the encryption serve as the anti-spam mechanism. We elaborate in Section 3 on why a dedicated Cosmos chain is chosen over Ethereum, and in Section 5 on how Bitmail thwarts spam and snooping by design.

# 2.2 Off-Chain Encrypted Storage (IPFS and Vaults)

While the Bitmail blockchain stores the tiny encrypted pointers, the bulk data of messages (the actual content) is stored off-chain in one or more decentralized storage “vaults.” By default, Bitmail uses IPFS (InterPlanetary File System) as its primary storage layer. IPFS is a distributed, content-addressable storage network ideal for Bitmail’s needs: when Alice uploads an encrypted message to IPFS, she receives back a Content Identifier (CID), which is a cryptographic hash of the file. This CID serves as a locator for the content on the IPFS network – any node with the CID can retrieve the corresponding data from IPFS peers.

Because IPFS is content-addressed and peer-to-peer, the message data is not reliant on any single server; multiple nodes can hold or cache the content, and it can be fetched from any of them using the CID. In Bitmail, all message payloads are encrypted before being uploaded to IPFS. The Bitmail client concatenates the Subject and Body of the email (and any attachments, which can be included as binary data or links) into a single plaintext package, then encrypts this package symmetrically with a random key, which is in turn protected by the recipient’s public key (using hybrid ECIES-style encryption). The result is an encrypted blob that only the recipient can decrypt with their private key.

Alice’s Bitmail client, after encryption, adds the content to IPFS via an API call. It then obtains the content’s CID (a hash like Qm... in IPFS). This CID is what needs to be communicated to Bob – but rather than send it in plaintext (which would reveal which IPFS hash is of interest), the CID is encrypted with Bob’s public key as described above, and only that encrypted form (the hashlink) goes onto the blockchain.

In effect, IPFS provides a shared storage medium for Bitmail, while the blockchain provides the access control and notification mechanism (since only Bob can unlock the pointer to the IPFS content).

One important design feature of Bitmail is that it is storage-backend agnostic. The architecture is modular such that different content storage networks or methods can be plugged in as “vaults.” The vaultID field in the message transaction can indicate which storage is used (e.g., 0 for IPFS public network, 1 for a private IPFS cluster, 2 for a BitTorrent magnet, etc.). In the current Bitmail implementation, IPFS is the default and vaultID is left blank or zero, but the protocol could be extended. For example, an enterprise could run a private IPFS or Swarm network for internal messages and specify that as the vault, or users could choose to redundantly store messages on multiple networks for robustness. The Bitmail client would then use the appropriate driver to upload/download from the specified vault. This flexibility ensures that Bitmail is not tied to one storage network’s fate; it can ride on future decentralized storage tech as they emerge, or even support hybrid models (like storing small messages on-chain directly if needed, or using cloud storage with encryption as a fallback in some scenarios).

Message Persistence and Retrieval: When Bob receives an encrypted hashlink from the blockchain, his Bitmail client will decrypt it to get the CID, then fetch the content from IPFS. The client either connects to the IPFS network (running a local node or using a gateway) and retrieves the data by CID. Because the data is content-addressed, Bob doesn’t need to know who stored it – the network will deliver the file as long as at least one node (likely Alice’s node, and perhaps other IPFS peers) is hosting it.

To improve reliability, Alice’s Bitmail app caches the message locally and keeps it pinned on IPFS for some time. The Bitmail client can also cache messages on the recipient side (Bob’s device) for offline reading [8]. Bitmail thus has an “offline-first” capability: once Bob has downloaded and decrypted a message, it is stored in his local encrypted datastore, allowing him to read it later even without internet connectivity [8].

If a message payload is not available on IPFS when Bob tries to get it (perhaps because no node is currently hosting it), the Bitmail client will flag the message as temporarily unavailable. The design assumes senders will remain online to seed recent messages, and in practice IPFS content often propagates to a few nodes. In a worst-case scenario where content is lost (e.g., the sender went offline immediately and no other node has it), Bob would see an indicator that the message is no longer available. This scenario is akin to an email server deleting an email before the recipient fetched it – except in Bitmail it would be due to lack of persistence on the storage network. Users may mitigate this by running IPFS nodes that mirror their inbox or by integrating a more persistent storage vault.

Future enhancements to Bitmail could include redundancy strategies (e.g., storing multiple encrypted copies on different IPFS nodes or networks).

# 2.3 Application Layer: Wallets, Identities, and Inbox Management

To ordinary users, Bitmail is experienced via an application that looks and feels like a secure email client combined with a cryptocurrency wallet. The Bitmail client app (available for desktop on Windows, macOS, Linux [8][8]) is essentially a crypto wallet specialized for messaging.

When first launched, the user creates or imports a wallet – this generates a public/private keypair (for the underlying Cosmos-based blockchain account) which serves as the user’s Bitmail identity. In Bitmail’s beta, the address format is like a typical Cosmos SDK address (e.g., starting with a prefix like btml1...). This address is the “Bitmail address” that users exchange with each other to be able to send messages. The client provides a QR code and address string that can be shared for others to add you as a contact [8].

For convenience, Bitmail allows users to set a username and avatar in their profile [8], which their contacts will see in the app (this is purely local/visual, the blockchain itself doesn’t record human-readable usernames globally in the current design).

The Bitmail app handles key management and encryption transparently. All messages are encrypted/decrypted locally; the private key never leaves the user’s device. To send a message, the app looks up the recipient’s address (either entered manually or chosen from contacts) and then fetches the recipient’s public key. In Cosmos SDK, an account’s public key can be obtained from the chain’s state (once the account has appeared in a transaction) via an API query.

The Bitmail client does this automatically: it contacts a Bitmail blockchain node (via REST or RPC) to retrieve the account info for the recipient address, extracting the pub_key. Using this public key, the app encrypts the message content and the hashlink as described earlier.

Likewise, on receiving, the app uses the user’s own private key to decrypt hashlinks and content.

From a UI/UX perspective, users see an inbox of messages similar to an email inbox. Each message shows the sender’s name (or address), the subject line, and perhaps a snippet of the body. This is made possible because once the Bitmail app downloads and decrypts a message, it stores the plaintext subject and body in a local database (typically indexed by the message’s transaction ID or hash) for quick reference. The messages are marked as “downloaded” so that the app knows it has the content.

Users can click to read the full message, which shows the body text (decrypted) and any attachments. Attachments can be handled by storing them within the encrypted payload (e.g., as base64 data or separate IPFS CIDs listed in the message body). The Bitmail app could fetch those similarly via IPFS and decrypt if needed.

The client also supports typical email management actions: delete, recover, etc. Deleting a message in Bitmail means the app will mark it as deleted in the local cache (and optionally purge the content). Because Bitmail does not have a central server, “recall” or true deletion from the network is tricky – once on the blockchain, the pointer is immutable, and if the content remains on IPFS it could still exist. However, users can choose to delete the local copy and even issue a special transaction to indicate a message deletion (for example, a future extension could let the sender or receiver post a tombstone that instructs others not to retain the content). For now, deletion is mostly a local operation (the Bitmail app hides or wipes the message content on the user’s device).

The Bitmail app’s Features list includes the ability to delete and recover messages [8], which suggests that deleted messages are kept in a trash folder (marked with a deleted status) and can be restored if needed.

Another key aspect is automatic synchronization: the Bitmail app will periodically poll or subscribe to the Bitmail blockchain for new transactions involving the user’s address [8]. New message transactions are synced and added to the inbox in near real-time (depending on block times, which are on the order of seconds). Because the blockchain is the source of truth, a user can potentially log in from another device (importing the same private key) and retrieve all their messages by scanning the chain’s history for transactions to them. The local app maintains a cache so it doesn’t re-download content it already has.

In summary, the application layer wraps the cryptographic and blockchain machinery in a familiar messaging interface. Users manage contacts (mapping human labels to Bitmail addresses), compose messages with a subject and body, and hit Send – the app then takes over to encrypt the content, upload to IPFS, and broadcast the on-chain pointer. When opening the app, it automatically checks for any new incoming encrypted hashlinks (new “mails”) and retrieves them for the user. The entire process avoids any third-party mail server: Bitmail uses a combination of blockchain + distributed storage as a decentralized email server, and public-key cryptography instead of the SMTP trust model.

# 3. Design Rationale: Cosmos SDK vs. Ethereum

A critical architectural decision in Bitmail is the choice to implement the on-chain layer as a sovereign Cosmos SDK blockchain (the Bitmail chain), rather than as a smart contract or dApp on an existing blockchain like Ethereum. We justify this choice along several dimensions: cost, performance, modularity, and privacy.

# 3.1 Transaction Fees and Cost Predictability

One of the biggest advantages of Cosmos for Bitmail is the low and predictable transaction fees. Cosmos SDK chains typically have minimal fees (often fractions of a cent) and can be configured by the application. In contrast, Ethereum’s fees (gas prices) have historically been volatile and often high, especially during network congestion. For example, during busy periods, sending a simple transaction on Ethereum can cost from a few dollars to tens of dollars in fees, which would be impractical for a messaging system.

Bitmail requires that sending a message be extremely cheap (ideally on the order of $0.0001 to $0.001) to encourage daily use and global adoption. By using its own Cosmos-based chain, Bitmail can ensure fees remain low; the Bitmail chain is not competing with DeFi trades, NFT mints, or other unrelated traffic that drive Ethereum fees up. Validators in the Bitmail network only process Bitmail message transactions, and the fee parameters can be adjusted via governance to suit the messaging use case (e.g., targeting a stable cost per message). Lower fees remove a barrier to entry and make the cost for legitimate use negligible, while still imposing a tiny cost to deter mass-spam attacks.

# 3.2 Throughput and Scalability

A dedicated Cosmos chain offers higher throughput for Bitmail transactions than an L1 like Ethereum. Ethereum (pre-sharding) handles on the order of ~15–30 transactions per second (TPS) on its base layer, and even with recent upgrades it can become congested with a few high-demand dApps. Cosmos SDK chains, on the other hand, can routinely handle hundreds of TPS since they are application-specific and use efficient BFT consensus (Tendermint/CometBFT). In addition, multiple Cosmos zones can run in parallel.

Bitmail has the potential to generate a very high volume of small transactions (each message is a transaction). For example, if Bitmail were to serve even 1% of global email volume, that could be billions of messages per day, far exceeding Ethereum’s capacity. While Bitmail may not need to reach that extreme scale immediately, the architecture should not impose a hard ceiling far below the target. Cosmos’s high scalability through interconnected zones or sidechains means Bitmail could scale out if needed (spinning up additional chains or sharding by user groups), whereas on Ethereum it would be constrained by the shared global throughput.

In short, Cosmos gives Bitmail room to grow. Even under load, the Bitmail chain can process messages without contending with unrelated apps. This translates to consistent latency (e.g., ~5–6 second block times for Cosmos vs. ~12 seconds on Ethereum and potentially slower when congested) and consistent throughput. Ethereum’s well-known congestion issues – high fees and slow confirmation during ICO booms or NFT drops – would severely degrade user experience for a messaging app. Cosmos avoids those issues by design [4].

# 3.3 Modularity and Customization

Building on Cosmos SDK allowed us to tailor the blockchain logic precisely to Bitmail’s requirements. The Cosmos SDK is a framework for building application-specific blockchains, where developers can create custom modules for their transaction types and state [4].

We created a custom module for Bitmail Encrypted HashLink transactions (the ehl module) rather than writing a smart contract in Solidity. This has several benefits:

Native performance and security: The message logic runs as compiled Go code at the blockchain level, avoiding the extra gas costs and potential inefficiencies of an on-chain VM (like the EVM). There is no risk of our message processing hitting the arbitrary gas limits or being impacted by changes in gas costs for opcodes, etc. We know exactly the cost of a MsgCreateHashCid (just enough to write a small blob to the chain state).
Governance and upgrades: As the chain developers, we have control to upgrade the Bitmail blockchain (through Cosmos’s governance or coordinated updates) to add features like new vault types, improved cryptography, etc. On Ethereum, upgrading a dApp can be complex and limited (one might be stuck with an upgradeable contract pattern or deploy new contracts and migrate users). Cosmos gives Bitmail “full-stack” control – we can even modify consensus parameters, block size, etc., to optimize for messaging data patterns.
Independence and Interoperability: The Bitmail chain can operate independently but also join the wider Cosmos ecosystem through Inter-Blockchain Communication (IBC) if desired. This means in the future Bitmail could interoperate with other chains (for instance, to accept tokens from other chains for fees, or to log transactions to other hubs for redundancy). Ethereum, being a single network, doesn’t offer the same out-of-the-box interoperability that Cosmos’s multi-chain architecture does [4]. While interoperability is not a primary requirement for Bitmail initially, Cosmos provides that pathway (Bitmail could be one “zone” in the Internet of Blockchains).

# 3.4 Avoiding Ethereum’s Privacy and Spam Issues

Existing Ethereum-based messaging solutions demonstrate some challenges that Bitmail’s approach avoids. For example, some “Web3 email” projects store messages or notifications in smart contract storage or events that are visible to all – relying on encryption to hide content, but often leaving metadata or at least the existence of a message visible to everyone.

If Bitmail were implemented as an Ethereum contract, every message’s ciphertext or content hash might be publicly logged on-chain. This could allow attackers to perform traffic analysis (e.g., seeing when and how often a particular address receives messages, even if they can’t read them easily). In Bitmail’s design, although the Bitmail chain is public, it is solely dedicated to messaging, and the encrypted hashlinks are opaque blobs that do not reveal even a content hash or meaningful identifier to an outsider.

By controlling the entire stack, we have also implemented recipient-specific encryption: each message pointer is encrypted to one recipient’s key, rather than, say, a static encryption or a key shared by many. This means only the intended recipient can detect and read their messages – an eavesdropper can’t even brute-force decrypt messages not intended for them without breaking the underlying cryptography (which is assumed secure, e.g., using ECIES over Curve25519 or secp256k1).

Ethereum’s general-purpose design did not provide an easy way to hide metadata like the recipient address or content hash within a transaction – everything in a public mempool is visible. Some Ethereum messaging protocols like Whisper attempted to address metadata leakage by broadcasting messages to all nodes with topics and using proof-of-work for spam control [7], but this resulted in a very inefficient system (every node processing lots of irrelevant messages, mobile-unfriendly due to PoW, etc.) and Whisper never achieved widespread use.

Bitmail’s approach of using a blockchain plus per-message encryption strikes a balance: the network only stores minimal necessary info, and the heavy lifting of routing is done by the blockchain in a targeted way (via the receiver address field), with encryption ensuring privacy. Meanwhile, Cosmos’s low fees and uncongested environment mean that requiring a transaction per message is feasible, whereas on Ethereum that would have been cost-prohibitive.

In summary, Cosmos was chosen over Ethereum because it enables orders-of-magnitude lower fees, higher throughput, and a purpose-built implementation aligned with Bitmail’s privacy goals. Ethereum-based dApps in the messaging space often compromise on one of these aspects: either they run off-chain (thus re-introducing some centralization or requiring separate nodes, as with Mailchain’s off-chain storage [5]), or if on-chain they suffer from cost/scale issues. Bitmail’s Cosmos-SDK blockchain avoids Ethereum’s bottlenecks and gives Bitmail the freedom to evolve its protocol on its own terms. This choice makes Bitmail more akin to Bitcoin in spirit – an independent network for a specific purpose – rather than just another DApp fighting for resources on a general chain.

# 4. Protocol Walkthrough: Sending a Message with Bitmail

To illustrate how Bitmail works end-to-end, we provide a high-level walkthrough of a typical message exchange. Consider two users: Alice (the sender) and Bob (the recipient). Both have installed the Bitmail application and created wallets, obtaining their Bitmail addresses (public keys). Let’s assume Alice and Bob have added each other as contacts (Alice knows Bob’s Bitmail address, possibly via scanning a QR code or Bob sharing it out-of-band).

# 4.1 Composing and Encrypting the Message

Step 1: Alice Prepares the Message
Alice writes a new message to Bob in her Bitmail client – similar to composing an email. She enters Bob’s address (or selects his name from her contacts, which inserts the address), fills in a subject line (e.g., “Project Update”) and the body of the message, and attaches any files if desired. When Alice hits “Send,” the Bitmail app begins the secure sending process [8].

Step 2: Fetch Bob’s Public Key
Alice’s app needs Bob’s public key to encrypt the content for him. If Alice doesn’t already have Bob’s pubkey cached, the app will query the Bitmail blockchain for Bob’s account info. Bitmail (being Cosmos-based) exposes an API where one can GET an account by address and retrieve fields including the public key if the account has been initialized on-chain.

Suppose Bob has used Bitmail (or at least received the faucet funding) so that his account is known; the query returns Bob’s public key in base64 encoding. If for some reason Bob’s key is not found (maybe Bob never came online to initialize, which is rare since even the faucet or first message would usually do so), the send would error out until Bob has a public key on chain. In practice, the Bitmail faucet or Bob sending any transaction would register his pubkey.

Step 3: Encrypt the Message Content
Alice’s Bitmail app now encrypts the email content using Bob’s public key. The implementation uses an ECIES (Elliptic Curve Integrated Encryption Scheme) approach: under the hood, a symmetric encryption (like AES-256) is used with a random key, and that key is itself encrypted with Bob’s public key (Curve25519 or secp256k1, depending on Bitmail’s crypto library) to produce an output that Bob can reverse.

In code, the app constructs a single plaintext string containing the subject and body (e.g., "Subject: Project Update\n\n<message body text>"). Then it calls the encryption routine with Bob’s public key, producing an encrypted message object consisting of: an initialization vector (IV), an ephemeral public key (for the Diffie-Hellman exchange), the ciphertext, and a MAC (authentication tag). All these components are encoded (typically in base64 JSON) to form the final encrypted payload. Let’s call this blob EncMsg. At this point, EncMsg is a chunk of data that only Bob’s private key can decrypt. It effectively functions as a sealed envelope containing Alice’s message.

Step 4: Upload Encrypted Content to IPFS
Next, Alice’s app connects to the IPFS network (either via a local node or a remote API). It adds the encrypted message EncMsg to IPFS. IPFS will store the content among its nodes and return a Content Identifier (CID), which is a hash (e.g., QmX...) uniquely representing that data. This CID is essentially a pointer that Bob (or anyone with it) could use to retrieve EncMsg from IPFS.

In our example, suppose the CID is Qm123...ABC. At this moment, the encrypted message is distributed in the IPFS system (and usually also cached in Alice’s IPFS node). However, only Alice has knowledge of the CID so far.

Step 5: Encrypt the CID (Hashlink)
Now comes Bitmail’s critical innovation: Alice will not send the CID in plaintext to Bob; instead, she encrypts the CID itself with Bob’s public key. Using Bob’s pubkey again, the app performs an ECIES encryption on the string "Qm123...ABC" (the CID). This yields another encrypted blob – call it EncCID. This EncCID is formatted similarly (IV, ephemeral key, ciphertext, MAC), and we refer to it as the encrypted hashlink or EHL. It’s essentially an envelope that contains the content’s location, locked to Bob’s key. Only Bob can open this envelope to learn the CID of the message file.

# 4.2 On-Chain Transaction Submission

Step 6: Construct the Message Transaction
Alice’s Bitmail app now creates a blockchain transaction to deliver the encrypted hashlink to Bob. The transaction is of type MsgCreateHashCid (from Bitmail’s custom module) and includes the fields:

creator = Alice’s address
receiver = Bob’s address
hashlink = EncCID
vaultid = 0 (for IPFS)

Essentially, the transaction is saying: "Alice (creator) is sending a message to Bob (receiver); the message’s content is stored in vault 0 (IPFS) and here is the encrypted pointer to it." The size of EncCID is small (just a couple hundred bytes since it’s an encryption of a hash), so the transaction remains lightweight.

Step 7: Sign and Broadcast
Alice’s app signs the transaction with her private key (just like signing any blockchain tx) and then broadcasts it to a Bitmail blockchain node. The transaction enters the Bitmail mempool and is soon included in a block by the validators. Within a short time (a few seconds), the transaction is confirmed on-chain.

At this point, the “sent mail” is essentially delivered to Bob’s on-chain mailbox. It’s worth noting the fee: the app attaches a small fee, say 100 ubtml (micro-BMTL), which might correspond to 0.0001 BMTL token. This fee is deducted from Alice’s account (which is why Alice needs a tiny amount of BMTL, funded via faucet or transfers, to send messages). If Alice tried to spam many messages without sufficient balance, the transactions would not be processed.

The Bitmail blockchain’s state now has a record of the message (likely as part of a module store or log). The presence of receiver = Bob in the transaction means Bob (or anyone) can query the chain for transactions directed to Bob’s address. From Alice’s perspective, once the transaction is confirmed, the Bitmail app may show the message as “Sent”. Alice can move on; her job is done. She will keep the encrypted content on IPFS at least until she believes Bob has fetched it (and possibly longer for backup). The content is only a few kilobytes (or more if attachments), so storing it is not a burden.

# 4.3 Retrieval and Decryption by the Recipient

Step 8: Notification of New Message
Bob’s Bitmail app, if online, will become aware of the new transaction relatively quickly. There are two possibilities:
(a) Bob’s app is actively polling the blockchain (via an API or by being a light client) and sees the new transaction for his address, or
(b) Bob’s app was offline and will catch up next time it syncs.

Assuming Bob is online, the app sees “Tx from Alice to Bob with an EncCID” in the latest block. The Bitmail app then adds a placeholder in Bob’s inbox: a new message entry from Alice, with the subject unknown yet (since it’s inside the encrypted content), possibly marked as unread and not downloaded.

Step 9: Decrypting the Hashlink (CID)
To actually retrieve the message, Bob opens it (or the app may auto-download new messages). The app takes the hashlink field from the transaction, which is EncCID (the encrypted CID), and uses Bob’s private key to decrypt it. This yields the plaintext CID, e.g., Qm123...ABC. Now Bob’s device knows where the encrypted message content resides in IPFS. The app confirms this step by checking the integrity (the MAC) – if decryption fails or the data is corrupted, it would indicate an issue, but normally it succeeds and Bob obtains a valid CID.

Step 10: Fetching from IPFS
Given the CID, Bob’s Bitmail app contacts IPFS to retrieve the content. This might involve either Bob’s node directly connecting to IPFS or using a gateway or the sender’s node (Bitmail can have fallback strategies). The app makes a request for the content identified by Qm123...ABC. If the content is available on the network, IPFS returns the data – which is EncMsg, the encrypted message payload that Alice originally uploaded.

The Bitmail app receives this encrypted blob (likely as a JSON string with the fields iv, ephemeral key, ciphertext, mac).

Step 11: Decrypting the Message Content
Finally, Bob’s app uses Bob’s private key to decrypt EncMsg. The process is similar to step 9 but now applied to the larger payload: the app parses the JSON, and calls the decrypt function with Bob’s key and the given IV, ephemeral public key, ciphertext, and MAC. The result is the original plaintext that Alice composed – which starts with "Subject: Project Update\n\n...". The app splits this into the Subject and Body. Now Bob can read the subject “Project Update” and the body content.

The Bitmail client will display these to Bob and mark the message as downloaded/deciphered. The message is now in Bob’s possession, in plaintext form (though typically the app would store it securely on disk). Bob can reply to Alice by composing a new message back to her address, which would go through the same steps in reverse.

Throughout this process, the confidentiality of the message was never broken. The content was encrypted at Alice’s end before leaving her device, and it stayed encrypted in transit (both on the blockchain as EncCID and on IPFS as EncMsg) until Bob decrypted it on his device. At no point could an intermediary read the message. The blockchain nodes saw only an unintelligible blob in the transaction. IPFS nodes storing the file saw only encrypted gibberish. Even if someone collated all data (the EncCID from the chain and EncMsg from IPFS), without Bob’s private key they could not link them or decipher the message.

In essence, Bitmail achieves true end-to-end encryption using the receiver’s public key, and uses the blockchain as a secure routing table and IPFS as a storage medium, without exposing sensitive data.

Bandwidth and storage efficiency: Each Bitmail transaction is small (only the encrypted hashlink, typically a couple of hundred bytes of JSON, plus addresses). The heavy payload (which could be kilobytes or even megabytes with attachments) is offloaded to IPFS. This keeps blockchain bloat minimal – Bitmail’s chain grows primarily by a few hundred bytes per message, not by the full content of messages. IPFS usage means storage scales with content, but users only download what’s addressed to them. If Bob doesn’t receive some messages, he never pulls those from IPFS. Meanwhile, IPFS naturally deduplicates content: if the exact same file were sent twice (rare for encrypted content because of random salts, but attachments might be identical), IPFS stores it once. And users can delete or not pin old content if space is a concern, knowing the blockchain still holds the pointer if needed.

# 4.4 Not a Clone of Traditional Email, But a New Paradigm

It is worth reiterating that while we describe Bitmail messages with terms like “Subject” and “Body” for familiarity, Bitmail is not simply a clone of SMTP/IMAP email on a blockchain. Many conventional email features (CC/BCC, forwarding, mailing lists, etc.) are not directly part of the base Bitmail protocol, though some could be built on top.

Bitmail’s philosophy is closer to sending a secure direct message or postal letter than to the open-routing model of email. Each message is a discrete object addressed to a specific recipient (or multiple recipients could be supported by encrypting the same CID to multiple public keys and sending multiple transactions – effectively sending separate copies). There is no notion of a spam folder or an email provider doing filtering – unwanted messages would simply be those from unknown addresses, which a user can ignore (and the cost to send them acts as a natural filter).

Nor is Bitmail a general file-sharing system: while one could send large files as attachments via Bitmail (subject to IPFS handling and perhaps splitting them), it is optimized for person-to-person encrypted communication, not for publishing content to the world.

Bitmail, in summary, demonstrates a new class of communication protocol that marries blockchain’s distributed trust model with strong cryptography to provide an encrypted, censorship-resistant email alternative. In the next section, we examine the security of this design and potential attack vectors, to verify that these claims hold under scrutiny.

# 5. Security Considerations and Potential Attacks

Bitmail’s design significantly improves privacy and security for messaging, but it is not immune to all attacks. Here we discuss the threat model and how Bitmail stands up to various challenges:

# 5.1 Eavesdropping and Unauthorized Content Access

By design, Bitmail should prevent any unauthorized party from reading message content. The encryption used for both message payloads and hashlinks is strong (assuming standard elliptic-curve cryptography and AES ciphers). An attacker on the network could intercept the transaction and the IPFS transfer, but would only see ciphertext. The blockchain provides integrity (transactions can’t be undetectably altered) and the encryption provides confidentiality.

Even if an attacker compromises a subset of blockchain validators or IPFS nodes, they gain nothing without the recipients’ private keys. This is a major improvement over email, where an attacker compromising an email server or sniffing a non-TLS connection could read all emails passing through. In Bitmail, only the recipient’s private key can decrypt the content.

Thus, eavesdropping is effectively thwarted barring a break in the crypto (e.g., a future quantum computer could be a threat to ECC, but that is outside our scope, and mitigations would involve upgrading to quantum-resistant encryption in a future version).

# 5.2 Metadata Leakage and Traffic Analysis

Bitmail does not hide all metadata. The most visible metadata is the sender and recipient addresses on the blockchain. Anyone observing the Bitmail chain can see that “address X sent a message to address Y at time T”. If those addresses can be linked to real identities (say Alice posts her Bitmail address publicly, and Bob’s address is known), then an observer learns that Alice communicated with Bob at that time. They don’t know the content or subject, but they know communication occurred.

This is analogous to how Bitcoin reveals transaction participants but not the reason or data; patterns and volumes can be analyzed. In some cases, that alone could be sensitive (e.g., whistleblower scenarios, where the fact of communication between two parties is incriminating). Traditional email has a similar issue: email providers and anyone surveilling them see sender/receiver metadata, which has been exploited by programs like NSA’s traffic analysis.

Bitmail only partially improves this: the content and subject are hidden, but social graph metadata is still exposed on-chain to the determined observer.

Mitigations:
Users who require high anonymity could use pseudonymous addresses not linked to their identity and frequently change keys (one could generate new Bitmail keypairs and only share the address with specific contacts, akin to using multiple unlinked email accounts). The Bitmail protocol itself could evolve to obscure receiver addresses – for instance, by requiring receivers to register some kind of masked identifier that only they can recognize when hashed with their private key. Such techniques (mix networks, or routing through intermediaries) could potentially be layered on, but at cost of complexity.

At present, we acknowledge metadata leakage as a trade-off for efficiency: having the receiver explicitly on-chain makes message retrieval straightforward without requiring every node to gossip every message (which was Whisper’s approach to hide metadata, and it was inefficient). Timing analysis is also possible: an adversary could note when messages are sent and correlate with events (though this is true of any messaging unless padded/delayed).

The volume of messages and their sizes are not directly visible on chain (size is hidden by fixed-size encrypted blobs), but an attacker could guess if an attachment was large by perhaps IPFS retrieval time. Generally, Bitmail drastically limits content leakage but does not provide network-layer anonymity like Tor. Users needing high-level anonymity might run their Bitmail node through Tor or I2P to hide IP addresses from observers.

# 5.3 Spam and Unwanted Messages

Spam in Bitmail carries a real cost to the spammer due to required fees, as discussed. Let’s analyze a determined spam attack:

Suppose spammers obtain a list of Bitmail addresses (maybe by observing the chain for active addresses, or by other means) and try to send phishing messages to many users. Each message costs them a fee and also requires encrypting individually to each target’s key. If the fee is, say, $0.001 per message, sending 1 million spam messages would cost $1,000 – which might be within the means of some spammers (spam campaigns can be that “cheap” in email since email is free; paying $1k for a big phishing run might be acceptable to a criminal if the payoff is larger).

However, Bitmail has further friction: addresses are not as easily obtainable as email addresses (no directories, many users may not publish their Bitmail address widely). The spammer could send to random addresses, but the chance of hitting a real user’s address by brute force is astronomically low (since addresses are 20-byte hashes, it’s like guessing someone’s crypto wallet – effectively impossible at scale).

The spammer could instead watch the Bitmail blockchain and scrape any addresses that appear (as senders or receivers), building a list of “active users”. They could attempt to spam those. Each message would be on-chain, highly visible as coming from the spammer’s address. The network or users could react by blacklisting or throttling that spammer’s address.

Because Bitmail is decentralized, there is no built-in authority to block an address, but users could configure clients to ignore messages from addresses not in their contacts (this is an important client-level defense: e.g., only auto-show or notify for known contacts, others go to a “pending” list). A spammer could create many burner sending addresses to avoid easy blocking, but each needs funding for fees.

Overall, while small-scale nuisance spam might occur, large-scale spam (millions of messages) would be financially expensive and readily apparent on-chain (the spammer’s transactions would make them stand out, and community could choose to raise fees if abuse skyrocketed). The Bitmail approach is somewhat analogous to requiring postage and using an open ledger: junk mail can exist but is limited and traceable.

Additionally, because messages are encrypted to specific recipients, there is no way for a spammer to send one message and have it read by many people (like a broadcast) without paying per target. This contrasts with email where a single SMTP session can blast thousands of BCC recipients or a botnet can spew millions with little incremental cost.

# 5.4 Phishing and Identity Trust

Bitmail can mitigate phishing in certain ways but not all. Phishing often involves impersonation – e.g., an attacker sending an email that appears to come from a familiar address or domain. In Bitmail, every user’s address is a cryptographic key; one cannot easily impersonate someone else’s address (you’d have to steal their private key). There is no concept of “display name” that can be spoofed to hide the real address; the client could show a user-defined alias for known contacts, but under the hood the address is fixed.

So, in terms of the from address, spoofing is essentially eliminated – you either have the private key or not. This is a big improvement over SMTP email which relies on DKIM/SPF to reduce spoofing but is far from perfect.

However, an attacker could still try to trick users by other means – for instance, sending a message claiming to be some service, hoping the user doesn’t verify the address. If a user has not added the purported sender as a contact, the app could warn “this message comes from an unknown sender”.

Phishing content itself (like malicious links) is not something the protocol can prevent; users must remain vigilant. But importantly, Bitmail’s closed network (you can’t receive messages from just anyone unless they know your address and pay a fee) means users will mostly get messages from people they chose to share their Bitmail address with. Sharing one’s Bitmail address is more deliberate than having an email (which might be guessed or on public websites). So the context is a bit more controlled – akin to exchanging Signal numbers.

This social aspect can reduce random phishing, though spear-phishing (a determined attacker who obtains your address and fools you) remains possible. Bitmail’s end-to-end encryption at least ensures that any phishing email is from the actual source (not intercepted and modified), so if Bob receives a message claiming to be Alice asking for something odd, Bob can verify it really originated from Alice’s address (if he trusts the blockchain’s integrity and Alice’s address identity). Integration with identity systems (like mapping addresses to known identities securely, or using key trust schemes) could further help users verify who they are talking to.

# 5.5 Denial of Service on Network

An attacker might attempt to disrupt Bitmail service by flooding the blockchain or attacking IPFS.

Flooding the blockchain (i.e., a denial-of-service by spamming many transactions) would require paying a lot of fees or attacking consensus. If an attacker is willing to burn money, they could try to fill blocks with junk message transactions (perhaps send to random or nonexistent addresses). Validators will include them as long as fees are paid. This could delay or raise cost for legitimate messages.

The Bitmail chain, being less busy, might handle quite a lot of spam TX/s, but in extreme cases validators could increase minimum fees, making it expensive for the attacker to continue. Also, since Cosmos chains typically have a rate of a few hundred TPS capacity, an attacker would have to produce transactions at that high rate.

The open question is if an attacker obtains a large stake or colludes with validators, but economic incentives in Cosmos PoS discourage doing things that crash the chain (they’d hurt their own stake value). The worst-case scenario is a censorship attack: if >2/3 of validators collude, they could refuse to include transactions from certain users (or any at all), effectively censoring the network. This is a risk inherent to any PoS chain. However, if Bitmail is widely decentralized with many validators, such collusion is unlikely without a broad compromise. And even then, users could fork the chain or switch to a new network if the original is captured – something not possible with centralized email providers (if your email provider is coerced or evil, you are stuck or must migrate addresses).

Attacking IPFS could involve trying to remove content. Since IPFS is p2p, an attacker cannot delete content globally except by ensuring no node is storing it. If an attacker controlled a lot of IPFS nodes, they might try to refuse serving Bitmail content, but as long as Alice or Bob’s node has it, it can be retrieved (or manually shared). To be safe, important messages might be stored by both sender and receiver until confirmed delivered. There’s also the theoretical attack of a content targeted attack: since the IPFS CID is public (once decrypted by Bob) an attacker who guesses or intercepts it could fetch the encrypted content – but they still can’t decrypt it. The worst they could do is hold onto it indefinitely (which is fine) or try to poison IPFS’s DHT for that hash (which might make retrieval slower, but Bob’s app could use known bootstrap nodes or the sender’s node directly).

Overall, IPFS adds a bit of surface but since all content is encrypted, the damage of any IPFS attack is limited to availability, not confidentiality.

# 5.6 User Device Compromise

If Alice or Bob’s device is compromised (malware), an attacker could steal their Bitmail private key. This is outside the protocol’s direct control, but it is a common threat – similar to stealing someone’s email password or PGP key.

If Bob’s key is stolen, the attacker can read all Bob’s received messages (including past ones if they have the ciphertexts, since they can now decrypt hashlinks and fetch content). They could also impersonate Bob by sending messages from his address.

Bitmail doesn’t magically solve this – it inherits the usual need for users to safeguard their keys (just like Bitcoin wallets). The Bitmail client could implement password encryption of the key or integrate with secure enclaves to mitigate key theft. However, that is an implementation detail. The protocol assumption is the endpoints are trusted. So while Bitmail removes trust from servers and network, the end-user must still trust their own device security.

# 5.7 Not a Total Solution for All Threats

We emphasize that Bitmail optimizes for privacy and censorship-resistance, but it does not guarantee things like delivery speed under all conditions (if the blockchain is congested, there could be delay – though likely small), nor guaranteed persistence (if both sender and receiver go offline and no IPFS node holds the content, a message could vanish – though this is mitigated by normal usage patterns).

Bitmail also doesn’t inherently provide forward secrecy beyond what ECIES offers (each message uses an ephemeral key, so it has some forward secrecy – compromise of a private key now doesn’t decrypt past messages that used different ephemeral secrets, unless the private key was needed all along – actually, in ECIES, if the main private key is compromised, an attacker can decrypt all messages that were encrypted with that static public key; forward secrecy would require per-session keys negotiated interactively, which Bitmail doesn’t do for asynchronous messaging). So an attacker who records all your encrypted messages for years and later steals your private key could decrypt them all. This is similar to PGP’s model.

A possible improvement is to periodically rotate keys (and publish new public keys or use an identity key to sign them), but that’s beyond current scope. For most users, the threat of key theft is more pressing than the threat of long-term recorded ciphertext + future quantum break, etc.

# 5.8 Comparison to Other Secure Messengers

Compared to end-to-end encrypted chat apps like Signal or Matrix, Bitmail provides a different set of trade-offs. Signal has perfect forward secrecy and doesn’t expose social graph to a public ledger, but it relies on centralized servers (though storing only minimal data) and phone numbers. Bitmail removes central servers entirely and uses crypto addresses, at the expense of a public record of transactions.

In highly adversarial settings, one might combine approaches (e.g., share Bitmail addresses only over secure channels, etc.). The advantage of Bitmail is that no single company or jurisdiction can shut it down or hoover up metadata easily – you would have to attack the global validator set or analyze the whole chain.

In conclusion, the Bitmail protocol is robust against most conventional threats to email: mass surveillance (cannot read content), provider data breaches (no central data store to breach), impersonation (cryptographic identity prevents spoofing), and spam (economic disincentives and lack of public address directories). It does expose some metadata and inherits the need to protect private keys. In practice, it offers a significant leap in privacy for users who currently rely on standard email for sensitive communication.

# 6. Conclusion

We have presented Bitmail, a decentralized, blockchain-based communication protocol that achieves the confidentiality of encrypted email and the resilience of peer-to-peer networks. In Bitmail, there are no trusted email service providers – the role of routing and delivery is taken up by a Cosmos SDK blockchain that records transactions containing only encrypted message references, and the role of storage is handled by distributed networks like IPFS.

By encrypting not just message content but also the content’s location (via encrypted hashlinks), Bitmail ensures that only the intended recipient can access each message, eliminating third-party visibility or control. This design directly tackles the motivations laid out: it significantly improves privacy (addressing the fact that much of today’s email is not end-to-end encrypted) and curbs spam and phishing abuse by making unsolicited messaging costly and by tying identity to unforgeable cryptographic addresses.

Bitmail is not intended as a drop-in replacement for the SMTP email ecosystem, but rather as a new paradigm for secure messaging. It abandons some legacy concepts in favor of a simpler, more secure model – one message, one transaction, one recipient – analogous to the way Bitcoin simplified financial transactions. In doing so, it opens the door to communication that is as censorship-resistant as a cryptocurrency transaction.

No corporation can misplace or scan your emails, and no government can quietly demand a service provider hand over your inbox – because the “inbox” is just keys and code you control, with messages scattered across a decentralized network, each one opaque to outsiders.

Our implementation and analysis show that modern blockchain technology (especially application-specific chains) is now capable of supporting such an application with reasonable efficiency. Cosmos SDK provides a viable platform with the throughput and low fees necessary for a messaging volume, and IPFS and similar systems provide the needed storage scalability.

While improvements and future work remain – e.g., exploring better ways to hide metadata, adding support for group messages or broadcasts, optimizing mobile usage, etc. – the foundation that Bitmail lays is both sound and innovative. It demonstrates that we can reinvent email for the web3 era: making it user-owned, private by default, and resistant to spam and censorship without relying on centralized authorities.

In essence, Bitmail merges the strengths of distributed ledger consensus with strong cryptography to create a communication protocol aligned with the principles of autonomy and privacy. We hope this work inspires further exploration into decentralized communication and proves useful for those seeking an alternative to today’s surveillance-prone email infrastructure.

As global awareness of privacy grows, Bitmail and systems like it could form a crucial part of the infrastructure for free, secure, and trusted digital communications in the future.

# References

[1] Cai Ellis and Robert Brandl, “Spam Statistics 2025: New Data on Junk Email, AI Scams & Phishing,” EmailToolTester Blog, Oct. 16, 2024.
[2] Gary Smith, “Top Phishing Statistics for 2025: Latest Figures and Trends,” StationX Blog, June 2, 2025.
[3] Amie Stepanovich, “Google to enable end-to-end encryption for user emails,” Access Now, June 3, 2014 (updated Jan 2023).
[4] “Ethereum vs. Cosmos: Choosing the Right Blockchain Platform,” Webisoft (Tech Blog).
[5] “Web3 Email Platforms: 2025 Comparison Guide,” EtherMail Blog, 2025.
[6] Paul Anthonioz, “How to Encrypt an Email in Gmail (2025),” Mailmeteor Blog, Oct. 5, 2023.
[7] Michal Bryxí (SitePoint), “Ethereum Messaging: Explaining Whisper and Status.im,” May 2018.
[8] Bitmail Network – “Bitmail is a beta peer-to-peer encrypted messaging platform built on a Cosmos SDK blockchain and IPFS.” (2025)