Background : Can we pay for user gas fees from the channel staked DAI
High gas fees can create fiction while users opt for notifications. Tho incentives can make it up for rewards in some time but users might not be able to see this. A genuine user is more interested in the notification than the reward he gets from it. He might not opt for notification because of not having enough eth or affordable fee
Can we create a multi transaction layer with the user just signs the message with information and EPNS pays the transaction cost with staked dai and properly envelope the transaction and sends it to the network
Instead of using staked dai for the rewards, we’ll use it to pay for user fees.
With the current reward mechanism, farmers can write bots to get the newly created channels and can always get more rewards from the early weightage and genuine users might get less rewards and might not be able to cover their gas fee of that channel ever. More discussion on reward farming here
- Genuine users will be able to opt for notifications
- Channels will be able to communicate with the right audience
- How to pay fees for early users as nothing got staked yet?
https://opengsn.org/, https://openzeppelin.com - They provide meta transaction layers
Moving into L2 can reduce fees but it’ll not be easy to communicate with dapps outside l2
I’d also argue whether or not an on-chain tx is even required to simply subscribe to notifications. Why is that even a thing?! Surely the average user can consume notifications without interacting with a global ledger, right?
@grasponcrypto If we store the notification user mapping of the chain then it is similar to traditional web2 protocols where companies can control what notification we subscribe to right
the epns network will control that anyway, right? subscriptions on mainnet ledger mean nothing when its up to a second layer to send notifications
We have to verify that users have opted in for that notification right. So that information has to be there whether if we are using l2 or l1 smart contract right. Let’s say even if we store the user channel mapping off-chain maybe in IPFS it’s not very straightforward to read these from the smart contract easily.
Thank you @NandiniAishwarya @grasponcrypto for the proposal and valuable feedbacks.
From collaborations with other protocols and feedback from the community members, we realized the necessity to implement the feature of Gasless opt-in to notifications.
Happy to say that, this has been implemented on our protocol which is live on Mainnet now. Hence closing this topic and discussion here.