Web3 Notification Service - Now supporting SMS and Push!

The Web3 Email Notification Service we released in Nov 2022, now supports SMS & Push notifications

First, a quick recap about why you should care…

Problem: dApps today are set up to fail

Right now, dApps on every blockchain suffer user retention and engagement problems.


Web3 notifications suck.

As a result, dApps don’t have a good decentralised way to continually engage users; to notify them of events that require their attention, or encourage habit-forming behaviours.

Right now, notifications suck for users and developers

Without notifications, users must remember to constantly log back into your dApp to see if anything has changed, while following a Twitter and/or Discord for alerts. This is an extremely poor user experience that is limiting dApps from succeeding.

If Web3 developers want to use email, SMS or push notification services in our dApps, we’re forced to build centralised off-chain services to manage this for us. This both adds development overhead and also introduces points of failure.

So, as developers, how do we send notifications in the most decentralised way possible, without having to set up lots of new infrastructure?

Creating a Web3 Notification Service (W3NS) - email notifications

I’m part of a team that’s solving the Web3 user retention and engagement problem.

We are creating a decentralised, secure notification service for developers building dApps on any chain, starting with IC.

In late 2022, we released our first product on the IC - an email notification service built with HTTPS outcalls. With this service, developers could engage users with transactional emails straight from their IC canisters.

We used Courier’s idempotent API to make HTTPS calls. Courier then allows developer to configure their email provider of choice (e.g SendGrid, Gmail or SES) to send user emails.

Update: Finally, SMS and Push Notifications for IC dApps!

We are excited to announce that we’ve expanded our Web3 Notification Service (W3NS) to support SMS and Push notifications (both Web and Mobile).

You can now send immediate notifications via Email, SMS and Push to individuals and segmented groups.

W3NS is idempotent and scales cheaply. It also supports dynamic API keys, so users can Bring Your Own Key (BYOK) to send via custom domain emails and vanity phone numbers (branded).

You will be able to subscribe users to specific Topics, which can then be used to broadcast to many users of similar interests, i.e. someone interested in the results of games in a fantasy sports league.

Here’s the highlights of this release:

Dynamic API keys (Bring Your Own Key - BYOK)

  • Support the setting and deleting of keys indexed by the canister that calls them.
  • Stored in a private data structure on the canister, so only needs to be set once and then you can call the send functions as needed.

SMS notifications via Courier

  • Expand support and the canister interface to include a function that allows consumers to also trigger an outcall that SMSes on their account’s API key.

Push notifications via Courier (both Web and Mobile)

  • Expand support and the canister interface to also trigger an outcall that sends Push on their account API key (They will have configured FCM in Courier already)
  • Requires the collection of the user’s device ID (whether web or mobile to support Push notifications) by the consumer to send

Targeted individual user notifications

  • Support specific users for their email, phone and push channels, interface needs to be able to select a channel and the user to target (identified by their email, phone number or device ID depending on the channel)

Subscribe users to Topics for broadcast notifications and sending broadcast notifications to Topics

  • Create Topics for Push notifications via outcall.
  • Support calls to the canister to Subscribe users to specific Topics for Push notifications
  • Support calls to the canister to unsubscribe users to specific topics for Push notifications
  • Support the sending of a notification to a Topic via outcall

Documentation for how to set up permissions requests for consumers of Canister for Push notifications

  • Documentation for how to send SMS, email and Push as a consumer

Try out the Web3 Notification Service!

Want email, SMS and push notifications for your dApp?

Visit our Notion project page for instructions to get started

Check out our demo videos

We’d love your feedback!

Are there other features you’d like to see, or do you have a cool idea? Let us know in the comments

What’s next?

Our short term goal is to build an Open Internet Service that’s easily accessible by builders on any chain and provides:

  • Improved frontend UI
  • Notification scheduling & flow designer
  • Automations based on events and user behaviours
  • Cross-chain email, SMS and push notifications

Our end vision is a full-stack Web3 marketing and user-engagement platform.

Find out about Argon Studios here: https://www.argonstudios.xyz/web3-futures


Sweet. Sending Push Notifications for NNS proposal topics would be nice.


This is impressive. I will take a closer look this week.


What is the pricing for teams that want to use this service?

1 Like

Hi @MJW , congrats for this effort.

Your pricing is a bit “damaged” by the HTTP Outcalls of the IC. It’s around 0.0048$, which looks cheap, but if a user sends a 1000 emails (which is very common on Web2), suddenly they payed 4.8$ :confused: This is not scalable :frowning:

As another alternative to your product, I would consider to inverse this, because it’s costly to send HTTP calls, but it’s uber cheap to receive them.

What if you had a Web2 server, that is only reading every second if a canister has any new “emails to send”. Like, getEmails(afterId: Int) : Emails. And the system that does the calling to Courier, is actually the Web2 system. That is super significantly cheaper.

The downside is that you can’t have feedback (it’s an async call) and you do lose for not being “fully decentralized”, but that is already lost by using Courier API.

That would allow you to have a cost that is probably 100x cheaper, just think about it :wink:

Hope this feedback helps :+1:


Will web socket help with that at all?

Thank you @diegop please let us know if you have any questions or feedback :grinning:

1 Like

Hey @justmythoughts, cost is usage based (per message). We’re beta testing the service now and looking for ways we can reduce costs. We’d love to co-build with anyone who wants to integrate and share feedback. If you’d like to chat more, please feel free to add me on Discord: MJW#7468

@tiago89 Thanks very much for your thoughts!

My team is having a lively discussion about this now and are definitely committed to reducing costs. Our goal is to create a scalable, accessible service for all IC dApps.

If you’d like to discuss ideas directly (plus any other feedback) please add me on Discord: MJW#7468