[SCP-79] Integrate EPNS into Shapeshift


This proposal is to officially choose EPNS as our notification provider and start its integration into our platform.


EPNS is the Ethereum Push Notification Service. They launched in January and allow DAOs to send push notifications related to governance proposals (new proposal on Snapshot, 24 hours remaining, results, etc.) on their mobile app, web app, and browser extension. Soon they will enable voting on proposals from the notifications.

If this proposal is implemented, EPNS will be used to send notifications about governance and our web app.


Communication from applications to users is essential in web applications. On Web2 platforms this is often done by sending emails attached to the users account, but that isn’t a good fit for Web3, which is wallet based. EPNS will allow users to get important information from us by providing only their wallet address.


This proposal will result in 2 outcomes:

a. Create an account on EPNS in which the DAO is the admin and workstream leaders have authority to make notifications. Notifications related to governance will include: proposal added to Snapshot, 24 hours remaining, and results after voting ends.

b. Committing to putting EPNS integration on the web app on the product roadmap. Integration will proceed at the product workstream’s discretion.


Shapeshift gains the ability to deliver push notifications to users in a decentralized and private way.


Workstream leaders will have the additional responsibility of managing push notifications for their workstream.


This proposal requests the treasury pay 100 DAI for the account and around $50 of ETH for the gas fees.

Why Make a Proposal

a. The DAO will need to execute transactions to deploy the channel (unless we decide to leave admin of the channel up to an EOA, which I don’t think we should do)

b. The DAO can potentially delegate the ability to send push notifications from the channel to an EOA. If we decide to go this route, that should be specified. Otherwise, if we don’t specify and want to implement this in the future, it would require an additional proposal.


The idea of a decentralized push notification system is pretty interesting; this could potentially become a powerful marketing tool in the long term and eventually replace the need for a centralized email marketing list. Very interested to see how the implementation would work, looking forward to input from engineering and product.

While this looks cool and is doable, I don’t think this needs to be a proposal given the magnitude of cost, and the reality that this will be administered by engineering in conjunction with product & marketing.

Put simply this should just be considered jointly between product and engineering as part of our respective roadmaps.

This is a no from me.

The same issue was raised during incubation, and Willyfox made a great post explaining why this should be a proposal instead of a workstream initiative.

I’ve added the main arguments of his post to a new section called “Why Make a Proposal” to make this more clear to others. 1f642

  • thanks for moving these ideas forward.

discourse-post-upload20231125-65354-zsozg2.png IrohDW:

b. Committing to putting EPNS integration on the web app on the product roadmap. Integration will proceed at the product workstream’s discretion.


I am a little unclear at this point of your proposal. Without understanding what this integration would look like and the expected level of effort it’s hard to reason about this feature compared to other high priority features being considered.

Obviously the DAO has finite resources and determining how to deploy them seems paramount to our success or failure as a DAO. I think having some more information on what the “cost” of this proposal passing is would be needed for me to be able to effectively vote on this.

That part of my proposal is there to ensure that the integration includes notifications to the web app in addition to making an EPNS account. It is vague on the requirements and timetable so that it doesn’t impose too much on product and engineering.

That section is a preference, not a requirement. So if it causes more trouble than it is worth I am willing to remove it when the proposal is added to Snapshot.

thanks for pushing this forward !

I can see how the commitment to integrate EPNS into the product could confuse the proposal, so while I agree we should do this, I think we can leave it out in the proposal language, or at least rephrase as “this will also open the door for product and engineering workstreams to further integrate EPNS into the ShapeShift apps if they choose.” I would also rename the proposal to something like “Deploy a ShapeShift EPNS channel for decentralized push notifications” so people don’t think the proposal is for an integration.

One other suggestion is to only delegate the ability to send custom notifications to leader(s) of marketing/growth workstreams. They are the only workstream with the ability to send tweets, and I think we can apply the same process to push notifications.

I hear ya that this is a relatively small proposal; the reason I asked Seth to make a proposal for this is that it will require DAO txs to deploy the channel and delegate the ability to send notifications to an EOA, and in the spirit of progressive decentralization, we only execute DAO txs that have been approved by the community. The initial notifications will only be governance related, so no product/engineering work is required (although we can decide to give users the ability to opt-in to notifications by signing a message on the upcoming FOX page). Once this is done, product and engineering can decide if and when to integrate EPNS without requiring an additional proposal.

OK. I’ll make those changes when I put the proposal in Snapshot tomorrow. 1f607