Dmail is a multichain messaging protocol for wallet-linked email and alerts

Address resolution and identity ambiguity

Address resolution is Dmail’s most important failure point because a readable name, wallet string and active inbox remain separate records.

An Ethereum account address contains 20 bytes and wallets typically render it as 40 hexadecimal characters after the 0x prefix. That string can appear under the same key on several Ethereum Virtual Machine networks, yet transaction context still changes: Ethereum mainnet uses chain ID 1, while BNB Smart Chain uses chain ID 56. Dmail therefore resolves more than the visible characters. The selected identity, its network association and its current mailbox binding determine where the message lands. For a default address or non-fungible token (NFT) domain, the compose flow also requests the recipient’s Principal ID for dual verification (compare Dmail troubleshooting ).

Readable identities introduce a second mapping. An ENS, SPACE ID or Unstoppable Domains name can change hands, while Dmail activation links it to a mailbox. A message sent to an inactive DID waits for that identity to be activated or used for login. This preserves deferred delivery, but arrival and visibility remain different events. Recheck the resolved identity after a name transfer or account rebinding.

Encrypted content and the limits of wallet proof

The Dmail protocol separates control of an inbox identity from encryption of message content, so a wallet signature does not reveal the underlying private key.

A signature proves that the connected account authorized a login or network action. The product describes end-to-end encryption, cross-chain relays and decentralized storage for its Web3 messaging path. Dmail’s architecture also names X25519 key exchange, whose public keys are 32 bytes. The recipient uses corresponding private material to derive the same shared secret without publishing it. Encryption protects the payload between compatible endpoints; identity resolution decides which endpoint receives it. Neither property alone confirms that a readable DID still belongs to the intended account.

Wallet recovery remains outside the mailbox flow. Bitcoin Improvement Proposal 39 (BIP-39) defines five valid mnemonic sizes: 12, 15, 18, 21 and 24 words, although each wallet exposes its own supported subset. A Dmail login asks for a signature, not those recovery words. When delivery crosses into Gmail or Proton Mail, the receiving provider’s storage and account controls become part of the confidentiality boundary.

What can Dmail deliver to a wallet identity?

The Dmail service delivers encrypted mailbox messages and opt-in project notifications to wallet addresses, activated DIDs, NFT domains and conventional email accounts. Direct messages support known contacts, while subscriptions carry governance notices, release updates, event reminders and account-related alerts. The shared inbox keeps those streams beside wallet context. It does not execute the action described in a message; a proposal vote, token transfer or settings change still occurs in the relevant application and requires its own authorization.

Four address forms behind one Dmail account

The Dmail identity system groups four address forms under one account: default wallet addresses, NFT domains, external DIDs and conventional email addresses, as covered in practice.

Wallet and default addresses

A wallet signature establishes control and the first login creates a default Dmail address. That route removes the need to register a separate username. Default addresses and NFT domains use dual recipient verification with the visible account plus a Principal ID, which reduces ambiguity when similar labels or shortened addresses appear.

DIDs and NFT domains

ENS, SPACE ID and Unstoppable Domains supply readable identifiers that Dmail can activate as email addresses. Ownership comes from the underlying naming system; mailbox activation creates the routing association. NFT domains issued inside the Dmail ecosystem provide another transferable identity. A transfer changes control of the name, so the account binding matters after ownership moves. Because ownership stays in the naming protocol, a mailbox label can outlive one application account.

Conventional email gateways

Gmail and Proton Mail extend reach to people outside wallet-native applications. The gateway handles exchange between the Web3 address format and ordinary email delivery. This route preserves familiar inbox access, while message storage, retention and account recovery at the conventional endpoint follow that provider’s rules.

Starting with a wallet and a default mailbox

The quickest Dmail entry path uses a supported wallet, a selected network and the default address created at first login.

A newcomer can connect MetaMask, choose the available chain and approve the login signature. Settings then shows the active wallet plus any default address, NFT domain or DID associated with it. Before sending, the compose screen separates the sender identity, recipient, subject and body. A default or NFT-domain recipient requires its Principal ID as well. Previous correspondents enter the address book, which shortens later selection without changing the underlying binding.

Worked example: assume these hypothetical inputs: a 2.4 MB PDF and a 0.8 MB image. Together they total 3.2 MB, exceeding Dmail’s 3 MB attachment ceiling by 0.2 MB. Reducing the image to 0.6 MB produces a 3.0 MB payload, so the pair fits within the documented limit.

The documented artificial intelligence (AI) assistant allowance starts with 10 free uses; each later use costs 10 Dmail Points.

The selected network determines whether sending requests gas, which native asset pays it and which confirmation appears in the wallet.

Project alerts through Subscription & Notification

Dmail’s Subscription & Notification product routes consent-based project updates to subscribers identified by wallets, DIDs or linked channels and records chosen topics inside the subscription feed for each selected project.

Subscriber consent and delivery

A user chooses projects or topics in the Subscription Center, then receives matching items in the subscription inbox. Delivery can also extend to browser notifications, conventional email, Telegram or Discord. Unsubscribing removes that project from the chosen feed. This model fits recurring announcements because the subscription records audience intent rather than treating every visible wallet address as an equivalent recipient. Four recurring feed types illustrate the range:

• governance proposal and vote reminders
• protocol maintenance and release announcements
• campaign eligibility and token distribution updates
• wallet activity or market-threshold alerts

Developer payloads and response codes

The developer interface gives subscriber messages the integer type 2 and accepts a sender, recipient group, receiver list, subject and content. Its documented version 1 response uses code 1 for success and code 0 for failure. Project setup also asks for a sender domain between 4 and 18 characters. Those fixed fields let a backend transform a contract event, publication update or campaign state into a routed message.

Channel choice changes the final presentation: an inbox item keeps wallet context, while Telegram, Discord and browser delivery prioritize immediate visibility.

Network gas, service costs and DMAIL utility

Costs for Dmail split among blockchain gas, optional identity services and ecosystem functions that use the DMAIL utility and governance token.

A send route that writes a transaction pays the selected chain’s native gas asset. Ethereum and zkSync Era use ETH, while BNB Smart Chain uses BNB. On Ethereum’s Ethereum Improvement Proposal 1559 (EIP-1559) fee market, the effective price combines the block’s base fee with a priority fee, subject to the sender’s maximum settings. Gas used then scales the final network charge. A sponsored or off-chain route follows a different cost path, so the wallet confirmation identifies the relevant mechanism.

In those conditions, DMAIL has a maximum supply of 200 million tokens across its ERC-20 and BEP-20 implementations. The DMAIL allocation assigns 17% to investors, 15% to the core team and advisers, 15% to the foundation and treasury and 38% to the community. Ecosystem development receives 6%, centralized-exchange events receive 3% and the first two airdrop allocations are 3.75% and 2.25%. Together those categories account for 100% of the stated supply.

The token’s documented roles include governance, ecosystem incentives, service fees and relay-node staking. Holding it is distinct from controlling a mailbox identity, which rests on the linked wallet or DID. The payable amount changes with the selected network, the optional service and the fee rules active when the user confirms an action.

Identity resolution, relays and storage under the hood

The Dmail protocol resolves an identity, encrypts the payload, routes it across supported networks and exposes the result in the recipient’s mailbox.

Identity resolution

The resolver starts with a wallet address, NFT domain, DID or conventional email account. ENS, SPACE ID and Unstoppable Domains provide external name ownership, while the Dmail account records activated routes. Default and NFT-domain delivery adds the Principal ID match used by the Internet Computer identity model. The output is a recipient endpoint that the messaging layer can address without placing a readable name directly inside every application’s own user database.

Encryption and relay

The sender selects an identity and authorizes the action through the wallet. Dmail encrypts compatible Web3 messages before relay and uses network components to carry them across chains or applications. Subscription publishers use developer credentials and structured payloads rather than a compose window. Relays solve transport; they do not redefine ownership. A changed DID record or transferred NFT domain therefore changes the identity input that route must resolve. The recipient opens the encrypted message after mailbox authorization.

Storage and public-chain boundaries

During normal operation, Dmail’s design separates account or routing state from encrypted content held through decentralized storage components. Blockchain transactions provide verifiable state changes and fee settlement where the selected route requires them. That architecture does not turn the readable email body into ordinary public transaction data. A conventional email gateway creates another storage boundary because the external provider receives the delivered copy under its own mailbox model.

XMTP, Push Protocol and conventional email as alternatives

On a first pass, Dmail alternatives include XMTP, Push Protocol and conventional email, which address communication through identity and delivery models. XMTP centers chats and groups on the standardized Messaging Layer Security protocol. Push Protocol centers wallet notifications, channel subscriptions and node-validated delivery. Gmail provides reach, while Proton Mail emphasizes encrypted email in its service. Dmail fits when a product must combine an email-shaped inbox, wallet and DID addressing and project subscription alerts; the alternative changes with the required endpoint and message pattern.