Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Harsh Rajat: Ethereum Push Notification Service – The Decentralized Notification Protocol

Episode Date: February 2, 2021

Ethereum Push Notification Service (EPNS) emerged from the Indian startup scene in 2020. It's a decentralized notification protocol that enables DApps to send push notifications to Ethereum wallet users. EPNS also provides incentives to users that opt-in for push notifications, creating the possibility for an ecosystem communities around topic-centric channels.We are joined by Harsh Rajat, Project Lead and Co-founder of EPNS. We chatted about why and how the protocol was built, its technical structure, the purpose of incentivizing users to receive notifications, and how they tackle spam.Topics covered in this episode:Harsh's background and how he got involved in cryptoThe beginning of Ethereum Push Notification ServiceThe design patterns considered when building EPNSWhat is a decentralized push notification service?Unique use cases that could benefit from DeFi push notificationsThe structure of the protocol and how it actually worksThe purpose of incentivizing users to receive notificationsThe Spam Score - how EPNS filter spamHow EPNS plan to onboard and incentivize wallets to integrateEpisode links: EPNS websiteEPNS appWhitepaperEPNS on TwitterHarsh on TwitterSponsors: 1inch: Discover the best rates and most efficient swapping routes across leading DEXes. Optimize on gas cost and execute DeFi trades faster with 1inch V2 - https://epicenter.rocks/1inchThis episode is hosted by Sebastien Couture & Sunny Aggarwal. Show notes and listening options: epicenter.tv/377

This is Epicenter, episode 377 with guest Harsh Rajat. Hi, I'm Sebastian Quirio and you're listening to Epicenter, the podcast where we interview crypto founders, builders, and thought leaders. On this show, we dive deep to learn how things work at a technical level, and we fly high to understand visionary concepts and long-term trends. If you like Epicenter, the best way to support us is to leave review on Apple podcasts. And if you're on a Mac or iOS device, well, the easiest way to do that is to go to Epicenter.rocks slash Apple. And if you're new to the podcast, be sure to subscribe to get episodes every week on Apple Podcasts, Spotify, or wherever you listen. Today, our guest is Hars Rajat.

He's the project lead and founder of Ethereum Push Notification Service. EPNS is an infrastructure project which builds a decentralized push notification service. So basically, it allows smart contracts to send notifications to account addresses. And there's lots of applications for this. So in a Dex context, a user could be notified when the price of a token falls or rises by a certain percentage. You could also set up a notification for when a trade is executed or completed. In DeFi, a lending protocol user could set up a notification and be informed when they're about to be liquidated. LP providers could set up a notification about impermanent loss and things like that. And those other applications in gaming and NFTs, which we go into during the interview.

So one thing I learned during this interview is that push notifications as we know them in our everyday lives, like the ones that we get on our phones, for example, are highly reliant on mobile deaf platforms. So in iOS, for example, all the push notifications go through Apple before being delivered to your phone. APNS provides an alternative for this that is decentralized and censorship resistant. And the nice thing about EPNS is that it's not blockchain specific. Offchain applications can also use EPNS to send notifications to their use. users. Sunny and I went into this interview really excited about the tech and all its potential applications because we think that the idea of a DAP or a smart contract sending notifications

to wallet addresses is really cool and useful. During the interview, though, we realized that there was one thing about EPNS that we missed during our research somehow, and that is that it also includes this incentive mechanism that allows users to be paid to receive messages. So the idea is that people would sign up to a channel and they could be paid to receive messages from, say, like a project, for example. We didn't really understand why this was useful in the broader kind of context of the project. We felt that it could create opportunities for some spammy behavior. So there's part of the interview where we address that with harsh. In any case, I'm really excited about this project and the technology.

They have a really great team. They have a wealth of experience in the mobile app space. And they're backed by some prominent figures in the ecosystem. So I have no doubt that they have the resources and the ability to succeed at building something which is really valuable. The next time you need to make a swap, don't worry about figuring out which decks or AMM will provide you the best price. Just go to one inch. It's my go-to decks aggregator. And when I use one-inch, I know I'm getting the best price for my trade. What's nice about one-inch is that it allows you to choose on maximum return or lowest gas cost when you're making a trade. then you can choose which one is right for you.

To learn more about one inch and start using it today, go to epicenter.rox slash one inch. And with that, here's our interview with Harz Rajat. We're here with Harsh Rajat. He is the project lead and co-founder of Ethereum Push Notification Service. And it's a protocol that allows for anyone to send notifications on a blockchain. So contrary to other notification service that I think most people are used to, these go through like typically like a central server and Ethereum push notification service actually is living on a blockchain. So it uses the underlying infrastructure of Ethereum to push notifications to users.

Thanks for joining us today. Thanks, Sebastian. Excited to be here. So tell us a bit about your background and how you. became involved in crypto? Sure. My background, I've been a mobile entrepreneur from 2010. So started my entrepreneurship journey quite early. Was there in the mobile ecosystem space, designed a lot of apps and games. Some of them were quite popular as well. But yeah, in 2015, I kind of grew board of the ecosystem and just developing mobile apps and games. And that was when

the exploratory phase started. Around 2016, I entered into trading as well. But yeah, I was at that point of time, I was going through a lot of tech. I was trying to also dabble into marketing. I was also exploring a lot of other technologies, including machine learning and AI and software as a service product. But yeah, in 2018, I realized that you can program on Ethereum

or you can program on Solidarity, which is a weird curve because, you know, I was trading from 2016 onwards with a classic strategy of buying high and selling globe. But yeah, in 2018, I found out that, you know, you can program on solidarity. And I always believe that before, you know, you can start solving some problem. You have to learn about it. Right. So at that point of time, I joined a fintech startup.

they were doing a P2Petransaction smart contract as well as a mobile app was there for around one and a half years learned about smart contracts, learned about the ecosystem. And yeah, that led me to start Ethereum Push Notification Service in 2020. So before you actually got to like start Ethereum Push Notification Service, were you, like, what kind of things were you building with solidity? Like, what kind of things were you building in that, like, sort of like your learning journey in the Ethereum space?

Sure. So I dabbled into, I mean, we all start with hello word in the smartphone trap. So, yeah, that was the first part. But yeah, I moved into and I dabbled into trying to create a version of Google Drive for the previous form, which would, instead of Google. Google Drive, which will be storing files on the Ethereum ecosystem. Of course, with IPFS and Ethereum ecosystem playing in tandem. And, you know, essentially that came in handy with notifications as well.

Because, you know, while you can store everything on Ethereum, but that will be very expensive. So IPFS really opens up a whole lot of possibility. So, yeah, in the previous tenure, I played around with metatransaction, played around with how you can create basically a Google Drive version on the Ethereum ecosystem using IPFS and, of course, the hello word contract. So it seems you've always been very more attracted to sort of the Web3 aspects of the ecosystem more so than, for example, DFI or any of these other, like, narrative. So what attracts you so much to the Web3 vision? The first thing about WebTree is that, and you know, I believe in the future. So, you know, the basic thing which really excites me is that in a way your public wallet

address is you use a name and your private key is your password. And that essentially fits into any service. And when you move from that service, you are essentially carrying your data. So it's kind of like a very new. thing to have or it was a new thing to have when I started. But that excited me because a lot of times I was thinking that, you know, why can't my data move between servers and who should own my data, whether it should be me or whether it should be corporations? And you know, VEPT sort of enabled that. So apart from, you know, of course, it's censorship resistant.

and it's better, you know, in terms of privacy. But, you know, taking that apart, it also enables you to move your data and, in a way, control your data, which was not really, or which is still not present in Web 2. So how did you end up coming now to the push notifications? Like, you know, with all these, you know, subverticles you could dive into within Web 3. Push notifications often isn't people think about storage or like, you know, messaging, but like how do you end up on push notifications? Sure.

So actually it's a full circle for me. When I started in 2010, I started as a mobile entrepreneur, right? And I, we created a web browser at that point of time that used to compete with Safari and Google Chrome. And what we realized, I mean, we were lucky,

the app was quite popular. At that point of time, it had apps download, manager, all the fancy bells and whistles. And because of that, you know, whenever the new tech was coming, we were rushing to incorporate it. And around that point of time, you know, Apple launched push notification. And I was able to deep dive into the architecture and understand, you know, why that communication middleware was needed and what sort of news it opened up. And yeah, because of that, I was a huge fan of push notifications from thereon. And, you know, and, you know, and

And if you can see basically from 2010, those notifications, they basically transformed our lives. So we don't realize it, but right now we are dependent on these push notifications so much. And I bet on the web toward, I mean, this meeting would have probably been a push notification. Any emails, any payments, any social likes, or any trends which you visit or services you visit traditionally. the services, these traditional services, they essentially send your notification telling you that your attention is needed. Even, you know, your WhatsApp video calls or your WhatsApp chats or your FaceTime calls are push notifications, which are then transformed based on the payload.

In essence, I already knew about push notifications. And, you know, when in 2020 we sat down and we started going to observe, serving a lot of tabs and smart contracts to see if there was any pain point. We were comparing it with the Web2 experience. And what happened was we quickly realized that while Web2 services, they come back to the user and they say, hey, we need your attention. What do you want to do? Do you want to pick up this call?

You are trending. Do you want to go and reply? When you compare it with the WebTree word, the services are still in the Stone Age era of communication. where then, you know, Web3 services expect users to come back to them. Like, you know, you take the loan on RVey. It can be liquidated without you getting to know about it.

Unless you are going back to those services and checking that out, any governance, what happens, you know, you will not know about it unless you go back and check it out. Take, for example, any Dexas or, you know, ENS domain names, they expire and the user is expected to keep track of it. And while that's okay when you start early, but as we mature and we grow a lot, you know, it becomes quite tough. If you are dabbling in 20 different Web 3 services, do need that same sort of interface

which Web2 has already perfected. And, you know, they have already proven that the user engagement and retention is more when you are doing push notifications. So, yeah, because I had that knowledge and because we were observing these points, we quickly notice that this is something which is probably we can help build. And, you know, of course, we were lucky and at the right place at the right time to do that. One inch is a decentralized exchange aggregator that sources liquidity from the top dexes and the AMMs to save you money and time on swaps. One inch finds the best possible trading paths across over 20 supported liquidity protocols and splits them up across multiple market depths.

I started using one inch last summer, and since then, it's become my go-to aggregator. I use it every time I need to make a swap. They recently launched V2, which has a brand new API. It greatly improves their routing algorithm. And my favorite part about the V2 is the new UI. It's super clean and easy to use. These improvements ensure that you get the best rates on your swaps with the lowest possible response time. So the next time you need to make a swap, forget about getting the best rate or optimizing your gas fees.

Make it easy on yourself. Just use one inch. And you can let them know that we sent you by go to epicenter. Dotrox slash one inch. That's one I-N-C-H. We'd like to thank One-inch for their support of the podcast. You said something that I think is really interesting as you were talking about, like these different services, like needing your attention.

And I mean, personally, in the last, probably in last year or two, like I've been really on this kind of like this quest to regain control of my attention. And so I've gotten off of a lot of social media. And in fact, I barely get any notifications on my phone at all. Like even WhatsApp messages, like I don't have notifications turned on for that. And I wonder if in this journey of yours to, you know, provide something that I think, like, is of actual value, right? It's like providing people with the information they need when they need it. If you also have given any thought to, I mean, I want to say like the consequences because it's like you're not the,

the root of the problem. I think the root of the problem is more just like our digital lives that have taken over our attentions. But if you have given any thought to like design mechanisms that or design patterns that are a little bit more mindful of our of our limited attention, if that's something that you've either incorporated in the product or given some thought too. Sure. Actually, we did.

You know, because we actually believe a lot. gotten basically observing. So, for example, you know, telegram messages stay at a boom. But at one point of time, if you go on telegram, you're getting loads and loads of spam because no one stops the other user to send you a message. And, you know, that kind of became a thesis that before we start building a notification protocol, we need to make sure that, you know, the users who are going to receive these notifications they should always be in control.

And, you know, of course, the services that will send notifications, they are also given a mechanism by which if they are abusing the service, they are trotted down, not by us, not by a centralized entity, but in a decentralized way through the protocol itself. So the way we developed this protocol was by always ensuring that the user is always and in control. And the way we do it is that whenever the service wants to send a notification to a user wallet, whether it's a DAV, it is a smart contract, whether it's a traditional server,

before they are able to do that, the user has to opt in to receive these notifications. Because in the end, that's how the design system should be. A user shouldn't get anything which they don't want. and that is the first design step we took, that notifications are cool. It might be game-changing for the entire ecosystem, but they also have this evil attached to them, where then anybody will come and they will just start spamming. And how can we stop that?

And we realize that the best way to stop it is to make sure that the user is in full control of receiving or enabling these notifications from a service or disabling it from a service and after that the service cannot usually send the notifications out. So that was the first step. The second step we did was a civil mechanism or a protection which was based on the thesis that what if a service is performing really well and they get loads of users and after that they turn evil or they are bought out or they are hijacked. For that, you know, we developed something called the spam score and we developed or we are still developing a governance which will make sure that, you know, if a service is not performing or, you know, if a service is performing in suspicious ways, then the protocol or that smart contract middleware which we are designing, it essentially is able to throttle notification from the service and give them a chance to basically correct that. behavior. And you know, if they don't stop, the trotling will start to go up and up. And again,

that's based on all the automatic controls, all the positive and negative action, the service takes in regards to sending notification and regards to their channel. But yeah, those were the two points which we thought about. I would be happy to get more into the spam score throttle. Well, let's come back to that, actually. First, let's, could you maybe tell us about how the protocol works and like what doesn't even mean to be a decentralized notification protocol because like you know in apple's iOS toolkit or whatever like some server has to be the one saying to send the push notification so what does it mean to have a decentralized push notification service to understand that I mean let's take a step back and let's talk about Apple push notification

service and how they usually operate So, yeah, basically the way Apple notification middleware is made, it's made. I mean, yeah, so basically there's Apple meta way that handles Apple push notification service. And whoever are the app owners, they basically have to interact with this middleware. And not many people realize that this middleware is basically responsible for a lot of things. but certain cool things which this middleware does is, A, it verifies if the app owner is entitled to send notification on the app's behalf. B, it ensures that the user has opted in to receive these notifications

and C, this middleware, this Apple middleware, ensures that if a app is sending a lot of notifications, then it's trotted. Now, you know, if all those rules are met, notifications they basically are emitted out from this middleware. And then what Apple ecosystem and what Apple platforms are doing is they have a socket or a WSS connection to this middleware, and they're only listening to this middleware, and they are then showing notifications to their operating system. And while, you know, it seems quite easy, but it's quite complex if you look about it in the architecture way.

I mean, if there was no middleware, then Apple was instead going for, I will just listen to WhatsApp Middleware or Facebook Middleware and show notification. First of all, it will become quite tedious because now Apple as a ecosystem is listening to

100 middlewares and, you know, they are trying to see and put hundreds of notifications from those 100 middlewares, which is not possible because, you know, the battery will be gone in like five minutes. So it's a quite elegant solution that you have one middleware which standardizes all the flow and imposes the rules. And then the ecosystem listens to it and shows all these notifications. So yeah, that's Apple push notification service. What we did was

we essentially took this decentralized middleware and we transformed it to the WebTree architecture layer. So for instance, one of the things we did with the middleware, of course, you know, all these rules, we took that, we borrowed that, and we cooked it in the decentralized smart contract of us to create a Web3 standard of communication and notifications. But yeah, with Apple ecosystem, the problem was that these notifications are flowing to just Apple platform. And it's quite easy to just listen to them. But for WebTree, I mean, it doesn't make sense if notifications are only coming to our apps, because again, that's not the WebTree ideology. So what we did was we abstracted the sending part and the receiving part of the notification. So in essence, what a smart contract on this Ethereum layer does is, you know, of course it follows these things, verifies that the user is control, the app is sending notification on the app on behalf and all those

things. But yeah, once all those rules are done and verified, the smart contract basically emits that event out which contains the identity of the notification. And that's the sending part for all the services, how to send the notification out. For the receiving part, because it's abstracted, now we have the ways or if we have the means to listen to this one single smart contract, get all the standardized notifications, and then essentially transform them in a way that it's supported by either Apple ecosystem or the Android ecosystem or even Telegram or, you know, the end goal vision is that, you know, these notifications are supported by popular crypto wallets by themselves. So yeah, that's essentially what.

we did to create the notifications protocol and, you know, that's essentially how the notifications are basically transformed and emitted out. I'm curious, like, what are the kinds of, because I mean, we, like, I think for, for Web 2, the use cases are pretty, are pretty clear. I mean, we, I mean, we observe those use cases on a daily basis, at least those of us who have notifications turns on. But But I wonder if in Web 3, some things are obvious. You mentioned this earlier, like your liquidation, for example, you want me notified of that. But like, what are some other unique use cases that perhaps are not so obvious or that you

envision it would be where it would be useful to have push notifications like for the future of Defi? Sure. So, defy is specific. I have a whole list of ideas. But yeah, near liquidation alerts, I already spoke about that. Price alerts, staking rewards, staking rewards, which are about to expire, stable coin pick, slippage, low gas cost, rebalancing, token contract migration,

any security update, governance update, any collateral types which are getting launched on the market, any liquidity mining incentives which has been changed or are now obligable. label, any yield farming alerts, any escrow period which is ending, and a lot more. In essence, that's the thing. That's the beauty of a communication protocol. It doesn't just stop over here. I mean, because the way the notifications are made, it can be used for any communication that a service wants to do to their users.

And by the way, I didn't really spoke about one other innovation, which we did, and that's where we are also called the DFI protocol. We essentially also enabled passive warning for all the users who are receiving notifications. And that essentially relies on the DFI aspect of our protocol. But yeah, that's another question I just wanted to highlight that. Just to, so I can get my head around this fully, it's what this protocol. it's not necessarily a web, like a blockchain specific thing where it's only, you know, DAPs can like send notifications. It's really more of saying, hey, there's this like very centralized middleware in the notification

stack, which is like owned by Apple. And that's like this like point centralized point of failure or whatever. And then let's decentralize that middleware. The fact that it can be used for like by DAP. is like a side thing because it can also be used by like, you know, normal Web 2 companies

could also choose to use this instead of Apple's middleware. Definitely. Definitely. I mean, that's one of the key points when we were building this. We wanted this to be backward compatible

as well as future compatible. So DAP and smart contracts, of course, they cannot send notifications out using traditional means. But with the EPNS, traditional servers can also send notification out as long as they're following the rules of the protocol. But yeah, just to correct you guys, basically we are building the Web3 decentralized middleware, which will send notifications out and, you know, Metamask, for example, integrates us, it can pop open. Though guys, Metamask hasn't integrated us right now.

if we have to go to the Apple service or when we go to the Apple ecosystem, I mean through this WebTree middleware, all the notifications still have to flow through the Apple ecosystem. Right. Because, you know, that's their rules. But yes, other than that, you're almost, I mean, you're 100% right. Okay, got it. And so what's nice is that because this middleware exists on the,

blockchain, DAPs can all, along with servers sending a transaction to like send a notification, a DAP can also send a trade a notification by like sending a smart contract call to the, uh, contract. Exactly. Yes. Got it. Okay. Okay.

Now I think I'm starting to understand it. Wouldn't this cause like a much higher gas overhead for most of these contracts? Like, you know, wouldn't we prefer instead of doing like smart contract calls, wouldn't we prefer to have some architecture where you can use like Ethereum events, for example, which are much cheaper gas-wise than doing smart contract calls? Sure. So actually, if you're looking at the smart contract calls, in the end, they are emitting a event out.

And it's only because, you know, you said that right, events are cheaper. So right now, even using the smart contract call, the way we have made it, it just costs 29,000 gas, which in essence is not that high. But yeah, there are certain ways by which we are trying to even support that. And the way our thesis is, so the way we think is that, you know, in the future, we are going to come into L2 layers. We are exploring solution about that. And, you know, if a traditional server or if a DAP wants to interact with the L2 layers,

they can still send a notification. And we will still be on L1, mostly for the main net smart contract to our EPNS protocol interaction. And usually whoever are on the main net, whatever smart contracts are on the main net and they want to send notification, their usual average cost is much, much higher. I mean, usually it's about $60. I mean, a couple of days back to basically loan or borrow. on the R-A, we won. And if notifications were enabled on that platform,

it would have cost $60.5 to the user, or even less. So the way we think is that if a user is able to pay $60, then of course they will not mind paying 0.1% extra to make sure that those notifications make it out to them. And of course, for the DAP and for these traditional servers, they can continue interacting with us on the L2 layer, thereby solving the problem of the gas price. And of course, it's counting EIP 1559 at 2.

So how does the integration work here now? So your smart contract is basically emitting the events for the notifications. Is it now on each wallet to individually know to subscribe to these events and send their own push notifications to the users? Yes, so basically, again, if you compare the web to word, services decide what notifications they want to send for the user, as long as the user has opted in to receive notification once. And that's the same architecture which we use on the protocol. So the user basically has to subscribe to a service or become their subscriber.

And we call services channel on our protocol. So once a channel has a subscriber, after that, the logic of sending notifications, whether they want to trigger on-chain notifications or off-chain notifications, it's left up to them what they want or what they think is useful for the users, either as a whole or a subset or even just one. That logic is left up to them and they are free to decide. How do they do the off-chain notification? So I'm understanding the on-chain.

So the flow would be that the DAP triggers your contract, emits an event. My wallet on my phone is watching this contract's event. It sees one that was meant for me, and it pops up as a notification on my thing. How do you do an off-chain one? Because if my wallet only knows to look at the events of that contract. Sure.

So the off-chain can interact without a contract, right? So in the end, as an off-chain service, you are interacting with the protocol. Oh, but you still have to send a transaction on chain. Okay, that's what you meant. Sorry. Okay. The origination of the notification is off-chain, but eventually your transaction still has

to be made on-chain. How expensive do you think this is like going to be feasible that every time like a someone wants to send a notification, they have to do an on-chain transaction. So like, you know, you just mentioned that you guys are looking into like L2 solutions and like stuff. But like, do you not think that this will be like, you know, especially even in the bootstrapping phase right now while you're still in V1, right now Ethereum gas prices are like, you know, it's like a minimum couple bucks to make a transaction.

Do you think that's going to be a hindrance to your getting started? Not really. So, I mean, we already started our alpha product on drop scene and we are going to come on L2 very, very soon. But yeah, that's the thing. I mean, for now, loan liquidation. I mean, if you have taken a loan of $1,000, you wouldn't mind paying $2. And even at this moment, I mean, with the current gas price, we calculated, with 300 gas price,

the notification cost came around to be $1.2 if you were on main net. But yeah, with drop scene, of course, that's totally omitted out. But yeah, you have to imagine or you have to bring. L2 into the mix. Because, you know, of course, we are on Ethereum push notification service. So Ethereum is our name. But eventually we'll become blockchain agnostic as well. And the way we are doing it is that, you know, we get this middleware running.

We, of course, Defi is the one that needs notification the most. I mean, your finances, if you take a loan from your bank, and the bank doesn't foreclose your house before sending you alerts. And, you know, this happens in Defi all along. But yeah, with L2, this becomes a no-brainer because, again, if L2 is unable to scale credit, then of course, you know, L2 will easily be able to scale our notifications. For the cost on L2, I mean the analysis we have done right now, I'm still ongoing. We feel that it will probably be around $0.001, sending a notification out.

And again, a notification transaction doesn't mean that, you know, if you are sending notifications to 20,000 subscribers, then you have to send 20,000 transactions. As I said, you know, the notification identity basically carries a lot of things, among which what all recipients or subset of recipients or single recipient notification is meant to. So yeah, not really worried about gas costs right now, but yeah, definitely something we are keeping a close eye on. I think most of the Ethereum is. So I'd like to talk about channels a little bit and just kind of dive into those. So we've talked a little bit about them. But I mean, so if you go on the EPNS app, so like I installed the app on my phone, I got it set up and everything. And like there is some channels here that I can subscribe to.

So there is a Bitcoin price channel. I don't have them in front of me right now, but like I was looking at it earlier. And so there's like some kind of generic channels there. Now next to each channel, there is like a number of users presumably that are subscribed to that channel. And also it cost and die. So walk us through then. So like what are channels conceptually? So is it is it a stream of information that is going to different users like a telegram group?

or this each, so for something that's a little bit more personal, like for example, alone liquidation, is that on a sort of user or individual address or is it like one channel where that channel is sending information to multiple users in this case? Like how is that structured? And then later we can get into the economics of how this works. Channels basically, they're very much similar to YouTube. So any user or any service, when they want to send a notification, they have to become a channel. And that channel then basically have subscribers.

So the subscribers are basically opting into receive notification from that channel. The way we have designed it was we thought a lot about it that, you know, AVE or compound or any other DFI protocol will come and start using notifications through channels. But what if some DeFi enabling apps like Zapify or Insert app, they also come in. And now they are sending notifications that also contains RASA subset. And because of that, you know, we realized that having a channel for each specific service makes a lot of sense. And that's what the channel does. The 50 or the number, the amount in coins which you saw in the app,

That basically is the part of the incentivized notification flow, which I spoke about it a bit briefly. But essentially, it's also a stable mechanism feature. So we are a decentralized protocol. That means we don't have a centralized flow. We cannot verify if a channel is good or bad. And we cannot even verify if a channel is what. So what we do is we ask channels who are interested to send notifications to first activate themselves on our protocol. And the way we do it is we tell them that you have to stake some amount of time for your channel to be active.

There's some amount of die is either 50 die or it can go as high as the channel wants. And I'll get into the reason why it is dynamic in a bit. But yeah, once the channel activates themselves, that means they have deposited these dye, we then use this die or we then take this die and we lend it out to our platform. And in turn, of course, we start generating interest on those die. And whenever a subscriber or a user comes in and says, I want notification from this specific service, that user automatically becomes eligible to receive a part of this interest. So that is one way by which we try to incentivize these notifications for the user.

And of course, you know, ensure that the civil mechanism on the protocol is also there. So just one question here. What is the purpose of incentivizing users to receive notifications? I mean, I received notifications. The incentive is the information itself because it's useful to me. It's valuable to be in a context. Why do I need extra incentive, financial incentive to receive a notification? I can say why not, but basically the reason is that if you're a uniswap or if you're Awe, if you're a compound, of course, you know, user wants to receive these notifications.

But yeah, let's say you're running a promotion. At that point of time, you can deposit a higher stake, which will transform into more passive earnings for your users. So it can also be a user engagement and it can also be a way to drive more users to use. protocol or if you have launched a new protocol and you just want eyes on that protocol. So again, the incentive part works very well because, you know, the users are flowing in onto the protocol. Yeah, I'm still not fully seeing it. Like, you know, I could have, you could have built a separate protocol to allow DAPs to pay

their users, but it doesn't seem, it doesn't make sense to me why this is linked in with a notification system. Sure. I mean, the first thing is Sibyl, and that's why we kept the staking fee quite low. This is refundable. So, our service, when they don't want to send notification, they can take the staking fee out. So the first thing to keep in mind is that first and foremost, this is a Sible mechanism. And then, you know, once we build it, we realize that there's a DFI aspect to it.

We can generate passive earnings for the users. So why not go ahead and do that? So what's the Sible attack? What would a service be able to do by sibling? Sure. So one of the thing a person can do is a person can basically create 10,000 of the channels by just creating 10,000 wallets and then just transacting with those wallets. And, you know, if the transaction fee is cheap, especially on the L2 network and even on

the L1 network, the transaction fee is quite cheap to activate a channel. then yeah it basically becomes transaction upon transactions that can be done or executed at a very cheap cost so with this mechanism that you have to deposit 50 diure higher we are essentially telling players that you know if you are serious about signing notifications then this 50 die or higher doesn't really affect you but why does it matter if someone creates a hundred channels if the if users don't subscribe to them, why would it matter? I mean, in a way, our app is also discovering these channels. And at that point of time, it really made sense. And with an incentivize earning in the flow, I mean, not a lot of users have really complained about it. In fact, they're happy about it.

So it kind of really worked out. But also, like, the idea of like, you know, if the minimum is 50 die, putting that on Ave, that's not going to really get that much yield, right? It's going to get like a couple of bucks a year, split over thousands of users. Wasn't the, I feel like the complexity of this entire system of like lending on ABE is just like not even worth it. And plus there is definitely additional gas costs that do, that come with like doing this whole Avey system. Once that just like cancel out all the yields if it's only $50? Yeah, so that's the thing. I mean, for UNISWAP, the user already sees the benefit of the notification.

So they just have to do 50 die. If you look at it from a promotional perspective, let's say a protocol is newly launched and they just want users to know about their protocol. And, you know, if they deposit 10,000 die on their channel, then all of a sudden they will be an influx of users, even if it's for a weekend, you know, after that they did. use it to 50 day. So it's more like a promotional or an incentivized mechanism. For the users, it's more like more of a passive ordaining rather than an active warning. So think of it more like,

you know, in a promotional sense and think of it that if a user is spending some gas cost to opt in or subscribe to a channel, then, you know, if the information is worthwhile for them, then yeah, this kind of makes up for it in the long run. It's unclear to me here, like, who is the target user for this product? Is it, you know, is it end users? So you could look at it one way. It was like, okay, an end user could see value in this because they're going to be notified, like, when there's a liquidation coming or when their domain name expires. And like, that's a clear value for the user who wants to be informed of that information, of that fact.

and but on the other hand like this incentive mechanism this kind of almost like promotional almost like kind of I mean it does seem like a little bit spammy like you know it feels like you just have you know there just have like a bunch of people in there the same people that you'd have in these you know kind of like pumpy telegram groups or whatever like trying to pump you know coins that the projects would have created notifications for like I don't know I guess I don't know who the user, the final user is meant to be. And also this, this whole promotion mechanism just seems a bit off to me. And I don't know like why anyone would, would want to go in there if the interest that they're due to receive is like 50 euros worth of dye, you know, like on, on AVE.

Sure. I mean, there are a couple of ways to look at it. First of all, again, if the service is attractive enough. then the user of course wants notification and they don't really have to care about incentives. So yeah, that's one way to look at it. The second way to look at it is, you know, if the service is gaining popularity or if they're running promotions, then it does make sense for a lot of users who are not based on the western part of the country. Because, you know, while earning two die or three die or four die in a month might not be a lot of good passive earning.

for the users in developed countries, but for the users who are in non-developed countries, it's a way to drive mechanism. It's the same way how, you know, promotions are run, or, you know, why does it make sense to encourage liquidity mining? It makes sense because, you know, you can drive growth to your platform.

And with this way, I mean, we just provided a way. Is that like sustainable growth, though, because if you're talking about, okay, I kind of get that these incentive mechanisms or these promotions or like this, this passive income is useful for, you know, for people who don't have like a high level of income. But, you know, for the platforms on the other side who are like buying, buying this attention, is that really, you know, who they're targeting as users and is that really like sustainable growth? for them if the protocol, like if they just have like a bunch of people in there that are just like trying to get passive income, but don't really care about the protocol. It's just like, oh, here's an opportunity from here. You like to make like two or three bucks a day. Yeah. Wouldn't also people just like subscribe to every possible channel just so they can get the

yield from all of them? Yeah. Actually, nice question. But here is the argument that makes sense because, you know, people who are subscribing to these channels, they are earning a very small passive income. That is getting better over time. So yeah, users can of course go ahead and subscribe to all the channels. But in a sense, you know, most of the time, users

will probably subscribe to channels who they really like or, you know, where the incentivization structure is quite high. And again, that's a thing. I mean, for us, being a decentralized or being a communication middleware, we

have just left these rules open for any services to come and try because, you know, users indicated that they wanted this or service indicated that they wanted. But at the same time, we made it quite flexible so that services, if they think that, you know, incentivized notification is not something which their game theory supports, then they can just take 50 die and that's not going to generate a lot of funding for these users. So in essence, they can play by their own game theory and their own rules. We are not going to force anyone to pay high or low just on that fact. So yeah, that's that's the thing. One of the other things you mentioned, you know, is that it's meant to

compensate the users for the gas costs of like subscribing. Why do I have to make an on-chain transaction to subscribe? That seems kind of unnecessary. I feel like there's some easy ways to design a way to subscribe to channels off-chain by just sending a message or something. Why do I have to subscribe on-chain? We are going to bring meta-transactions into that mix. So, yeah, the services can also offload that cost if they want for their users. But, yeah, on-chain is needed because, again, this is a decentralized communication middleware, and we need to make sure that the user has opted in, or they have.

user wallet has opted in to get notifications from our channel before those notifications can flow through the smart contract or can flow through the service. So that's why that on-chain event is needed. You know, whether it's done on the L2 smart contract of ours or on L1 or true meta-transaction, that's something which we had actively, you know, trying to build. Yeah, I mean, it seems to me like this could also, I'm probably far less technically positioned to answer this. But like it seems that you could post the, post the notifications to IPFS. If they're meant for everyone, like anyone can just kind of pull that data from IPFS directly.

And then so therefore you don't need the on-chain transaction. And if it's sort of data that's meant for a specific user, that data could maybe be encrypted using some kind of handshake mechanism that leverages the user's existing private key and then they would like, so it would also be there on IPFS, but only they would have access to it. And then maybe that would not necessitate that on chain transaction. I don't know. Sunny, does that make sense from a technical perspective?

Yeah, I think so. I mean, you could do something similar. You need a way for the wallets to find out about the IPFS data. But like, I think that there's ways of, I was just talking about this specifically for subscribing. For the IPFS, it will not work. I mean, the only way it will work is if IPNS is somehow connected to IPFS and those IPFS files are getting pinned down.

And again, for the DAP and smart contract, that will not work, because how will they interact with the IPFS? So that is why on-chain transactions are needed. Because, you know, again, these are user wallets. are saying that I allow a service to receive a notification. And I mean, till now, whatever we have done, and again, that's something which we always feel that the protocol should be ever evolving.

But till now, the ways which we have identified is if the user subscribe to it, then the middleware works and follows the rule. If the meta-transaction is executed on behalf of the user, even then that really works. But till now, we haven't really found a way to, you know, make sure that we are verifying these users and getting things on chain or, you know, and getting things somewhere that can be verified that, you know,

our users have done it. So one way is by making the user sign, they consent, but then again, we have to send it to the smart contract in one way or the other because if you are using IPFS again the DAAP and the smart contract link it gets jeopardized so could you tell us now a little bit about you know you mentioned the spam scoring that you guys have to filter channels and stuff how does that work so that was the middle part you know when the user has opted into receive notifications from our service after that what if a service turns malicious or, you know, a service turns evil

or a service is sold to someone or, you know, they had hacked. And at that point of time, we started thinking that, you know, how to protect these users because, you know, at that point of time, a lot of spam can come their way. And that's when we designed the spam score and we are still working on it.

I mean, that's one of the last feature which is getting worked on the protocol to become a version one for the mainnet launch. But yeah, in essence, the spam score essentially will measure the channel positive signals as well as the channel's negative signals. And based on that, it will assign a score to a channel between a score of zero and one. When I say negative signals, they can be higher than usual unsubscribe rate. They can be sending a lot more notifications than, you know, the service is sending. When I talk about positive signals, they can be higher than usual subscribe rates or a passage of time getting passed by.

So yeah, and we are still working on more positive and negative factors. But in essence, they will transform a channel score between 0 and 1. Zero being that the channel is really healthy and 1 being that the channel is really bad or the channel is spamming. at one point of time, if the spam score comes to, let's say, 0.8, the protocol or the smart contract will itself start to throttle the number of notifications a channel can send. And basically, with passage of time, the spam score will decrease bit by bit or, you know, with the subscribe rate or, you know, positive events.

But if the channel continues to do that, then, you know, that 0.8 score will go to 0.9 or even one. And then it becomes a lot tougher for the channel to send notification out until they're back into the healthy range. So that's the spam score. I'm curious about the spam score. Is it meant to be just sort of an indicator for people subscribing to the channel to see, okay, this is a channel that is healthy based on these indicators.

So therefore, I know I'm going into something where I'm going to get actually good information or is it so I guess there's so this this throttling I guess I don't really understand the point if I'm subscribing to a channel I can just unsubscribe if something's spammy I just I just get out of it and I really don't care what the spam score is it's my experience that kind of makes the difference yeah how does that like how do you think about that yeah you can go ahead and unsubscribe and the channel cannot add you back but yeah what we thought was of course you know, that spam score also acts as an indicator that how good a channel is. But yeah, of course, you know, for the users or for the hack channels or for the compromise

channels, this is spam score throttling basically gives us a way or basically gives them a way to kind of correct their behavior. And if they don't, then, you know, even if you're subscribed or, you know, even if you don't want to or are reluctant to unsubscribe, even then, these notifications will stop coming your way, making, you know, the entire ecosystem a little less spam. But yeah, you can definitely go and unsubscribe. These criteria that you've established for the spam index, I mean, do you see a possibility where, like, for example, something that might seem undesirable could actually be something that you just want and could have negative effects?

on the spam score. So let's say, for example, hypothetically, like, I want a notification system that sends me something like every minute. Like, I want some really up-to-date information and maybe I'm not reading it directly, but maybe it's feeding into some other system, right, that's treating the information. Now, that might be useful in my use case, but in terms of the spam score, like, that might be rated as like a low spam score or a high spam score, however you're counting it. How would one mitigate that? Is there a way to? Is, is there a way to? to kind of like inform the system, like, okay, this is what I'm doing and like this is a valid channel. And so therefore like I can, I should send one message per minute.

So data. And again, this is an ever evolving feature. But yeah, there are two ways by which we are trying to approach that solution. One way is again, you as a user, if you are indicating that. So we are building a user specific structure. or a user specific setting within the channel itself. So if you are opting into that, we might be able to, you know, forego the spam throttle and we make the notification go ahead. And the second way which we have just started exploring

is through a social verifying badge or a verifying badge. So when we start the service on the main net, we are going to give the channels who we have verified just a badge or just a flag. And then these services can also give that flag to channels who they think are right or who they think are official. And basically if that flag is present, whether it's our flag or the services who have given other services the flag, then basically we might take the spam control formula in a little less way. So again, this is something, this formula is something which we are still actively developing. Because, yeah, the way you have sent, you know, what if a user wants to receive these notifications, that has to make their way.

Now, one of our investor actually told us about a different use case, which was what if I just subscribe to a channel 10,000 times because I'm a rival of that channel. and then unsubscribe all at once. And that will give me so much of a negative store that I'm killing off competition. And we realize that this is something which we still need to work on to make sure that this doesn't happen. So yeah, we are still working on that formula. But these are the ways which we have identified so far to make sure that the spam school works. Just off the top of my head, I think what you might want is some sort of web of trust. thing where you can see what channels your friends are subscribed to and then go

based off of something like that rather than like because you a web of trust basically help you determine the difference between some random address subscribe to channels versus like you know my trustworthy people relative to me subscribe to certain channels and that's really an awesome idea I'm going to include that and then so then the last thing I want we wanted to talk about is, I guess is maybe two things actually then. One, one is how do you plan on onboarding and incentivizing

wallets to integrate? Like, you know, what you really need is like this will only become successful once you have like MetaMask and Argent and everyone subscribe to this. But then part of the problem is that some of these wallets, you know, their defy integrations are

their like key selling feature. And so how do you convince them to like drop that and like join this open protocol? That's actually a very, very tricky and a very awesome question. We asked this question about, I mean, one thing was there that, you know, we can follow the story of Bitcoin and Ethereum that with enough network effect, people are bound to just integrate. But then we realize that, you know, this is an open protocol. Eventually, we are going to introduce a fee feature for services that are sending notification. What we are going to do is this fee will flow directly from the protocol.

So what we have come up is a win-win scenario for both the crypto wallets that indicate the protocol and for the users or our token holders. What in essence we are doing along with the network effect is that we are telling these crypto wallets, that, hey, if you integrate us, and if you move a proposal, and that proposal is passed through the token holders, then you will get a fee split of whatever revenue the protocol earns. And that thing is completely decentralized. It's completely built on governance.

So in essence, what we are doing with the way we are approaching it is that let's say Metamasker wants to integrate to our protocol, then they integrate the protocol and then they can move our governance feature or governance proposal on our protocol that, hey, we are bringing 1 million users to the protocol. And that means we should get 70% of the fee that is getting generated by the smart contract or the protocol. And if that proposal passes, then perpetually MetaMars will be able to claim 70% of the fee that is getting earned from the protocol. the way we see this entire network effect to take place is getting services to our protocol

and there are three ways by which we are doing that of course we are going to all the services and you're talking and telling them about the advantage of push notifications and now you can send it and we want official notifications to come but yeah that's one thing which we are doing The second thing we are doing is we are creating our own channels, like what Sebastian just said. We have created our channels like VTC tracker, et tracker, et gas. Even now wallet tracker is coming very, very soon.

That will send notifications out for certain activities, whether that's on-chain activities in terms of wallet tracker or off-chain in terms of ad-gaz. That will start to drive the user. and see we are going to offer liquidity mining or usage mining to all the third-party developers who can come and build on our protocol. And in essence, if they're able to bring valid subscribers into the channel, they will start getting our push tokens. Those are governance tokens.

So what we feel is that these three things will eventually drive users to the protocol, which essentially will drive at first, small. services and then higher or top-tier services to the protocol, which in turn will enable revenue generation of short sorts that will start to happen on protocol. And at that point of time, crypto wallets, especially the ones who are suffering from monetization, they will be incentivized to come and integrate our protocol and start showing notification and start taking a share of the kitty. And, you know, this cycle will be dense and repeated every few times as in when we grow to make sure that, you know, the network effect is kind of catalyzed.

The last piece was, you know, the push token that you guys have, you know, in the white paper, it kind of, you open the dock and it reads like a legal document or something with all these disclaimers. And honestly, after reading it, I didn't quite fully understand what the push token is doing. So could you maybe clarify a bit about that? And those legal disclaimers are because of our law is the first version was very, very simple. In essence, push tokens are governance tokens. What they do is they enable or they allow the token holders to control or the core features of the protocol. So some of the things like we discuss is spam trottle or the fee which we'll charge, what we will charge in the future

and other core features of the protocol. The other thing which push tokens also do is enables governance proposals to be passed which enables fee split for the crypto wallets. And the third thing the push token does is because everything is relied on these token holders, they are also eligible to take a part of this fee that is getting generated on the protocol to them.

So yeah. And yeah, the last thing I missed out was the liquidity mining or the usage mining. So we have designed these tokens. We also want to make sure that we attract third party developers, as well as active users and, you know, staking users into our ecosystem. And for those things, push tokens are also useful because, you know, if you're a developer and you're building a channel on our protocol and that drives in valid users, then you will earn a share of those push tokens going forward. Same for active subscriber.

If you are active on our ecosystem and in essence you are not a bot, then you will also start getting push tokens at a variable lead once we hit main net. So in essence, that is what the push tokens do for our protocol. So where can people go to find you and how can people learn more about building on the protocol? So yes, people can visit EPNs.io and that's our website. They can find us over there. But yeah, in case they want to chat about us or, you know, train strong with us for the features,

they should join our telegram group, which is EPNS project. on Telegram or on Twitter with the same handle. And for all the people who want to try the app out, just visit app.EPNS.org or, you know, visit the website and, you know, you can just navigate your way from there. Great. Thanks, Hars. Thanks, Sebastian, and thanks, Sunny. It was great to be here.

And, you know, I kind of picked up a new feature for the protocol. We get a big send out. Great. Thanks. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device,

you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter. So you get new episodes in your inbox. as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter.

And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.