Dmail notifications carried project messages before the announced shutdown, while SubHub tracked delivery and reading separately
Dmail notifications delivered project updates to subscribed wallet addresses or decentralized identifiers (DIDs) through the Dmail Messaging Protocol. SubHub, Dmail’s subscription hub, let projects select recipients and track delivery rates, read rates, and new-reader counts. Those measurements described different communication outcomes: delivery concerned message arrival, while reading concerned viewing activity. Neither result confirmed that a recipient completed a task mentioned in the message. The team announced a gradual service shutdown beginning May 15, 2026, so these functions belong to the service’s pre-shutdown context. Interpreting an archived alert requires attention to its chosen audience, receiving channel, and reporting label, especially when comparing a sent message with a recorded read.
Updated on
Subscriber identities determined where project messages went
A project’s subscriber list defined its notification audience, with wallet addresses or associated DIDs identifying recipients. SubHub resolved those identities through the shared Dmail Messaging Protocol. A wallet address by itself did not demonstrate membership in a particular project’s subscription list.
The corporate digital business card collected subscription access, social information, updates, campaigns, and bulletins in one place. It gave the project’s announcements a shared entry point. Message Push handled notifications to subscribed identities, while the card helped users find the project and its subscription.
Audience selection and receiving destinations used different controls
A project chose its audience in Message Push. A subscriber’s linked traditional email supplied an additional destination.
| Parameter | Pre-shutdown option | Applicable condition |
|---|---|---|
| Recipient identity | Wallet address or associated DID | The identity belonged to a subscribed user. |
| Audience selection | Individual recipients, all subscribers, tags, or groups | The basic sending walkthrough covered all or selected subscribers; tag support differed between historical interface descriptions. |
| Linked email destination | The recipient’s linked traditional email | An account needed that email link to receive the additional copy. |
| Scope | Project audience settings and linked receiving destinations described different parts of the pre-shutdown notification service. | |
Historical instructions differed on tag-based sending. The basic sending walkthrough presented tags as a future addition, while the wider Message Push description included tag and group distribution. Interpreting an archived campaign therefore required its actual audience setting, without assuming that every sending interface exposed all methods.
Wallet profiles supplied targeting criteria and privacy limits
SubHub used wallet data to organize subscribed addresses into profiles and tags. Its documented inputs included on-chain assets, transaction histories, and transaction frequency. Projects could also create custom tags and groups. These categories gave recipient selection a more specific basis than broadcasting every update to the full subscriber list.
The messaging design used encryption to protect content. SubHub’s profiling tools categorized subscribed wallets through on-chain assets and transaction records. Message privacy and audience classification concerned different information about the same subscribed identity. Encryption of the message did not remove the public wallet data that the targeting tools used. A project’s tag described its selection criterion, which remained separate from the content that it sent.
A recipient’s wallet profile described observable activity. It could not establish their willingness to act on a specific notification.
What did a delivery rate establish?
A delivery rate described the platform’s recorded delivery outcome for a notification, separately from its later reading activity. Message Push exposed delivery analytics after sending. Projects could evaluate recorded distribution without treating a sent message as evidence of readership. An aggregate percentage did not, by itself, identify the recipient behind each delivery event or show that a particular person opened the content.
The campaign’s audience also supplied context for interpreting reach. Sending to selected subscribers narrowed the intended recipient set. A delivery figure for that set could not apply automatically to the project’s full subscriber list.
Did a read rate mean recipients completed the requested action?
A read rate recorded viewing activity; it did not establish completion of an action described in the notification.
The sending walkthrough described an open-rate display after users viewed the message. Message Push reported delivery rates and read rates as separate metrics. A recorded view added information beyond a delivery entry: the platform had registered activity around the content. The sending record, receiving state, and viewing record consequently described different stages of the same communication.
New-reader counts added another dimension to reading analytics. Subscriber-list entries described registration, including when an account joined the project audience. A notification’s reader count and a project’s subscription count therefore represented different records, even where they concerned some of the same addresses.
A read-rate percentage also needed a defined reporting basis. Its denominator determined the population that the percentage described. Historical figures could support a numerical comparison when that basis matched. Identical labels on different screens did not establish that the displays counted recipients, messages, or viewing events in the same way.
In-app delivery and forwarding reached different surfaces
The subscription sending guide described delivery inside Dmail and to a recipient’s linked traditional email address. That account link supplied an additional receiving surface for the notification, letting subscribers encounter project content outside the Dmail interface. A report from one receiving channel could not establish that the recipient viewed every copy. Any claim about activity across receiving channels needed the channel scope of the recorded event.
Recipients had separate settings for browser notifications, email forwarding, and Telegram forwarding. These channels broadened the places where a subscriber could encounter an update. A project’s audience setting concerned the recipients it targeted; the subscriber’s configuration concerned the receiving experience. An alert displayed by a browser and content opened in a mailbox described different observations, even when both related to the same notification.
Task conditions gave project points a separate meaning
SubHub awarded project-defined points when subscribers completed configured tasks and met the relevant conditions. Developers could set verification criteria and contracts for NFT or OAT credentials. The point-management dashboard recorded participation in points and offered task statistics. These records supplied engagement information beyond a notification’s read rate. A credential check concerned whether someone met the configured requirement. A read event concerned viewing the message that might announce or accompany the task.
Projects could tag or group participants who validated the same credential, connecting completed tasks with subscriber management. That gave later audience choices a task-specific basis. Project-defined points also differed from the DApp’s mailbox-tier points and the DMAIL token. A delivery or read figure did not represent a DMAIL balance, and a project reward did not automatically establish a change in mailbox privileges.
SDK reminders used configurable conditions and message content
Message Push also offered a software development kit (SDK) for notifications driven by application-defined conditions. The integration used a customer ID and private key supplied by Dmail. Projects could customize the conditions and the content that the messaging protocol sent. This connected notification content to monitored application information, extending the feature beyond manually composed subscription updates.
The documented SDK example concerned ENS names approaching expiry within a 30-day window. These were Ethereum Name Service (ENS) names. In that example, approaching expiry could trigger an automatic renewal reminder. Its read metric concerned recorded viewing of that message. Renewal concerned the name itself, so the message’s viewing statistics could not confirm a change to the name’s expiration.
The shutdown plan put a date boundary around delivery
May 15, 2026, marked the planned start of the gradual service closure announced in April 2026. The notice instructed users to export their emails before that date. It warned that emails would become inaccessible after all nodes stopped running. Notification delivery depended on the service infrastructure that the plan said would cease operating.
An archived campaign record could describe a result from its own operating period. It could not establish that the same notification path remained active later. A saved subscription, a linked-email setting, or an old notification screen likewise recorded an earlier configuration. Those historical records did not demonstrate current service availability or resolve whether the announced shutdown completed as planned.
Audience scope governed comparisons between archived campaigns
Historical read-rate comparisons needed the audience setting that applied to each message. All-subscriber sending and selected-recipient sending addressed different populations. Tags or credential-based groups could narrow them further. A higher reading figure alone could not show whether changed content, changed audience selection, or both explained the difference. The delivery result added context about recorded reach, while the subscriber list described who belonged to the audience.
For an archived campaign, decide whether the question concerns notification reach, message viewing, or a completed task. Communication statistics addressed the first two within their reporting scope. A claim that subscribers completed an advertised task needed the relevant task result. Keep the audience selection and metric label with the campaign record so that the comparison answers the intended question.
Before you start with Dmail notifications
Could a project accept Dmail subscriptions without collecting email addresses?
Projects could accept SubHub subscriptions through a shared invitation link without requiring email registration. The link could lead users to the project’s profile and also fit a website’s subscription entry. Wallet-based subscription and a linked traditional email served different purposes: the former identified the subscribed account, while the latter supplied an additional receiving destination.
Which details appeared in a project’s SubHub subscriber list?
SubHub’s subscriber list displayed registration times, wallet addresses, networks, tags, and assets. The management tools also offered custom subtags, groups, star designations, blacklists, and removal lists. These were subscriber-management records and controls. They did not establish that an individual viewed a particular notification, even when that address appeared within the intended audience.
Was a notification read enough to raise a Dmail mailbox tier?
Reading a notification alone did not establish a mailbox-tier increase. Dmail’s DApp tiers used the point attributes of the NFT domain bound to the account. An import into that domain was required for earned DApp points to affect those attributes. SubHub’s project-defined points were a separate scheme, so a project reward or read count did not automatically show a higher mailbox tier.
Did the ENS reminder window apply to every Dmail notification?
The 30-day window belonged to the documented ENS renewal-reminder use case and described the approaching expirations that the SDK could monitor. Message Push let projects customize SDK conditions and content. That window did not establish the timing of other notifications or the delay between sending and delivery.