Push Game Theory Explained

In this post, we cover Push in more detail and explain the game theory used in its design.

Push provides a easy and simple way to send notifications to users by different Channel Owners (App Owners). Notifications can be sent via the web, mobile, and Web3.0 providers like Metamask. To ensure consistent messaging throughout the project we have created the following nomenclature of terms, roles that will be used in the rest of the project lifecycle.

• Contract Owner — The owner of the contract, specifically the address by whom the contract is deployed.
• App Owner — Referred to as Channel Owners. The third-party projects, dApps or smart contract, specifically the address which form their identity as well as the custom opt-in group that the subscribed users will receive message from.
• Users — All the users who don’t fall in either of the above categories.
• App Owner Group — Referred to as Channel. The group which contains subscribed users of a particular channel.
• Subscribed Users — The users who have subscribed to a specific channel.

For the purpose of explaining the above EPNS terms, let’s take the example of Youtube and the various associated roles.

• Youtube — Contract Owner
• Channels — App Owner Groups
• Channel Owners — App Owners
• Users — Users
• Subscribed Users — Users subscribed to a specific App owner group

Game Theory -- Push

In order to ensure the proper participation of all roles, following game theory is proposed, features marked with *** will mostly be excluded from the upcoming MVP:

• The contract owner doesn’t have any ability to send messages on behalf of channel owners.
• The channel owners might spoof other trusted apps and thus will have to be verified or a spam system developed so that users can mark them as spoof or a similar mechanism.
• The channel owners need explicit permission from the users before messages can be sent to them.
• The channel owners need to stake some minimum DAI to ensure a spam-free environment, this is going to be minimal but good enough to ascertain good behavior (for example, 50 DAI).
• The users need to transact on blockchain to specifically subscribe or unsubscribe to a channel, this leads to an incentive issue, ie: why would a user spend gas in most cases?
• To counter this, The staked DAI from channel owners can inturn be used as an incentive for users to subscribe to the specific channel.
• This can be done by using services like AAVE to accrue interest on the said DAI and distribute it to the subscribed users group.
• This incentivizes the users to spend gas to perform “subscribe” transaction operation.
• The channel owners can stake more DAI if they want to since the users are incentivized to subscribe.
• The channel owner can blacklist a certain user from their channel if they want to.
• The channel owners can reclaim this DAI back, reclaiming this DAI will also destroy the channel, a fee of 10 DAI will also be held back for the contract owner, the fees is small enough for serious players to not worry about but will act as a further deterrent for bad players.

We would love to hear your feedback and ideas to better the overall experience. Stay tuned for more updates!