├── .gitbook └── assets │ ├── achievements (1).jpg │ ├── achievements.jpg │ ├── achievements.psd │ ├── achievementsgitbook.jpg │ ├── achievementsgsheetv4litepaper (1).jpg │ ├── achievementsgsheetv4litepaper (2).jpg │ ├── achievementsgsheetv4litepaper.jpg │ ├── darkyoutube.jpg │ ├── epnscoverwelcome.jpg │ ├── founder.jpg │ ├── harsh.png │ ├── highleveldefi (1).jpg │ ├── highleveldefi (2).jpg │ ├── highleveldefi.jpg │ ├── img_c16f41ec1f18-1.jpeg │ ├── inputdappserverless.png │ ├── inputserver.png │ ├── inputsmartcontract.png │ ├── logo.jpg │ ├── logofulltaglinesquarsmall.jpg │ ├── milestones.jpg │ ├── milestonesgitbook.jpg │ ├── plainmockup.png │ ├── plainmockupglow.jpg │ └── richa.png ├── .gitignore ├── Ethereum Push Notification Service Litepaper.pdf ├── README.md ├── SUMMARY.md ├── disclaimer.md ├── future-features-research.md ├── governance-section ├── governance.md └── governance │ ├── README.md │ ├── game-theory.md │ └── usage-and-design.md ├── index.md ├── introduction-section └── introduction │ ├── README.md │ ├── basic-definitions.md │ └── high-level-application-flow-diagram.md ├── pdf-version └── EthereumPushNotificationServiceWhitepaperDraft.pdf ├── protocol-specs-section ├── epns-protocol │ ├── README.md │ ├── channels │ │ ├── README.md │ │ ├── channel-activation-deactivation.md │ │ ├── channels-registry.md │ │ ├── deriving-fair-share-of-interest-for-a-channel-from-stake-pool.md │ │ ├── deriving-fair-share-of-token-incentives-for-a-channel-from-stake-pool.md │ │ ├── spam-rating-and-throttling.md │ │ ├── special-channels.md │ │ ├── types-of-channels.md │ │ └── updating-channel.md │ ├── claiming-earnings-from-protocol.md │ ├── sending-notifications │ │ ├── README.md │ │ ├── delegation-of-notifications.md │ │ └── notifications-abi.md │ ├── subscribers │ │ ├── README.md │ │ ├── deriving-weighted-earnings-of-a-subscriber-of-a-channel.md │ │ ├── indirect-subscribe-action-delegate-subscription-of-user-by-channel.md │ │ ├── subscribing-to-channel.md │ │ ├── unsubscribing-from-channel.md │ │ └── user-direct-action-subscribe.md │ └── users │ │ ├── README.md │ │ ├── public-key-registry.md │ │ └── users-registry.md ├── future-features-research.md ├── protocol-integration-flow │ ├── README.md │ ├── creating-channel-on-protocol.md │ ├── introduction-to-push-nodes.md │ ├── sending-notification-dapp.md │ ├── sending-notification-from-server.md │ └── sending-notification-from-smart-contract.md ├── specifications │ ├── README.md │ ├── channel-payload-specs.md │ └── notification-payload-specs.md └── the-epns-product.md ├── protocol-specs ├── epns-protocol │ └── protocol-integration-flow │ │ ├── README.md │ │ └── creating-channel.md ├── the-epns-product │ ├── epns-infra-push-service.md │ ├── js-library.md │ └── showrunners.md └── the-epns-protocol │ └── activation-of-a-service.md ├── references-section └── references.md ├── risks └── risks.md ├── summary-section └── summary.md └── team-and-acheivements-section ├── achievements.md └── founders.md /.gitbook/assets/achievements (1).jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/achievements (1).jpg -------------------------------------------------------------------------------- /.gitbook/assets/achievements.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/achievements.jpg -------------------------------------------------------------------------------- /.gitbook/assets/achievements.psd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/achievements.psd -------------------------------------------------------------------------------- /.gitbook/assets/achievementsgitbook.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/achievementsgitbook.jpg -------------------------------------------------------------------------------- /.gitbook/assets/achievementsgsheetv4litepaper (1).jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/achievementsgsheetv4litepaper (1).jpg -------------------------------------------------------------------------------- /.gitbook/assets/achievementsgsheetv4litepaper (2).jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/achievementsgsheetv4litepaper (2).jpg -------------------------------------------------------------------------------- /.gitbook/assets/achievementsgsheetv4litepaper.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/achievementsgsheetv4litepaper.jpg -------------------------------------------------------------------------------- /.gitbook/assets/darkyoutube.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/darkyoutube.jpg -------------------------------------------------------------------------------- /.gitbook/assets/epnscoverwelcome.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/epnscoverwelcome.jpg -------------------------------------------------------------------------------- /.gitbook/assets/founder.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/founder.jpg -------------------------------------------------------------------------------- /.gitbook/assets/harsh.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/harsh.png -------------------------------------------------------------------------------- /.gitbook/assets/highleveldefi (1).jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/highleveldefi (1).jpg -------------------------------------------------------------------------------- /.gitbook/assets/highleveldefi (2).jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/highleveldefi (2).jpg -------------------------------------------------------------------------------- /.gitbook/assets/highleveldefi.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/highleveldefi.jpg -------------------------------------------------------------------------------- /.gitbook/assets/img_c16f41ec1f18-1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/img_c16f41ec1f18-1.jpeg -------------------------------------------------------------------------------- /.gitbook/assets/inputdappserverless.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/inputdappserverless.png -------------------------------------------------------------------------------- /.gitbook/assets/inputserver.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/inputserver.png -------------------------------------------------------------------------------- /.gitbook/assets/inputsmartcontract.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/inputsmartcontract.png -------------------------------------------------------------------------------- /.gitbook/assets/logo.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/logo.jpg -------------------------------------------------------------------------------- /.gitbook/assets/logofulltaglinesquarsmall.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/logofulltaglinesquarsmall.jpg -------------------------------------------------------------------------------- /.gitbook/assets/milestones.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/milestones.jpg -------------------------------------------------------------------------------- /.gitbook/assets/milestonesgitbook.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/milestonesgitbook.jpg -------------------------------------------------------------------------------- /.gitbook/assets/plainmockup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/plainmockup.png -------------------------------------------------------------------------------- /.gitbook/assets/plainmockupglow.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/plainmockupglow.jpg -------------------------------------------------------------------------------- /.gitbook/assets/richa.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/.gitbook/assets/richa.png -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | -------------------------------------------------------------------------------- /Ethereum Push Notification Service Litepaper.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/Ethereum Push Notification Service Litepaper.pdf -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | A decentralized Notification protocol that enables users (wallet addresses) to 4 | receive notifications and obtain token incentives through active 5 | participation. 6 | --- 7 | 8 | # Push Protocol (EPNS) 9 | 10 | {% hint style="info" %} 11 | **Whitepaper is written for Ethereum Blockchain, as PUSH protocol is moving to multi-chain. Some of the info might be outdated.** 12 | {% endhint %} 13 | 14 | ![](.gitbook/assets/logofulltaglinesquarsmall.jpg) 15 | 16 | **Abstract** 17 | 18 | The document introduces a decentralized notifications protocol that enables wallet addresses to receive notifications in platform agnostic fashion from both decentralized and centralized carriers. It also explores and describes the theory and technical aspects of the protocol / platform and the game theory that the protocol utilizes to ensure incentives for good actors in the ecosystem. 19 | 20 | > **`Authors: Harsh Rajat, Richa Joshi | founders@epns.io`** 21 | 22 | > **`Whitepaper Version 1.0 | June 2020`** 23 | > 24 | > **`Last Updated: 16th November, 2020`** 25 | 26 | {% hint style="info" %} 27 | **`Draft for community review and subject to change`** 28 | {% endhint %} 29 | 30 | {% hint style="info" %} 31 | **Whitepaper is written for Ethereum Blockchain, as PUSH protocol is moving to multi-chain. Some of the info might be outdated.** 32 | {% endhint %} 33 | 34 | {% hint style="info" %} 35 | To know more, please visit [Developer docs](https://docs.epns.io/developers). 36 | {% endhint %} 37 | 38 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Table of contents 2 | 3 | * [Ethereum Push Notification Service (EPNS)](README.md) 4 | * [DISCLAIMER](disclaimer.md) 5 | * [Index](index.md) 6 | 7 | ## Introduction 8 | 9 | * [Introduction](introduction-section/introduction/README.md) 10 | * [Protocol / Product Flow](introduction-section/introduction/high-level-application-flow-diagram.md) 11 | * [Basic Definitions](introduction-section/introduction/basic-definitions.md) 12 | 13 | ## Specs and Architecture 14 | 15 | * [Specifications](protocol-specs-section/specifications/README.md) 16 | * [Channel Payload Specs](protocol-specs-section/specifications/channel-payload-specs.md) 17 | * [Notification Payload Specs](protocol-specs-section/specifications/notification-payload-specs.md) 18 | * [EPNS Protocol](protocol-specs-section/epns-protocol/README.md) 19 | * [Users](protocol-specs-section/epns-protocol/users/README.md) 20 | * [Users Registry](protocol-specs-section/epns-protocol/users/users-registry.md) 21 | * [Public Key Registry](protocol-specs-section/epns-protocol/users/public-key-registry.md) 22 | * [Channels](protocol-specs-section/epns-protocol/channels/README.md) 23 | * [Types of Channels](protocol-specs-section/epns-protocol/channels/types-of-channels.md) 24 | * [Channels Registry](protocol-specs-section/epns-protocol/channels/channels-registry.md) 25 | * [Special Channels](protocol-specs-section/epns-protocol/channels/special-channels.md) 26 | * [Channel Activation & Deactivation](protocol-specs-section/epns-protocol/channels/channel-activation-deactivation.md) 27 | * [Deriving fair share of token incentives for a channel from stake pool](protocol-specs-section/epns-protocol/channels/deriving-fair-share-of-token-incentives-for-a-channel-from-stake-pool.md) 28 | * [Updating Channel](protocol-specs-section/epns-protocol/channels/updating-channel.md) 29 | * [Spam score and throttling](protocol-specs-section/epns-protocol/channels/spam-rating-and-throttling.md) 30 | * [Subscribers](protocol-specs-section/epns-protocol/subscribers/README.md) 31 | * [Subscribing to Channel](protocol-specs-section/epns-protocol/subscribers/subscribing-to-channel.md) 32 | * [User direct action subscribe](protocol-specs-section/epns-protocol/subscribers/user-direct-action-subscribe.md) 33 | * [Deriving weighted accumulated token incentives of a subscriber of a channel](protocol-specs-section/epns-protocol/subscribers/deriving-weighted-earnings-of-a-subscriber-of-a-channel.md) 34 | * [Indirect subscribe action (delegate subscription of user by channel)](protocol-specs-section/epns-protocol/subscribers/indirect-subscribe-action-delegate-subscription-of-user-by-channel.md) 35 | * [Unsubscribing from Channel](protocol-specs-section/epns-protocol/subscribers/unsubscribing-from-channel.md) 36 | * [Sending Notifications](protocol-specs-section/epns-protocol/sending-notifications/README.md) 37 | * [Protocol Interfacing for Notifications](protocol-specs-section/epns-protocol/sending-notifications/notifications-abi.md) 38 | * [Delegation of Notifications](protocol-specs-section/epns-protocol/sending-notifications/delegation-of-notifications.md) 39 | * [Claiming Token incentives from Protocol](protocol-specs-section/epns-protocol/claiming-earnings-from-protocol.md) 40 | * [EPNS Products](protocol-specs-section/the-epns-product.md) 41 | * [Integration Flow for dApp / Server / Smart Contract](protocol-specs-section/protocol-integration-flow/README.md) 42 | * [Creating Channel on dApp / Server / Smart Contract](protocol-specs-section/protocol-integration-flow/creating-channel-on-protocol.md) 43 | * [Sending Notification from dApp / Serverless](protocol-specs-section/protocol-integration-flow/sending-notification-dapp.md) 44 | * [Sending Notification from Server](protocol-specs-section/protocol-integration-flow/sending-notification-from-server.md) 45 | * [Sending Notification from Smart Contract](protocol-specs-section/protocol-integration-flow/sending-notification-from-smart-contract.md) 46 | * [Introduction to Push Nodes](protocol-specs-section/protocol-integration-flow/introduction-to-push-nodes.md) 47 | * [Future Features & Research](protocol-specs-section/future-features-research.md) 48 | 49 | ## Governance 50 | 51 | * [Governance](governance-section/governance/README.md) 52 | * [Usage and Design](governance-section/governance/usage-and-design.md) 53 | * [Game Theory](governance-section/governance/game-theory.md) 54 | 55 | ## Risks 56 | 57 | * [Risks](risks/risks.md) 58 | 59 | ## Summary 60 | 61 | * [Summary](summary-section/summary.md) 62 | 63 | ## Team & Acheivements 64 | 65 | * [Founders](team-and-acheivements-section/founders.md) 66 | * [Achievements](team-and-acheivements-section/achievements.md) 67 | 68 | ## References 69 | 70 | * [References](references-section/references.md) 71 | -------------------------------------------------------------------------------- /disclaimer.md: -------------------------------------------------------------------------------- 1 | # DISCLAIMER 2 | 3 | PLEASE READ THE ENTIRETY OF THIS "DISCLAIMER" SECTION CAREFULLY. NOTHING HEREIN CONSTITUTES LEGAL, FINANCIAL, BUSINESS OR TAX ADVICE AND YOU SHOULD CONSULT YOUR OWN LEGAL, FINANCIAL, TAX OR OTHER PROFESSIONAL ADVISOR\(S\) BEFORE ENGAGING IN ANY ACTIVITY IN CONNECTION HEREWITH. NEITHER ETHEREUM PUSH NOTIFICATION SERVICE FOUNDATION \(THE **COMPANY**\), ANY OF THE PROJECT TEAM MEMBERS \(THE **EPNS TEAM**\) WHO HAVE WORKED ON THE EPNS PROTOCOL \(AS DEFINED HEREIN\) OR PROJECT TO DEVELOP THE EPNS PROTOCOL IN ANY WAY WHATSOEVER, ANY DISTRIBUTOR/VENDOR OF $PUSH TOKENS, INCLUDING WITHOUT LIMITATION ETHEREUM PUSH NOTIFICATION SERVICE LIMITED \(THE DISTRIBUTOR\), NOR ANY SERVICE PROVIDER SHALL BE LIABLE FOR ANY KIND OF DIRECT OR INDIRECT DAMAGE OR LOSS WHATSOEVER WHICH YOU MAY SUFFER IN CONNECTION WITH ACCESSING THIS WHITEPAPER, THE WEBSITE AT HTTPS://EPNS.IO/ \(THE **WEBSITE**\) OR ANY OTHER WEBSITES OR MATERIALS PUBLISHED BY THE COMPANY. 4 | 5 | ## Project purpose 6 | 7 | All contributions will be applied towards the advancing, promoting the research, design and development of, and advocacy for the missing piece of web 3.0 infrastructure with the introduction of the decentralized notification protocol. The Company, the Distributor and their respective affiliates would develop, manage and operate the EPNS protocol. The Company is acting solely as an arms’ length third party in relation to the $PUSH sale, and not in the capacity as a financial adviser or fiduciary of any person with regard to the sale of $PUSH. 8 | 9 | ## Nature of the Whitepaper 10 | 11 | The Whitepaper and the Website are intended for general informational purposes only and do not constitute a prospectus, an offer document, an offer of securities, a solicitation for investment, or any offer to sell any product, item or asset \(whether digital or otherwise\). The information herein may not be exhaustive and does not imply any element of a contractual relationship. There is no assurance as to the accuracy or completeness of such information and no representation, warranty or undertaking is or purported to be provided as to the accuracy or completeness of such information. Where the Whitepaper or the Website includes information that has been obtained from third party sources, the Company, the Distributor, their respective affiliates and/or the EPNS team have not independently verified the accuracy or completion of such information. Further, you acknowledge that circumstances may change and that the Whitepaper or the Website may become outdated as a result; and neither the Company nor the Distributor is under any obligation to update or correct this document in connection therewith. 12 | 13 | ## **Token Documentation** 14 | 15 | Nothing in the Whitepaper or the Website constitutes any offer by the Company, the Distributor or the EPNS team to sell any $PUSH \(as defined herein\) nor shall it or any part of it nor the fact of its presentation form the basis of, or be relied upon in connection with, any contract or investment decision. Nothing contained in the Whitepaper or the Website is or may be relied upon as a promise, representation or undertaking as to the future performance of the EPNS protocol. The agreement between the Distributor \(or any third party\) and you, in relation to any sale, purchase, or other distribution or transfer of $PUSH, is to be governed only by the separate terms and conditions of such agreement. 16 | 17 | The information set out in the Whitepaper and the Website is for community discussion only and is not legally binding. No person is bound to enter into any contract or binding legal commitment in relation to the acquisition of $PUSH, and no virtual currency or other form of payment is to be accepted on the basis of the Whitepaper or the Website. The agreement for sale and purchase of $PUSH and/or continued holding of $PUSH shall be governed by a separate set of Terms and Conditions or Token Purchase Agreement \(as the case may be\) setting out the terms of such purchase and/or continued holding of $PUSH \(the Terms and Conditions\), which shall be separately provided to you or made available on the Website. The Terms and Conditions Documentation must be read together with the Whitepaper. In the event of any inconsistencies between the Terms and Conditions and the Whitepaper or the Website, the Terms and Conditions shall prevail. 18 | 19 | ## **Deemed Representations and Warranties** 20 | 21 | By accessing the Whitepaper or the Website \(or any part thereof\), you shall be deemed to represent and warrant to the Company, the Distributor, their respective affiliates, and the EPNS team as follows: 22 | 23 | * In any decision to purchase any $PUSH, you have shall not rely on any statement set out in the Whitepaper or the Website; 24 | * You will and shall at your own expense ensure compliance with all laws, regulatory requirements and restrictions applicable to you \(as the case may be\); 25 | * You acknowledge, understand and agree that $PUSH may have no value, there is no guarantee or representation of value or liquidity for $PUSH, and $PUSH is not an investment product including for any speculative investment; 26 | * None of the Company, the Distributor, their respective affiliates, and/or the EPNS team members shall be responsible for or liable for the value of $PUSH, the transferability and/or liquidity of $PUSH and/or the availability of any market for $PUSH through third parties or otherwise; and 27 | * You acknowledge, understand and agree that you are not eligible to purchase any $PUSH if you are a citizen, national, resident \(tax or otherwise\), domiciliary and/or green card holder of a geographic area or country \(i\) where it is likely that the sale of $PUSH would be construed as the sale of a security \(howsoever named\), financial service or investment product and/or \(ii\) where participation in token sales is prohibited by applicable law, decree, regulation, treaty, or administrative act \(including without limitation the United States of America, Canada, New Zealand, People's Republic of China \(but not including the special administrative regions of Hong Kong and Macau, and the territory of Taiwan\), Thailand, and the Socialist Republic of Vietnam\); and to this effect you agree to provide all such identity verification document when requested in order for the relevant checks to be carried out. 28 | 29 | The Company, the Distributor and the EPNS team do not and do not purport to make, and hereby disclaims, all representations, warranties or undertaking to any entity or person \(including without limitation warranties as to the accuracy, completeness, timeliness or reliability of the contents of the Whitepaper or the Website, or any other materials published by the Company or the Distributor\). To the maximum extent permitted by law, the Company, the Distributor, their respective affiliates and service providers shall not be liable for any indirect, special, incidental, consequential or other losses of any kind, in tort, contract or otherwise \(including, without limitation, any liability arising from default or negligence on the part of any of them, or any loss of revenue, income or profits, and loss of use or data\) arising from the use of the Whitepaper or the Website, or any other materials published, or its contents \(including without limitation any errors or omissions\) or otherwise arising in connection with the same. Prospective purchasers of $PUSH should carefully consider and evaluate all risks and uncertainties \(including financial and legal risks and uncertainties\) associated with the $PUSH token sale, the Company, the Distributor and the EPNS team. 30 | 31 | ## Informational purposes only 32 | 33 | The information set out herein is only conceptual, and describes the future development goals for the EPNS protocol to be developed. In particular, the project roadmap in the Whitepaper is being shared in order to outline some of the plans of the EPNS team, and is provided solely for **INFORMATIONAL PURPOSES** and does not constitute any binding commitment. Please do not rely on this information in making purchasing decisions because ultimately, the development, release, and timing of any products, features or functionality remains at the sole discretion of the Company, the Distributor or their respective affiliates, and is subject to change. Further, the Whitepaper or the Website may be amended or replaced from time to time. There are no obligations to update the Whitepaper or the Website, or to provide recipients with access to any information beyond what is provided herein. 34 | 35 | ## Regulatory approval 36 | 37 | No regulatory authority has examined or approved, whether formally or informally, of any of the information set out in the Whitepaper or the Website. No such action or assurance has been or will be taken under the laws, regulatory requirements or rules of any jurisdiction. The publication, distribution or dissemination of the Whitepaper or the Website does not imply that the applicable laws, regulatory requirements or rules have been complied with. 38 | 39 | ## Cautionary Note on forward-looking statements 40 | 41 | All statements contained herein, statements made in press releases or in any place accessible by the public and oral statements that may be made by the Company, the Distributor and/or the EPNS team, may constitute forward-looking statements \(including statements regarding intent, belief or current expectations with respect to market conditions, business strategy and plans, financial condition, specific provisions and risk management practices\). You are cautioned not to place undue reliance on these forward-looking statements given that these statements involve known and unknown risks, uncertainties and other factors that may cause the actual future results to be materially different from that described by such forward-looking statements, and no independent third party has reviewed the reasonableness of any such statements or assumptions. These forward-looking statements are applicable only as of the date indicated in the Whitepaper, and the Company, the Distributor as well as the EPNS team expressly disclaim any responsibility \(whether express or implied\) to release any revisions to these forward-looking statements to reflect events after such date. 42 | 43 | ## References to companies and platforms 44 | 45 | The use of any company and/or platform names or trademarks herein \(save for those which relate to the Company, the Distributor or their respective affiliates\) does not imply any affiliation with, or endorsement by, any third party. References in the Whitepaper or the Website to specific companies and platforms are for illustrative purposes only. 46 | 47 | ## English language 48 | 49 | The Whitepaper and the Website may be translated into a language other than English for reference purpose only and in the event of conflict or ambiguity between the English language version and translated versions of the Whitepaper or the Website, the English language versions shall prevail. You acknowledge that you have read and understood the English language version of the Whitepaper and the Website. 50 | 51 | ## No Distribution 52 | 53 | No part of the Whitepaper or the Website is to be copied, reproduced, distributed or disseminated in any way without the prior written consent of the Company or the Distributor. By attending any presentation on this Whitepaper or by accepting any hard or soft copy of the Whitepaper, you agree to be bound by the foregoing limitations. 54 | 55 | -------------------------------------------------------------------------------- /future-features-research.md: -------------------------------------------------------------------------------- 1 | # Future Features Research 2 | 3 | The following features are getting researched and are expected to change 4 | 5 | -------------------------------------------------------------------------------- /governance-section/governance.md: -------------------------------------------------------------------------------- 1 | # Governance 2 | 3 | The protocol token has the following major functions that it performs: 4 | 5 | * Getting share from fee pool \(80% of the fee, split in equal parts for token holders\). 6 | * Setting up the price for micro-payment fees. 7 | * Setting up the fee for indirect subscribe action. 8 | * Penalty fee for Channel updating. 9 | * Removing a channel permanently. 10 | * Adjusting spam throttle. 11 | 12 | 13 | 14 | -------------------------------------------------------------------------------- /governance-section/governance/README.md: -------------------------------------------------------------------------------- 1 | # Governance 2 | 3 | The protocol tokens \(**$PUSH**\) are designed to incentivize continued adoption cycle for the EPNS protocol. This is achieved by ensuring incentives for all the users involved by rewarding or encouraging them through incentives and penalty, their continued involvement is seen to be necessary for the growth and adoption of the protocol and to achieve the **vision of becoming web3 notification standard**. 4 | 5 | ## Users of EPNS 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 18 | 21 | 22 | 23 | 25 | 27 | 28 | 29 | 31 | 37 | 38 | 39 | 41 | 42 | 43 | 44 |
CategoryDescription
Service Providers 17 | Any dApp / protocol / services that want to send notifications. These 19 | are envisioned to be direct service owners (like AAVE, Compound, Cryptokitties, 20 | etc) or third party vendors who can build on behalf of these services.
Users 24 | ​People who want to receive notifications as that is beneficial 26 | for them.
Wallets / Infra Services 30 | 32 |

Wallets / other infrastructure building on top of protocol that

33 |

enables users to receive notifications through their centralized or decentralized 34 | solution (mobile app, web browser, user wallets like metamask, trust, etc). 35 | Includes the EPNS infra which does delivery.

36 |
Token Holders 40 | People who hold tokens and define the rules between the above 3 players.
45 | 46 | -------------------------------------------------------------------------------- /governance-section/governance/game-theory.md: -------------------------------------------------------------------------------- 1 | # Game Theory 2 | 3 | The game theory of governance is designed keeping in mind all participating users of the EPNS ecosystem. The more users the protocol has, more services will come leading to an increase in fees pool and rewards leading to direct impact on the token utility as the token is intrinsically linked to protocol growth, being a key medium of exchange for all activities occurring thereon. 4 | 5 | ## Game Theory 6 | 7 | 1. **Service Providers** ​are already incentivized to send notifications as it brings them on par with web2 experience, and with platform agnostic and incentivized notifications, we can even go ahead and state that EPNS betters the current notification game of web2 / centralized. The subsection of this will also be ​**vendors** ​who are third party developers that will be creating channels to capitalize on liquidity mining. 8 | 2. **Users**​ are incentivized as they want to receive notifications related to payments, DeFi, gaming or service​ ​on web 3. As can be seen by traditional services \(web 2\) and the rampant use of notifications to drive engagement which is working and has become a part of all of our daily lives. Users also benefit by ​**receiving token incentives from notifications** ​and by **universal delivery**​. 9 | 3. **Wallets / Infra Services** 10 | * **Existing Wallets / Services** ​are incentivized to continue performing as that ensures their perpetual share from the integration partners pool. 11 | * **Future Wallets** ​are incentivized to integrate with the growing reward pool of **EDP**, ​as​ ​it gets higher over time as more fee flows in the protocol \(as more and more notifications are sent\). This creates an incentive for future wallets to consider integration to protocol to claim this reward and also to move a proposal to have perpetual share in the Integration partners pool. 12 | * **Note:** ​The integration in turn drives more users to the protocol which drives more services and thus an increase in the fees pool which starts the cycle of future wallets integration again. 13 | 4. **Token Holders** ​are incentivized to keep and to pass the best proposal and keep core features fees competitive at the best rate possible as they gain the most of all the participating users are properly incentivized as it drives utility to the protocol and the usage of protocol. 14 | 15 | **Example:**​ More users means more services want to integrate which drives up the fees present in the fees pool \(and in turn the integration partner pool and the reward pool\), this encourages more wallets to support the protocol which ensures more users in the ecosystem. We see the network effect to work on smaller wallets first and then bigger as the EDP funds start to increase due to the above scenario leading to bigger wallets considering integration and thus starting the cycle again. 16 | 17 | -------------------------------------------------------------------------------- /governance-section/governance/usage-and-design.md: -------------------------------------------------------------------------------- 1 | # Usage and Design 2 | 3 | The native digital cryptographically-secured utility token of the EPNS protocol \(**$PUSH**\) is a transferable representation of attributed functions specified in the protocol/code of the EPNS protocol, which is designed to play a major role in the functioning of the ecosystem on the EPNS protocol and intended to be used solely as the primary utility token on the network. 4 | 5 | $PUSH is a non-refundable functional utility token which will be used as the medium of exchange between participants on the EPNS protocol. The goal of introducing $PUSH is to provide a convenient and secure mode of payment and settlement between participants who interact within the ecosystem on the EPNS protocol, and it is not, and not intended to be, a medium of exchange accepted by the public \(or a section of the public\) as payment for goods or services or for the discharge of a debt; nor is it designed or intended to be used by any person as payment for any goods or services whatsoever that are not exclusively provided by the issuer. $PUSH does not in any way represent any shareholding, participation, right, title, or interest in the Company, the Distributor, their respective affiliates, or any other company, enterprise or undertaking, nor will $PUSH entitle token holders to any promise of fees, dividends, revenue, profits or investment returns, and are not intended to constitute securities in Singapore or any relevant jurisdiction. $PUSH may only be utilised on the EPNS protocol, and ownership of $PUSH carries no rights, express or implied, other than the right to use $PUSH as a means to enable usage of and interaction within the EPNS protocol. 6 | 7 | $PUSH also provides the economic incentives which will be consumed to encourage users to contribute and maintain the ecosystem on the EPNS protocol, thereby creating a win-win system where every participant is fairly compensated for its efforts. $PUSH is an integral and indispensable part of the EPNS protocol, because without $PUSH, there would be no incentive for users to expend resources to participate in activities or provide services for the benefit of the entire ecosystem on the EPNS protocol. Users of the EPNS protocol and/or holders of $PUSH which did not actively participate will not receive any $PUSH incentives. 8 | 9 | $PUSH tokens are used to control various core functionalities of the EPNS protocol, allowing users to vote on features of the protocol. For the avoidance of doubt, the right to vote is restricted solely to voting on features of the EPNS protocol; the right to vote does not entitle $PUSH holders to vote on the operation and management of the Company, the Distributor or their respective affiliates, or their assets, and does not constitute any equity interest in any of the aforementioned entities. For example, the protocol fees are charged in **$ETH** or **$DAI** within the EPNS protocol, but the $PUSH token holders may vote to change these fee parameters. 10 | 11 | All fees collected from the EPNS protocol usage forms the ​**Fees pool** ​and will be distributed in the following proportion: 12 | 13 | **30%​** of **Fees Pool** forms **Ecosystem development pool** 14 | 15 | | **Ecosystem development pool \(EDP\)​ Breakdown** | | 16 | | :--- | :--- | 17 | | \*\*\*\* | **x%**​ for Integration partners pool | 18 | | | **y%**​ for Future integration reward pool | 19 | | | Where​ **x%**​ + **​y%**​ = ​**100%​** of **E​DP** | 20 | 21 | The major decision and usage of the protocol tokens are: 22 | 23 | * **Protocol Fees:** ​Defining micro-fees paid per notifications by the service provider. 24 | * **Protocol Fees:** ​Defining monthly/yearly subscription fees. 25 | * **Protocol Fees:** ​Defining Indirect subscription fees percentage to be taken when a service provider adds a wallet address without the explicit consent of the user. 26 | * **Protocol Fees:​** Defining Penalty fees for updating service name, icon, url, etc. 27 | * **Governance:** ​Configuring SPAM throttle index. 28 | * **Governance:**​ Adjusting percentage allocation of various Integration partners pool from ecosystem development pool through governance proposal. 29 | * **Governance:** ​Adjusting percentage allocation of Future integration reward pool from ecosystem development pool through governance proposal. 30 | * **Staking and Voting:** ​Token holders are allowed to create and move proposals by staking certain percentage of tokens to put them up for voting. These tokens are locked and are eligible for withdrawal only after a 30 day locking period to ensure serious users perform such functions. 31 | * **Liquidity Mining:​** Service providers will be rewarded with our tokens for the next few years for increasing their activities within the ecosystem, with more rewards going to higher subscriber count and notifications sent. This will create a new subsection of service providers \(ie: vendor\), that are third party developers who are not affiliated to official services but create channels to capitalize on token rewards for providing quality content. 32 | * **Liquidity Mining:** ​To encourage more users to vote on proposals and to enable further decentralization, the voting will result in rewards in terms of governance tokens. 33 | * **User incentives:** Users will be able to receive token incentives based on some of their direct or indirect actions within the EPNS protocol, for example directly subscribing to channels, or being indirectly subscribed by a channel \(channel pays user either the default minor reward, or the reward expectation set by the individual user\). 34 | * **Note:** ​When a user withdraws their token incentives, the aDAI accrued is swapped for the protocol’s governance token and is given to them. 35 | 36 | $PUSH are designed to be consumed/utilised, and that is the goal of the $PUSH token sale. In fact, the project to develop the EPNS protocol would fail if all $PUSH holders simply held onto their $PUSH and did nothing with it. In particular, it is highlighted that $PUSH: \(a\) does not have any tangible or physical manifestation, and does not have any intrinsic value \(nor does any person make any representation or give any commitment as to its value\); \(b\) is non-refundable and cannot be exchanged for cash \(or its equivalent value in any other virtual currency\) or any payment obligation by the Company, the Distributor or any of their respective affiliates; \(c\) does not represent or confer on the token holder any right of any form with respect to the Company, the Distributor \(or any of their respective affiliates\), or its revenues or assets, including without limitation any right to receive future dividends, revenue, shares, ownership right or stake, share or security, any voting, distribution, redemption, liquidation, proprietary \(including all forms of intellectual property or licence rights\), right to receive accounts, financial statements or other financial data, the right to requisition or participate in shareholder meetings, the right to nominate a director, or other financial or legal rights or equivalent rights, or intellectual property rights or any other form of participation in or relating to the EPNS protocol, the Company, the Distributor and/or their service providers; \(d\) is not intended to represent any rights under a contract for differences or under any other contract the purpose or pretended purpose of which is to secure a profit or avoid a loss; \(e\) is not intended to be a representation of money \(including electronic money\), security, commodity, bond, debt instrument, unit in a collective investment scheme or any other kind of financial instrument or investment; \(f\) is not a loan to the Company, the Distributor or any of their respective affiliates, is not intended to represent a debt owed by the Company, the Distributor or any of their respective affiliates, and there is no expectation of profit; and \(g\) does not provide the token holder with any ownership or other interest in the Company, the Distributor or any of their respective affiliates. 37 | 38 | The contributions in the token sale will be held by the Distributor \(or their respective affiliate\) after the token sale, and contributors will have no economic or legal right over or beneficial interest in these contributions or the assets of that entity after the token sale. 39 | 40 | To the extent a secondary market or exchange for trading $PUSH does develop, it would be run and operated wholly independently of the Company, the Distributor, the sale of $PUSH and the EPNS protocol. Neither the Company nor the Distributor will create such secondary markets nor will either entity act as an exchange for $PUSH. 41 | 42 | {% hint style="warning" %} 43 | The token design and usage is still in discussion and might result in some further tweaks in design. The document specs will freeze as we move from draft to final. 44 | {% endhint %} 45 | 46 | -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | # Index 2 | 3 | [Ethereum Push Notification Service \(EPNS\) Abstract](./) 4 | 5 | [DISCLAIMER](disclaimer.md) 6 | 7 | 1 [Introduction](introduction-section/introduction/) 8 | 9 | 1.1 [Protocol / Product Flow](introduction-section/introduction/high-level-application-flow-diagram.md) 10 | 11 | 1.2 [Basic Definitions](introduction-section/introduction/basic-definitions.md) 12 | 13 | 2 [Specifications](protocol-specs-section/specifications/) 14 | 15 | 2.1 [Channel Payload Specs](protocol-specs-section/specifications/channel-payload-specs.md) 16 | 17 | 2.2 [Notification Payload Specs](protocol-specs-section/specifications/notification-payload-specs.md) 18 | 19 | 3 [EPNS Protocol](protocol-specs-section/epns-protocol/) 20 | 21 | 3.1 [Users](protocol-specs-section/epns-protocol/users/) 22 | 23 | 3.1.1 [Users Registry](protocol-specs-section/epns-protocol/users/users-registry.md) 24 | 25 | 3.1.2 [Public Key Registry](protocol-specs-section/epns-protocol/users/public-key-registry.md) 26 | 27 | 3.2 [Channels](protocol-specs-section/epns-protocol/channels/) 28 | 29 | 3.2.1 [Types of Channels](protocol-specs-section/epns-protocol/channels/types-of-channels.md) 30 | 31 | 3.2.2 [Channels Registry](protocol-specs-section/epns-protocol/channels/channels-registry.md) 32 | 33 | 3.2.3 [Special Channels](protocol-specs-section/epns-protocol/channels/special-channels.md) 34 | 35 | 3.2.4 [Channel Activation and Deactivation](protocol-specs-section/epns-protocol/channels/channel-activation-deactivation.md) 36 | 37 | 3.2.5 [Deriving fair share of token incentives for a channel from stake pool](protocol-specs-section/epns-protocol/channels/deriving-fair-share-of-token-incentives-for-a-channel-from-stake-pool.md) 38 | 39 | 3.2.6 [Updating Channel](protocol-specs-section/epns-protocol/channels/updating-channel.md) 40 | 41 | 3.2.7 [Spam score and throttling](protocol-specs-section/epns-protocol/channels/spam-rating-and-throttling.md) 42 | 43 | 3.3 [Subscribers](protocol-specs-section/epns-protocol/subscribers/) 44 | 45 | 3.3.1 [Subscribing to Channel](protocol-specs-section/epns-protocol/subscribers/subscribing-to-channel.md) 46 | 47 | 3.3.2 [User direct action subscribe](protocol-specs-section/epns-protocol/subscribers/user-direct-action-subscribe.md) 48 | 49 | 3.3.3 [Deriving weighted earnings of a subscriber of a channel](protocol-specs-section/epns-protocol/subscribers/deriving-weighted-earnings-of-a-subscriber-of-a-channel.md) 50 | 51 | 3.3.4 [Indirect subscribe action \(delegate subscription of user by channel\)](protocol-specs-section/epns-protocol/subscribers/indirect-subscribe-action-delegate-subscription-of-user-by-channel.md) 52 | 53 | 3.3.5 [Unsubscribing from Channel](protocol-specs-section/epns-protocol/subscribers/unsubscribing-from-channel.md) 54 | 55 | 3.4 [Sending Notification](protocol-specs-section/epns-protocol/sending-notifications/) 56 | 57 | 3.4.1 [Protocol Interfacing and Notifications](protocol-specs-section/epns-protocol/sending-notifications/notifications-abi.md) 58 | 59 | 3.4.2 [Delegation of Notifications](protocol-specs-section/epns-protocol/sending-notifications/delegation-of-notifications.md) 60 | 61 | 3.5 [Claiming Earnings from Protocol](protocol-specs-section/epns-protocol/claiming-earnings-from-protocol.md) 62 | 63 | 4 [EPNS Products](protocol-specs-section/the-epns-product.md) 64 | 65 | 5 [Integration Flow for dApp / Server / Smart Contract](protocol-specs-section/protocol-integration-flow/) 66 | 67 | 5.1 [Creating Channel on dApp / Server / Smart Contract](protocol-specs-section/protocol-integration-flow/creating-channel-on-protocol.md) 68 | 69 | 5.2 [Sending Notification from dApp / Serveless](protocol-specs-section/protocol-integration-flow/sending-notification-dapp.md) 70 | 71 | 5.3 [Sending Notification from Server](protocol-specs-section/protocol-integration-flow/sending-notification-from-smart-contract.md) 72 | 73 | 5.4 [Sending Notification from Smart Contract](protocol-specs-section/protocol-integration-flow/sending-notification-from-server.md) 74 | 75 | 6 [Future Features & Research](protocol-specs-section/future-features-research.md) 76 | 77 | 7 [Governance](governance-section/governance/) 78 | 79 | 8 [Risks](risks/risks.md) 80 | 81 | 9 [Summary](summary-section/summary.md) 82 | 83 | 10 [Milestones]() 84 | 85 | 11 [Founders](team-and-acheivements-section/founders.md) 86 | 87 | 12 [Achievements](team-and-acheivements-section/achievements.md) 88 | 89 | 13 [References](references-section/references.md) 90 | 91 | 92 | 93 | -------------------------------------------------------------------------------- /introduction-section/introduction/README.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | The blockchain space is growing at an extremely rapid pace and the exponential growth is projected to continue rapidly in terms of users, services and revenue [\[1\]](../../references-section/references.md). Despite this growth and expanding usage of blockchain tech, the services \(dApps, services, smart contracts\) still lack a genuine and organic communication medium with their users which is sometimes filled by alternative communication mediums like twitter, telegram or email defeating the purpose of web 3.0. 4 | 5 | More often though, dApps, smart contracts or services assume that users will come to them. This method is very similar to the early 2003 era of the internet where users were expected to perform an action, come back later and check the results of those actions \(Gmail, Orkut, etc\). 6 | 7 | While this was okay with early internet days and web 2.0, it is not the case with traditional services now. In fact, no web 2.0 service really expects the user to come to them now, instead, they reach out to their users informing them about certain important events or any further actions required from users end. Modern push notification played a crucial role in this transition and has become a backbone for all web 2.0 services now [\[2\]](../../references-section/references.md). 8 | 9 | However, for web 3.0, there still **doesn't exist a** **notification mechanism** that can notify users\(wallet addresses\) of important updates, events, actions, etc. This flawed mechanism has already led to pain points and side effects: 10 | 11 | * Important events or user action requirements are missed completely \(trading completed on dEx, liquidation alert on DeFi protocols, etc\). 12 | * Blockchain domains expiry have to be put on twitter in the hopes that the grace domain user might read it. 13 | * A protocol getting compromised means sending information through Twitter and Telegram hoping the users of that protocol become aware of the vulnerabilities. 14 | 15 | This is a major issue in adoption and the problem will worsen more as the services keep on growing on blockchain. 16 | 17 | This paper describes the solution to these problems and aims to provide the missing piece of web 3.0 infrastructure with the introduction of the decentralized notification protocol. The protocol will enable users to receive notifications, be in complete control of the notifications they receive as well as enabling users to receive and accumulate token incentives from those notifications. 18 | 19 | -------------------------------------------------------------------------------- /introduction-section/introduction/basic-definitions.md: -------------------------------------------------------------------------------- 1 | # Basic Definitions 2 | 3 | The following definitions are used in the rest of the whitepaper to refer to certain roles. 4 | 5 | ## EPNS Related 6 | 7 | | **Role** | Description | 8 | | :--- | :--- | 9 | | Service | Any dApp / smart contract / centralized service / etc who wishes to send notifications. | 10 | | Channel | Any service that has activated themselves on the protocol and thus can send notifications to their subscribers. | 11 | | Subscriber | The user who have subscribed to a particular channel. | 12 | | Users | Any user who is present in protocol registry. | 13 | | Stake Pool | The pool of staked fee charged when a **service** activates themselves as a **channel.** | 14 | | Token Incentives Pool | The token incentives generated by the stake pool meant for distribution among subscribers of a channel in a weighted ratio favoring early subscribers. | 15 | | Fee Pool | The fee earned by the protocol during certain actions, i.e. micro fees when sending notification, part of the penalty, etc. | 16 | | Incentive Reserve | The user token incentives that haven't been moved to the user wallet and still present and mapped to the user in the protocol. | 17 | | Ecosystem Development Pool \(EDP\) | Portion of the Fee Pool used to incentivize user wallets / infrastructure services that integrate EPNS protocol | 18 | | Integration Upfront Reward Pool \(IURP\) | Portion of the Fee Pool allocated as instant bounty for integrating EPNS protocol | 19 | 20 | ## Other Concepts 21 | 22 | | **Role** | Description | 23 | | :--- | :--- | 24 | | IPFS | The InterPlanetary File System \(**IPFS**\) is a protocol and peer-to-peer network for storing and sharing data in a distributed file system. [\[3\]](../../references-section/references.md) | 25 | | JSON payload | JavaScript Object Notation is used across the ecosystem for storage of data meant for consumption at frontend. | 26 | 27 | {% hint style="info" %} 28 | Unless explicitly mentioned, within the context of this whitepaper, the terms **contract owners, services, channels** or **users** always means **wallet addresses** that are anonymous. 29 | {% endhint %} 30 | 31 | -------------------------------------------------------------------------------- /introduction-section/introduction/high-level-application-flow-diagram.md: -------------------------------------------------------------------------------- 1 | # Protocol / Product Flow 2 | 3 | EPNS uses the following flow to ensure storage, broadcasting and sending notifications in a platform agnostic and decentralized way. 4 | 5 | ![High level flow](../../.gitbook/assets/highleveldefi%20%281%29.jpg) 6 | 7 | Notification is stored and treated like JSON payload which is transformed as per the rules of the different carriers when the notification reaches them. JSON Payload can differ with payload types which ensures the flexibility of the content, data, storage interpretation and delivery. This helps in creating different rules and content interpretation of the notification \(for example: carrying images, call to action, live videos, etc\). 8 | 9 | **The protocol allows users to be in direct control of what services they get notifications from; it imposes rules on the services including spam protection for users, limiting their ability to add wallets as subscribers, etc.** 10 | 11 | **The protocol incentivizes users who receive notifications.** 12 | 13 | **This on-chain abstraction of data enables delivery of information to centralized as well decentralized carriers, notifications are treated more like a social feed \(e.g. Twitter\) than an ephemeral piece of information \(though means to do so also exists\).** 14 | 15 | It also enables rules, incentives, settings and configuration to be retrieved from a single source of truth and is not dependent on a single point of failure. 16 | 17 | Storing the JSON payload on decentralized storage and just its pointer / hash on on-chain logs enables cost optimization. Though the protocol also allows storing the entire payload on-chain for services that intend to do so. 18 | 19 | This can be further optimized by moving parts of these mechanisms to the layer-2 \(L2\). 20 | 21 | {% hint style="info" %} 22 | Abstracting the data layer on-chain \(directly or indirectly\) ensures notifications are platform agnostic and available on decentralized mediums as well \(e.g. dApp, wallets that might not want to trust a central point of truth\). 23 | {% endhint %} 24 | -------------------------------------------------------------------------------- /pdf-version/EthereumPushNotificationServiceWhitepaperDraft.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pushchain/push-protocol-whitepaper/e4ea0a38a5a8ab18e8368a5ca09c669b64d926ca/pdf-version/EthereumPushNotificationServiceWhitepaperDraft.pdf -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/README.md: -------------------------------------------------------------------------------- 1 | # EPNS Protocol 2 | 3 | ## Introduction 4 | 5 | Ethereum Push Notification Service protocol will be on the Ethereum blockchain that provides and standardises the ways by which notification on blockchain can operate. 6 | 7 | {% hint style="info" %} 8 | In the future, the protocol can also support other blockchain by exploring bridging or migrating the contract and service to a particular blockchain. 9 | {% endhint %} 10 | 11 | ## Primary Use Cases & Features 12 | 13 | * Users 14 | * Users registry 15 | * Public key registry 16 | * Channels 17 | * Types of Channels 18 | * Channels registry 19 | * Special channels 20 | * Channel Activation & Deactivation 21 | * Game Theory and User Incentives 22 | * Deriving fair share of token incentives for a channel from stake pool 23 | * Updating Channel 24 | * Spam rating and throttling 25 | * Subscribers 26 | * Subscribing to Channels 27 | * User direct action subscribe 28 | * Game Theory and User Incentives 29 | * Deriving weighted token incentives accruing to a subscriber of a channel 30 | * Indirect subscribe action \(delegate subscription of user by channel\) 31 | * Game Theory and User Incentive 32 | * Unsubscribing from Channel 33 | * Sending Notifications 34 | * Protocol interfacing for Notifications 35 | * Delegation of notifications 36 | * Claiming Token incentives from Protocol 37 | 38 | {% hint style="warning" %} 39 | The primary use cases might change or tweaked in the future as more protocol features are built. 40 | {% endhint %} 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/channels/README.md: -------------------------------------------------------------------------------- 1 | # Channels 2 | 3 | Any user who activates themselves on the protocol to send notification is called a **Channel**. Channel stakes fees in a stake pool, and the token incentives accumulated would be distributed among their subscribers in a weighted proportion. 4 | 5 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/channels/channel-activation-deactivation.md: -------------------------------------------------------------------------------- 1 | # Channel Activation & Deactivation 2 | 3 | ## Concept 4 | 5 | A **service** needs to activate itself on the protocol as a one time step before they can send notifications to their subscribers. When a service is activated on the protocol, they are referred to as a **Channel**. 6 | 7 | The channel is also required to stake fees in DAI which is **50 DAI or higher**, this is used to create a staking pool which in turn interacts with other DeFi protocols to receive token incentives. These token incentives are then distributed to all the **subscribers** of that service in a weighted manner preferring the earliest subscriber more than the later ones. 8 | 9 | {% hint style="info" %} 10 | There is always 1:1 mapping between a service \(wallet\) and the channel it creates. 11 | {% endhint %} 12 | 13 | ## Game Theory and User Incentives 14 | 15 | In order to ensure the proper participation of all ecosystem users, following game theory is applied to keep each user in the system motivated to be a good actor in the ecosystem. 16 | 17 | * Contract owner cannot send notification on behalf of channel unless the control is delegated to it by the channel owner as an on-chain event. 18 | * The **service** needs to deposit **50 DAI or higher** as staking fee to activate themselves, this ensures that serious users participate in the channel creation. 19 | * The **channel stake** goes to a combined stake pool of channels and starts accumulating token incentives using [**AAVE Protocol**](https://aave.com/) ****\(at the time of writing, this can be replaced with a similar DeFi protocol in the future\). 20 | * The **channel owner** will be able to decide on the level of channel stake it is willing to put up, since eventually all token incentives attributable to this channel stake will be distributed among their users weighted towards the earliest subscriber, and is refundable, having **higher stake incentivizes more users** to subscribe to the channel. 21 | * This **channel** can be deactivated by the **channel owner** with a penalty of **20 DAI**, this ensures that bad actors are unable to abuse the system as a monetary loss will occur with each recurrence, small enough for serious users to not worry about it but act as a further deterrent for malicious users. 22 | * Upon deactivation, the channel is unable to send notification and its ratio in the **stake pool** is reduced to **10 DAI**, as a result, the proportionate ratio from token incentives pool for the channel is also reduced accordingly. The channel continues distributing its fair share of token incentives to all existing subscribers of the channel, though the channel loses the ability to add more users. 23 | * The rest of the penalty \(**10 DAI**\) goes into the Fee Pool. 24 | 25 | {% hint style="info" %} 26 | There is an upper ceiling limit applied for staking fee to ensure that a service is not approving an unlimited amount of fees to transfer \(250k DAI at the time of writing\). This is mostly to avoid the mentioned problem and should not really be effecting any features or UX of the protocol. 27 | {% endhint %} 28 | 29 | {% hint style="info" %} 30 | The penalty fee, stake fee can be adjusted in the future before going to the mainnet. After mainnet, it can only be adjusted by voting mechanism of the protocol. 31 | {% endhint %} 32 | 33 | 34 | 35 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/channels/channels-registry.md: -------------------------------------------------------------------------------- 1 | # Channels Registry 2 | 3 | ## Concept 4 | 5 | The channels registry is maintained in the protocol to carry out various tasks such as carrying weights and indexes for deriving the fair share of token incentives from the common stake pool, mapping the number of subscribers, adjusting the spam rating, etc. 6 | 7 | ## Key data stored on chain 8 | 9 | * Type of channel 10 | * Channel status 11 | * Stake pool contribution 12 | * Time at which the channel was created \(block number\) 13 | * Mapping of its subscribers 14 | * Mapping of key data points of subscribers for calculating their fair share from the derived token incentives of the channel 15 | 16 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/channels/deriving-fair-share-of-interest-for-a-channel-from-stake-pool.md: -------------------------------------------------------------------------------- 1 | # Deriving fair share of interest for a channel from stake pool 2 | 3 | ## Concept 4 | 5 | The stake pool is a pool that contains all the staking fees from all the channels. There are two important concepts to keep in mind to derive the fair share of interest for an individual channel. 6 | 7 | * The staking fee starts earning interest as soon as a channel is activated, this means that the fair share of a channel would need to account for the time since the channel is activated to ensure fair play. This is achieved by recording the **block number** at which a channel is activated. 8 | * The staking fee is dynamic and can differ from one channel to another, i.e. channel decides the amount based on their game theory and incentive plan they put in place. To account for this, the **weight** of the channel and **aggregated weight of all channels** are recorded at the time a new channel creation. 9 | 10 | ## Problem Statement 11 | 12 | We need to derive the formula which gives us the ratio of the interest the channel has generated so that it can be distributed among the subscribers. 13 | 14 | While this can be solved by recursion of all channels, getting their share in the pool, deriving their weight and the start block number. This will be inefficient as more channels continue to get activated on the protocol. 15 | 16 | ### Solution 17 | 18 | Instead of recursion, we are going to approach the formula in a linear way. We know that each time a channel is added, the previous number of channels, their block number, etc can be treated like a constant as their values will not change moving forward. 19 | 20 | For example, if **channel** **x** got added at **block y**, then the channels count before **block y** would never change, nor will the differential which we have before **channel** **x** was added. We utilize this to form our own ratio calculation that is not based on recursion but instead is based on the aggregation that happens whenever a channel is added or removed. The different weights of the channel are also mapped to an aggregated weight variable which helps us in determining the total sum needed to derive the fair share of interest for the channel. 21 | 22 | Putting it together, the formula by which we can derive a channels' fair share of interest from the stake pool for current block can be written as: 23 | 24 | ### Formula to calculate fair share interest ratio 25 | 26 | $$ 27 | ratio = (d * a) / (z + n * x *w) 28 | $$ 29 | 30 | ### Formula to calculate historical constant \(z\) 31 | 32 | Occurs whenever a channel is added, deactivated or the stake fees changes 33 | 34 | $$ 35 | z = z + (n * x * w) 36 | $$ 37 | 38 | | Parameter | Explanation | 39 | | :--- | :--- | 40 | | d | Differential of current block number and the block number on which the channel was last modified in relation to stake fee. | 41 | | a | The actual weight of the channel, measured by dividing the stake fee of the channel with the minimum stake fee. | 42 | | z | The historical constant of the **channels**, calculated whenever a modification in number of channels occurs or whenever the stakes fee of the channel is changed. | 43 | | n | The previous count of the number of channels present in the protocol. | 44 | | x | Differential between the latest block number and the last modified block number. Last modified block number is whenever a channel was added, deactivated or fees of any channel was changed. | 45 | | w | The averaged out weight of all the channels, the average is normalized / averaged out whenever a new channel is added, deactivated or fess of any channel is changed. | 46 | 47 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/channels/deriving-fair-share-of-token-incentives-for-a-channel-from-stake-pool.md: -------------------------------------------------------------------------------- 1 | # Deriving fair share of token incentives for a channel from stake pool 2 | 3 | ## Concept 4 | 5 | The stake pool is a pool that contains all the staking fees from all the channels. There are two important concepts to keep in mind to derive the fair share of token incentives for an individual channel. 6 | 7 | * The staking fee starts accumulating token incentives as soon as a channel is activated, this means that the fair share of a channel would need to account for the time since the channel is activated to ensure fair play. This is achieved by recording the **block number** at which a channel is activated. 8 | * The staking fee is dynamic and can differ from one channel to another, i.e. channel decides the amount based on their game theory and incentive plan they put in place. To account for this, the **weight** of the channel and **aggregated weight of all channels** are recorded at the time a new channel creation. 9 | 10 | ## Problem Statement 11 | 12 | We need to derive the formula which gives us the ratio of the token incentives the channel has generated so that it can be distributed among the subscribers fairly proportionate to their joining of the channel and the number of subscribers joined earlier. 13 | 14 | While this can be solved by recursion of all channels, getting their share in the pool, deriving their weight and the start block number. This will be inefficient as more channels continue to get activated on the protocol. 15 | 16 | ### Solution 17 | 18 | Instead of recursion, we are going to approach the formula in a linear way. We know that each time a channel is added, the previous number of channels, their block number, etc can be treated like a constant as their values will not change moving forward. 19 | 20 | For example, if **channel** **x** got added at **block y**, then the channels count before **block y** would never change, nor will the differential which we have before **channel** **x** was added. We utilize this to form our own ratio calculation that is not based on recursion but instead is based on the aggregation that happens whenever a channel is added or removed. The different weights of the channel are also mapped to an aggregated weight variable which helps us in determining the total sum needed to derive the fair share of token incentives for the channel. 21 | 22 | Putting it together, the formula by which we can derive a channels' fair share of token incentives from the stake pool for current block can be written as: 23 | 24 | ### Formula to calculate fair share token incentives ratio 25 | 26 | $$ 27 | ratio = (d * a) / (z + n * x *w) 28 | $$ 29 | 30 | ### Formula to calculate historical constant \(z\) 31 | 32 | Occurs whenever a channel is added, deactivated or the stake fees changes 33 | 34 | $$ 35 | z = z + (n * x * w) 36 | $$ 37 | 38 | | Parameter | Explanation | 39 | | :--- | :--- | 40 | | d | Differential of current block number and the block number on which the channel was last modified in relation to stake fee. | 41 | | a | The actual weight of the channel, measured by dividing the stake fee of the channel with the minimum stake fee. | 42 | | z | The historical constant of the **channels**, calculated whenever a modification in number of channels occurs or whenever the stakes fee of the channel is changed. | 43 | | n | The previous count of the number of channels present in the protocol. | 44 | | x | Differential between the latest block number and the last modified block number. Last modified block number is whenever a channel was added, deactivated or fees of any channel was changed. | 45 | | w | The averaged out weight of all the channels, the average is normalized / averaged out whenever a new channel is added, deactivated or fess of any channel is changed. | 46 | 47 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/channels/spam-rating-and-throttling.md: -------------------------------------------------------------------------------- 1 | # Spam score and throttling 2 | 3 | The protocol uses game theory and incentives to ensure that the channel stay useful to the users. However, there might come a point where a channel might become a bad actor despite the incentives and penalty imposed. This can happen in various scenarios, a couple of them can be: 4 | 5 | * Popular channel is bought by someone else with the purpose to promote advertisements. 6 | * Channel private key is compromised. 7 | 8 | These edge cases are handled by the protocol by introducing the concept of spam rating and throttling of sending notification, this is done in the following way: 9 | 10 | * The channel always starts with a spam score of neutral position \(0.5\), this rating can go towards 0 \(positive position, good actor\) or 1 \(negative position, bad actor\). 11 | * The score is adjusted to move towards positive position \(0\) whenever a new user is added, this is weighted by the total number of users in the ecosystem as well. 12 | * The score is adjusted to move towards negative position \(1\) whenever a user unsubscribes and indicates spam, this rating is weighted against the total number of subscribers of the channel. 13 | * The score slowly inches towards positive position \(0\) as block number increases \(i.e. time increases\) but takes the spam score into account in relation to how quick the spam score will decrease, i.e. the higher the spam rating, the more minute adjustment is done towards the positive position. 14 | * As the spam score start reaches or exceeds **0.8**, the number of notifications starts getting limited for a channel as a quadratic function. 15 | 16 | {% hint style="warning" %} 17 | The feature is expected to change heavily as it's still in development. 18 | {% endhint %} 19 | 20 | {% hint style="info" %} 21 | The spam score throttle can be adjusted in the future before going to the mainnet. After mainnet, it can only be adjusted by voting mechanism of the protocol. 22 | {% endhint %} 23 | 24 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/channels/special-channels.md: -------------------------------------------------------------------------------- 1 | # Special Channels 2 | 3 | There are two special channels in the protocol that are owned and controlled by the contract owner. These channels are special because: 4 | 5 | * They don't give any token incentives to their subscribers. 6 | * They are the only automated opt-in channels in the protocol that doesn't pay subscribers \(yet add them without their direct consent\). 7 | 8 | ## EPNS Channel 9 | 10 | This channel is an auto subscribe channel for all the users of the protocol. The purpose of the channel is to send out extremely important events or alerts to the subscribers. While an auto subscribe, the channel can be unsubscribed by the user and like all the other channels will lose permission to add that user again indirectly. 11 | 12 | ## EPNS Alerter Channel 13 | 14 | The channel is an auto subscribe channel for all the other channels of the protocol. The purpose of this channel is to send out updates, alerts to other channels of the protocol. While an auto subscribe, the channel can be unsubscribed by the user and like all the other channels will lose permission to add that user again indirectly. 15 | 16 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/channels/types-of-channels.md: -------------------------------------------------------------------------------- 1 | # Types of Channels 2 | 3 | The protocol allows a service to choose what type of channel ****they want to create. This enables several other business use cases than just delivering information via notification. 4 | 5 | * Open Channel 6 | * Closed Channel 7 | * Mutual Channel 8 | 9 | ## Open Channel 10 | 11 | The default channel, this channel is created by the service and is intended to be open for any user to come and subscribe without any restrictions. Channel can also indirectly subscribe the user to it by paying the user a minor fee. 12 | 13 | ## **Closed Channel** 14 | 15 | A service can opt to create a closed channel, this channel cannot be directly subscribed by the user. Instead, the channel needs to add the user indirectly by paying a minor fee to the user. 16 | 17 | ## Mutual Channel 18 | 19 | A service can opt to create a mutual channel, which requires user direct action to subscribe to it, but the subscription is only confirmed once the channel approves it as well. 20 | 21 | {% hint style="info" %} 22 | This is not a definitive list, we might add more types of channels as per the need in the future. 23 | {% endhint %} 24 | 25 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/channels/updating-channel.md: -------------------------------------------------------------------------------- 1 | # Updating Channel 2 | 3 | A channel can be updated as long as the number of subscribers to that channel is equal to one, which means that the channel owner is the only subscriber of the channel. 4 | 5 | The channel becomes immutable as soon as a new subscriber joins the channel, to avoid, constant changes on the channel \(even with a single subscriber\). A fee of **10 DAI** is charged that goes to the **Fee Pool**. 6 | 7 | {% hint style="info" %} 8 | The penalty fee can be adjusted in the future before going to the mainnet. After mainnet, it can only be adjusted by the voting mechanism of the protocol. 9 | {% endhint %} 10 | 11 | 12 | 13 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/claiming-earnings-from-protocol.md: -------------------------------------------------------------------------------- 1 | # Claiming Token incentives from Protocol 2 | 3 | ## Claiming Token incentives 4 | 5 | The protocol provides ways for users to receive token incentives based on some of their direct or indirect actions. These include incentives resulting from: 6 | 7 | * Subscribing to channels by their direct action \(receive token incentives\). 8 | * Indirect subscribe by a channel \(channel pays user either the default minor reward or the reward expectation set by the user\). 9 | 10 | These token incentives are mapped to the user in the protocol and the user is free to claim these anytime they want to. The token incentives are generated and kept as [aDai \(AAVE Interest bearing DAI\)](https://aave.com/aTokens) for users to keep generating token incentives automatically for them. They are converted to protocol tokens when the user withdraws them. 11 | 12 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/sending-notifications/README.md: -------------------------------------------------------------------------------- 1 | # Sending Notifications 2 | 3 | ## Concept 4 | 5 | EPNS is a decentralized notification protocol that abstracts the data layer to enable sending notifications to both decentralized and centralized carriers. 6 | 7 | * Sending notifications carries a micro fee, charged in **$ETH** \(or **$DAI**\), the fee is controlled by the governance model. 8 | * We do know that notification needs to be carried from decentralized to centralized carriers and finally to a centralized platform which requires infrastructure and a business model to maintain it and leave the business model to the infra service building on top of the protocol. 9 | * We are running our own infrastructure ensure early adoption and to carry notifications to centralized carriers \(iOS, Android, Chrome, Firefox with more to come in the future\), more about this and the range of product suite is explained in [EPNS Products](../../the-epns-product.md) section. 10 | 11 | The protocol charges micro fees on notifications that are sent out. The fees from this goes to the fee pool of the protocol. 12 | 13 | {% hint style="warning" %} 14 | The fee pool is divided into certain ratios which are then shared accordingly as per the governance game theory and voting, so as to incentivize protocol participation. 15 | {% endhint %} 16 | 17 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/sending-notifications/delegation-of-notifications.md: -------------------------------------------------------------------------------- 1 | # Delegation of Notifications 2 | 3 | ## Concept 4 | 5 | The channel can also opt to delegate sending notification from another wallet address or multiple wallet addresses in the protocol. If the delegation is present, that wallet can send notification on the protocol on behalf of that channel. The delegation can be revoked at any point of time by the channel owner. 6 | 7 | This is useful in providing value added services to the channels and having mechanisms that can be used by EPNS infrastructure or other third party infrastructure to send notifications on-chain on a channels' behalf. 8 | 9 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/sending-notifications/notifications-abi.md: -------------------------------------------------------------------------------- 1 | # Protocol Interfacing for Notifications 2 | 3 | ## Concept 4 | 5 | All of the payloads are uploaded as JSON format in decentralized storage solutions \(**or in some special future cases, even centralized ones**\). The EPNS JS Library interfaces with Ethereum Push Notification Service protocol and calls: 6 | 7 | ```text 8 | sendNotification(address _recipient, bytes _identity) 9 | ``` 10 | 11 | | Parameter | Sub Field | Description | 12 | | :--- | :--- | :--- | 13 | | **\_recipient** | | Differs with the payload type, broadcast and special multi payload notifications have the channel address as the recipient address. | 14 | | **\_identity** | | The identity field consists of the following parameters joined together with a delimiter. | 15 | | | payloadtype | Payload type not only indicates the content of notification but also the storage implementation stored. | 16 | | | payloadhash | Indicates the hash of the payload through which payload data can be obtained. | 17 | 18 | {% hint style="info" %} 19 | The delimiter **+** is used for joining the fields together, this is done to optimize the payload written on chain. 20 | {% endhint %} 21 | 22 | {% hint style="success" %} 23 | Example \_identity: 2+QmcdzjicUnxv8ASKKSgEEYjhK7symwxqDG4BeCS82rdNBk 24 | {% endhint %} 25 | 26 | {% hint style="info" %} 27 | Always recommended to interface with **EPNS JS Library** for abstracting these details out. 28 | {% endhint %} 29 | 30 | {% hint style="warning" %} 31 | This feature of protocol will keep evolving for further optimizations in the future. 32 | {% endhint %} 33 | 34 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/subscribers/README.md: -------------------------------------------------------------------------------- 1 | # Subscribers 2 | 3 | Subscriber is any user that subscribes to one or more channel. A channel can also be a subscriber of other channels. Furthermore, a channel cannot send a notification to a user who is not a subscriber of their channel to ensure user is in complete control of what channels can or cannot send them notification. 4 | 5 | Though means to delegate subscribe by the channel is given with greater incentives for the user \(subscriber\) to ensure win-win scenario [\[6\]](../../../references-section/references.md) and to cover the need of the channel as well. 6 | 7 | {% hint style="info" %} 8 | The channel owner will always be the first subscriber of the channel as soon as the channel is activated, it's not possible to remove the channel owner \(subscriber\) from their own channel. 9 | {% endhint %} 10 | 11 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/subscribers/deriving-weighted-earnings-of-a-subscriber-of-a-channel.md: -------------------------------------------------------------------------------- 1 | # Deriving weighted accumulated token incentives of a subscriber of a channel 2 | 3 | ## Concept 4 | 5 | The token incentives pool is a pool that contains all the interest generated by the stake pool \(of channels\). There are two important things to keep in mind to derive the weighted accumulated token incentives of a subscriber of a channel: 6 | 7 | * The token incentives pool contains all the tokens generated by all the channels which means we need to first find the ratio of the token incentives to be attributed to a specific channel. We have covered how to do this in [deriving fair share of token incentives for a channel from stake pool](../channels/deriving-fair-share-of-token-incentives-for-a-channel-from-stake-pool.md). 8 | * Next, we need to calculate the weighted token incentives accrued to a particular subscriber of the channel, this is necessary since subscribers who joined earlier would be receiving more notifications and thus in exchange be entitled to higher share in the token incentives attribute to the channel than the subscribers who joined later. 9 | 10 | ## Problem Statement 11 | 12 | We need to derive the formula which can give us the exact accumulated token incentives of the subscriber of a specific channel. The subscriber share of token incentives ratio needs to be weighted favoring earlier subscription. 13 | 14 | While this can be solved by recursion of all subscribers, getting their join time \(block number\) and applying a simple ratio formula. This will be inefficient as more subscribers will lead to higher inefficiencies. 15 | 16 | ### Solution 17 | 18 | Instead of recursion, we are going to approach the formula in a linear way. We know that each time a subscriber is added, the previous number of subscribers, their block number, etc can be treated like a constant as their values will not change moving forward. 19 | 20 | For example, if **subscriber** **k** is added to **block b**, then the subscriber count before **block b** would never change, nor will the differential which we have before **subscriber** **k** was added. We utilize this to form our own ratio calculation that is not based on recursion but instead is based on the aggregation that happens whenever a subscriber is added or removed. 21 | 22 | Putting it together, the formula by which we can derive a channels' fair share of token incentives from the stake pool for the current block can be written as: 23 | 24 | ### Formula to calculate weighted subscriber ratio 25 | 26 | $$ 27 | ratio = d / (z + n * x ) 28 | $$ 29 | 30 | ### Formula to calculate historical constant \(z\) 31 | 32 | Occurs whenever a subscriber is added, deactivated or the stake fees changes 33 | 34 | $$ 35 | z = z + (n * x ) 36 | $$ 37 | 38 | | Parameter | Explanation | 39 | | :--- | :--- | 40 | | d | Differential of current block number and the block number on which the subscriber was last removed or added. | 41 | | z | The historical constant of the **channels**, calculated whenever a modification in number of subscribers occurs. | 42 | | n | The previous count of the number of subscriber present in the channel. | 43 | | x | Differential between the current block number and the last modified block number, last modified block number is whenever a subscriber was added or removed. | 44 | 45 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/subscribers/indirect-subscribe-action-delegate-subscription-of-user-by-channel.md: -------------------------------------------------------------------------------- 1 | # Indirect subscribe action \(delegate subscription of user by channel\) 2 | 3 | ## Concept 4 | 5 | The indirect subscribe action provides channels a way to subscribe users and thus send notification to them without the explicit permission of the user. While this action is obtrusive in nature and opens up the protocol for misuse, we do however also see it's use cases: 6 | 7 | * When channel doesn't have any means to reach the user 8 | * When user is not added in the protocol or the channel but notification is important \(example: ENS domain expiry or security compromise\) 9 | * For closed channels and their business use case \(For example, notification that do multi-factor authentication should not be open for any action of the user\) 10 | 11 | Seeing this as a necessity, we do have provisions in the protocol to initiate subscribe from a channel to a user. Since, this action has larger consequences on the user if misused, we have set the following rules and higher incentives for indirect subscribe action. 12 | 13 | ## Game Theory and User Incentives 14 | 15 | The indirect subscribe action imposes the following rules and conditions on the channel: 16 | 17 | * The indirect subscribe can only occur once, if the user unsubscribes, there is no way to add them back. 18 | * The user can set and change at will their fee that a channel should to pay to them for indirect subscribe. 19 | * The channel needs to pay the user the above specified amount and only then can the indirect subscribe occur, this directly goes to the users Incentive Reserve. 20 | * If the user hasn't set an indirect fee amount, then a default amount **0.1 DAI** still needs to be paid before an indirect subscribe can occur. 21 | * A minor fees \(0.2% at the time of writing\) is also charged which is sent to the Fee Pool. 22 | 23 | {% hint style="info" %} 24 | The indirect fees can be adjusted in the future before going to the mainnet. After mainnet, it can only be adjusted by voting mechanism of the protocol. 25 | {% endhint %} 26 | 27 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/subscribers/subscribing-to-channel.md: -------------------------------------------------------------------------------- 1 | # Subscribing to Channel 2 | 3 | ## Concept 4 | 5 | The service benefits from establishing a genuine communication channel with the user and the user benefits from receiving the notifications which would contain information useful to them, which is a great incentive in itself. 6 | 7 | However, the decentralized web has also introduced some limitations of its own which are needed to be counteracted with incentives of decentralization to ensure seamless adaption and more benefits than traditional services. The common inconvenience with protocols in general and with EPNS in particular when a user needs to do a subscription action can be summarized as follows: 8 | 9 | * The users need to transact on blockchain to specifically subscribe or unsubscribe to a channel or multiple channels, this leads to an incentive issue, i.e. **why would a user spend gas in most cases?** 10 | * The users can be added by the channel in delegated fashion \(though only once\), this feature while required at times to ensure backward compatibility and handling of different use cases also leads to the issue of adding users without their consent. **What can we do to ease the pain points?** 11 | 12 | To address these issues, we built means for the user to receive token incentives along with receiving notifications. The earning is designed to be relativity more rewarding for indirect action done on behalf of the user \(channel subscribing them\). The subscription section focuses a lot on the win-win aspect of Game Theory [\[6\]](../../../references-section/references.md) and how the protocol ties to ease the pain points of the user by balancing them with incentives. 13 | 14 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/subscribers/unsubscribing-from-channel.md: -------------------------------------------------------------------------------- 1 | # Unsubscribing from Channel 2 | 3 | ## Concept 4 | 5 | The channel has no control on the unsubscribing action of its' subscriber. Though the subscriber can indicate whether they are unsubscribing because: 6 | 7 | * They don't want to receive notification from the channel anymore, in which case, the channel spam score is unaffected. 8 | * However, if the subscriber indicates that they unsubscribed due to spam then the spam score of the channel is affected as outlined in [channel's spam score and throttling](../channels/spam-rating-and-throttling.md). 9 | 10 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/subscribers/user-direct-action-subscribe.md: -------------------------------------------------------------------------------- 1 | # User direct action subscribe 2 | 3 | ## Concept 4 | 5 | The user can opt to directly subscribe to a channel via an on-chain event, this enables the service to send notifications to the users, channel benefits from engagement with their subscriber while the subscriber benefits from receiving useful information through the notification and receive token incentives from them as well. 6 | 7 | ## Game Theory and User Incentives 8 | 9 | In order to ensure that the user is incentivized to do an on-chain transaction \(however negligible\), we have applied the following game theory: 10 | 11 | * The token incentives, which gets [generated by the stake pool of the channels](../channels/channel-activation-deactivation.md) is distributed to the subscribers of the channel in a weighted manner. 12 | * This means that the earliest subscriber receives a higher share of the token incentives received by the channel than the subscriber coming later than them. 13 | * The user continues to accumulate token incentives from the channels they are subscribed to until they unsubscribe, in which case, the part of the token incentives that they have accumulated from that channel is automatically sent to their Incentive Reserve on the protocol. 14 | * The user can also withdraw all token incentives whenever they want without unsubscribing from any channel. 15 | 16 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/users/README.md: -------------------------------------------------------------------------------- 1 | # Users 2 | 3 | Any entity \(wallets\) involved in protocol \(contract owner, channels or normal users\) is referred to as **Users** of the protocol. User can become a channel by activating themselves as a channel, or can become subscriber to one or more channel and start receiving token incentives. 4 | 5 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/users/public-key-registry.md: -------------------------------------------------------------------------------- 1 | # Public Key Registry 2 | 3 | ## Concept 4 | 5 | Encrypted notification generally uses an algorithm based on public key or its derivative thereof. To facilitate this, the EPNS protocol maintains a public key registry of all the users who enter the ecosystem. This is done by having mirrored function with public key registry for **creating a channel** and **subscribe** which allows the protocol to emit public key of the wallet out \(or skip if it already exists\). 6 | 7 | {% hint style="info" %} 8 | Since public key for any wallet is derivable if they have done even a single transaction, we consider this information as safe non-invasive to privacy. 9 | {% endhint %} 10 | 11 | The public key registry for users is completely optional and the protocol has alternative methods that completely skip this process but carry the required functionality. The registry is helpful on the frontend side to quickly poll and find the key of the wallet and use it to encrypt the notifications wherever necessary. 12 | 13 | 14 | 15 | -------------------------------------------------------------------------------- /protocol-specs-section/epns-protocol/users/users-registry.md: -------------------------------------------------------------------------------- 1 | # Users Registry 2 | 3 | ## Concept 4 | 5 | The users registry is maintained in the protocol to carry out various tasks such as stopping channels from adding them again \(after a user has unsubscribed\), if their public key is in the registry, what channels they are subscribed to and a mapping to get to those channels, if they own a channel, etc. 6 | 7 | ## Key data stored on chain 8 | 9 | * If the user is already in the ecosystem 10 | * If their public key is already in the registry 11 | * Whether they own a channel 12 | * The channels they have subscribed to 13 | * The channels they have graylisted 14 | 15 | -------------------------------------------------------------------------------- /protocol-specs-section/future-features-research.md: -------------------------------------------------------------------------------- 1 | # Future Features & Research 2 | 3 | The following future features are getting researched on 4 | 5 | * Exploring IPNS \(DNS\) [\[7\]](../references-section/references.md) for IPFS as a means to form a decentralized communication system between users. 6 | * IPNS is a static file on IPFS that points to your website that's hosted on IPFS. 7 | * We are researching ways in which we can use this to potentially form several communication point that are enabled between user to user. 8 | * This can lead to exciting possibilities, for example, **having a chat thread** on IPFS that carries with itself the previous hash \(cid\) and IPNS keeps on updating the latest hash as a pointer towards that chat. 9 | * This can also be explored to give way to possible **decentralized video messaging** and other exciting breakthroughs. 10 | 11 | {% hint style="info" %} 12 | Since this is at research phase, we will update the paper once we have carried out a PoC in this regard. 13 | {% endhint %} 14 | 15 | 16 | 17 | 18 | 19 | -------------------------------------------------------------------------------- /protocol-specs-section/protocol-integration-flow/README.md: -------------------------------------------------------------------------------- 1 | # Integration Flow for dApp / Server / Smart Contract 2 | 3 | Some of the ways by which the protocol can be Integration into the dApp, Server or Smart Contract flow is designed to keep developer hassle to a minimum and as such, the recommended way to connect to protocol through various architecture are explained. 4 | 5 | * Creating Channel 6 | * Sending Notification from dApp / Serverless 7 | * Sending Notification from Server 8 | * Sending Notification from Smart Contract 9 | 10 | 11 | 12 | -------------------------------------------------------------------------------- /protocol-specs-section/protocol-integration-flow/creating-channel-on-protocol.md: -------------------------------------------------------------------------------- 1 | # Creating Channel on dApp / Server / Smart Contract 2 | 3 | The creation of channel is a **one time process** and as such is recommended to do it either from EPNS dApp, EPNS JS library or a custom JS library of your choice. [Information about the channel payload specs is described here](../specifications/channel-payload-specs.md). 4 | 5 | Interfacing directly via smart contract to protocol to create a channel can also be done by calling it 6 | 7 | * with **public key registry** function 8 | 9 | ```text 10 | createChannelWithFeesAndPublicKey(ChannelType _channelType, bytes calldata _identity, bytes calldata _publickey) external 11 | ``` 12 | 13 | * without **public key registry** function 14 | 15 | ```text 16 | createChannelWithFees(ChannelType _channelType, bytes calldata _identity) 17 | ``` 18 | 19 | | Parameter | Sub Field | Description | 20 | | :--- | :--- | :--- | 21 | | **\_channelType** | | The type of channel to create | 22 | | **\_identity** | | The identity field consists of the following parameters joined together with a delimiter. | 23 | | | payloadtype | Payload type not only indicates the content of notification but also the storage implementation stored. | 24 | | | payloadhash | Indicates the hash of the payload through which payload data can be obtained. | 25 | | **\_publickey** | | Pass the publickey of the wallet in bytes | 26 | 27 | | ChannelType | Description | 28 | | :--- | :--- | 29 | | 0 | Non Interest Bearing, Protocol Reserved Channel for Information | 30 | | 1 | Special Interest Bearing Protocol Reserved Opt in Channel for Promotion | 31 | | 2 | Interest Bearing, Open Channel | 32 | | 3 | Interest Bearing, Mutual Channel | 33 | 34 | | payloadtype | Description | 35 | | :--- | :--- | 36 | | 1 | Represents storage on IPFS with letters Qm happen to correspond with the algorithm \(SHA-256\) and length \(32 bytes\) used by IPFS. | 37 | 38 | {% hint style="info" %} 39 | The delimiter **+** is used for joining the fields together, this is done to optimize the payload written on chain. 40 | {% endhint %} 41 | 42 | {% hint style="success" %} 43 | Example **\_identity**: 1+QmXSuc8iVsNFtsqrFvgHWpa6tJXFLoq2QEWYu2aS6KF8ux 44 | {% endhint %} 45 | 46 | {% hint style="success" %} 47 | Example **\_publickey**: 0x187c0568118be8032ece2499135d16a69b1da955125185c195a900d45eed0a325f2a7bf3ce6eb01375011db55d3a311fd84c2a17d0476edf8c6290f36ed2280b 48 | {% endhint %} 49 | 50 | {% hint style="info" %} 51 | Always recommended to interface with **EPNS JS Library** for abstracting these details out. 52 | {% endhint %} 53 | 54 | {% hint style="warning" %} 55 | This feature of protocol might change for further optimizations in the future. 56 | {% endhint %} 57 | 58 | -------------------------------------------------------------------------------- /protocol-specs-section/protocol-integration-flow/introduction-to-push-nodes.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Brief overview of the PUSH Nodes 3 | --- 4 | 5 | # Introduction to Push Nodes 6 | 7 | [https://medium.com/ethereum-push-notification-service/push-nodes-p2p-web3s-way-to-communicate-6a473577d173](https://medium.com/ethereum-push-notification-service/push-nodes-p2p-web3s-way-to-communicate-6a473577d173) 8 | -------------------------------------------------------------------------------- /protocol-specs-section/protocol-integration-flow/sending-notification-dapp.md: -------------------------------------------------------------------------------- 1 | # Sending Notification from dApp / Serverless 2 | 3 | ## dApp / Serverless integration workflow 4 | 5 | EPNS allows various ways to integrate the protocol into your service. The following flow shows how a dApp can send notifications to the protocol. 6 | 7 | ![](../../.gitbook/assets/inputdappserverless.png) 8 | 9 | ## Sending notification via the dApp 10 | 11 | 1. Use your internal logic to figure out what notification you want to send \(i.e. alerting users on some smart contract event, user actions, movement in their wallets, a podcast or post from your end, etc\). 12 | 2. Form the JSON payload using our JS Library or your which you want to send as notification. Please check supported payload types and their requirements. 13 | 3. Interact with protocol using EPNS JS Library. 14 | 15 | -------------------------------------------------------------------------------- /protocol-specs-section/protocol-integration-flow/sending-notification-from-server.md: -------------------------------------------------------------------------------- 1 | # Sending Notification from Server 2 | 3 | ## Server integration workflow 4 | 5 | EPNS allows various ways to integrate the protocol into your service. The following flow shows how your server can integrate and send notification to the protocol. 6 | 7 | ![](../../.gitbook/assets/inputserver.png) 8 | 9 | ## Sending notification via the server 10 | 11 | 1. Use your internal logic to figure out what notification you want to send \(i.e. alerting users on some smart contract event, user actions, movement in their wallets, a podcast or post from your end, etc\). 12 | 2. Form the JSON payload using our JS Library or your which you want to send as notification. Please check supported payload types and their requirements. 13 | 3. Interact with protocol using EPNS JS Library. 14 | 15 | -------------------------------------------------------------------------------- /protocol-specs-section/protocol-integration-flow/sending-notification-from-smart-contract.md: -------------------------------------------------------------------------------- 1 | # Sending Notification from Smart Contract 2 | 3 | ## Smart Contract workflow 4 | 5 | EPNS allows various ways to integrate the protocol into your service. The following flow shows how your server can integrate and send notification to the protocol. 6 | 7 | ![](../../.gitbook/assets/inputsmartcontract.png) 8 | 9 | ## Sending notification via the smart contract 10 | 11 | 1. Use your internal logic to figure out what notification you want to send \(i.e. alerting users on some smart contract event, user actions, etc\). 12 | 2. This can be done by either having internal logic cooked in your protocol or better yet having a function which you can call from outside which can interact with our protocol. 13 | 3. Please check for supported payload types and their requirements. 14 | 4. Either pass the hash of the content or the data in bytes to EPNS protocol. 15 | 16 | -------------------------------------------------------------------------------- /protocol-specs-section/specifications/README.md: -------------------------------------------------------------------------------- 1 | # Specifications 2 | 3 | EPNS is a notification protocol at its heart. We see notifications as the means to communicate information which can be of different types, carry different utilities and perform different tasks as per their use cases. To enable this, we assign each notification payload a payload type that defines certain characteristics of both the data they carry and the medium of storage. 4 | 5 | Besides the flexibility of notification payload, we also see the rules established between **channels** and their **subscribers** to also have an impact on their utility and use cases. 6 | 7 | Keeping in mind with the above analogies, the following specifications are rolled out to ensure that the specifications and the payload determine the use case of the notification rather than treating them as plain standard ones. 8 | 9 | Some of the use cases we see opening up by this approach are: 10 | 11 | * To allow users to receive notifications with different content type \(images, call to actions, videos, etc.\). 12 | * To allow future content or payload to be different and be interpreted differently. 13 | * Makes interpreting payload storage flexible as changing payload type can indicate the storage medium \(on-chain, IPFS, other storage solutions\). 14 | * To allow service to create channel that any user can subscribe to. 15 | * To allow channels to approve users as subscribers and create business cases around them. 16 | * To allow channel and users to approve each other before information is shared between them. 17 | 18 | 19 | 20 | -------------------------------------------------------------------------------- /protocol-specs-section/specifications/channel-payload-specs.md: -------------------------------------------------------------------------------- 1 | # Channel Payload Specs 2 | 3 | Creating a channel requires sending a JSON payload containing information about the channel to a decentralized storage. This JSON payload is uploaded to a decentralized storage solution \(IPFS at the time of writing\) which is emitted on chain to ensure that channel meta data can be constructed from the said decentralized storage. 4 | 5 | {% hint style="info" %} 6 | Uploading the payload is easily taken care by our dApp or any frontend solutions. While provisions to do it on smart contract directly exists \(with pre-filled IPFS hash\), it's recommended to do it on frontend due to it being a one time process. 7 | {% endhint %} 8 | 9 | ## Channel JSON Payload 10 | 11 | | Parameter | Description | 12 | | :--- | :--- | 13 | | name | Your Channel name \(Recommended Limit: 40 Chars\) | 14 | | info | Short Description of your channel \(Recommended Limit: 240 Chars\) | 15 | | url | Your Channel's website \(Recommended Limit: 160 Chars\) | 16 | | icon | Base64 encoded image \(Recommended Limit 128x128\) | 17 | 18 | ### Example 19 | 20 | ```text 21 | { 22 | "name": "ENS (Ethereum Name Service)", 23 | "info": "ENS offers a secure & decentralised way to address resources both on and off the blockchain using simple, human-readable names.", 24 | "url": "https://ens.domains/", 25 | "icon": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAIAAAACACAIAAABMXPacAAAACXBIWXMAAAsTAAALEwEAmpwYAAAGvmlUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS42LWMxNDAgNzkuMTYwNDUxLCAyMDE3LzA1LzA2LTAxOjA4OjIxICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyIgeG1sbnM6cGhvdG9zaG9wPSJodHRwOi8vbnMuYWRvYmUuY29tL3Bob3Rvc2hvcC8xLjAvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZUV2ZW50IyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ0MgKE1hY2ludG9zaCkiIHhtcDpDcmVhdGVEYXRlPSIyMDIwLTA1LTEzVDE2OjM5OjMyKzA1OjMwIiB4bXA6TW9kaWZ5RGF0ZT0iMjAyMC0wNS0xNlQxMToxNzoyNyswNTozMCIgeG1wOk1ldGFkYXRhRGF0ZT0iMjAyMC0wNS0xNlQxMToxNzoyNyswNTozMCIgZGM6Zm9ybWF0PSJpbWFnZS9wbmciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHBob3Rvc2hvcDpJQ0NQcm9maWxlPSJzUkdCIElFQzYxOTY2LTIuMSIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDo2NDU3OTU0OC1hMjdjLTQ0N2ItYjFhMi1iZjYyYjg2ZDYwMjYiIHhtcE1NOkRvY3VtZW50SUQ9ImFkb2JlOmRvY2lkOnBob3Rvc2hvcDoxMjk2ZDhkZi02OWNjLWJmNGQtOGEzNy1hNjU0MDk0N2RmOWEiIHhtcE1NOk9yaWdpbmFsRG9jdW1lbnRJRD0ieG1wLmRpZDo5NGIxNmJhYy04NzAxLTQ3ZjAtOGExZi1kYjlkN2JkMzAwMmYiPiA8eG1wTU06SGlzdG9yeT4gPHJkZjpTZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjk0YjE2YmFjLTg3MDEtNDdmMC04YTFmLWRiOWQ3YmQzMDAyZiIgc3RFdnQ6d2hlbj0iMjAyMC0wNS0xM1QxNjozOTozMiswNTozMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENDIChNYWNpbnRvc2gpIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDpkOGJhZGNmNi02YzRiLTQ2YzgtYjhjYi05YjUwMDMwYzNmYzMiIHN0RXZ0OndoZW49IjIwMjAtMDUtMTZUMTE6MTc6MTIrMDU6MzAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDQyAoTWFjaW50b3NoKSIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6NjQ1Nzk1NDgtYTI3Yy00NDdiLWIxYTItYmY2MmI4NmQ2MDI2IiBzdEV2dDp3aGVuPSIyMDIwLTA1LTE2VDExOjE3OjI3KzA1OjMwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgQ0MgKE1hY2ludG9zaCkiIHN0RXZ0OmNoYW5nZWQ9Ii8iLz4gPC9yZGY6U2VxPiA8L3htcE1NOkhpc3Rvcnk+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8P3hwYWNrZXQgZW5kPSJyIj8+da2UygAAGzVJREFUeNrtfXmQnOV55+95v6OvuaWR0DlCBxJCIITuQfjAMcQuEnyA184mWxsn5RBvjCtZV2W3amtrU5WqvbLJro+sYxbXxsGxd7kCBhYwPgAJgSxARhKg+xhpdM09fX/f+/z2j+/rY4SMkZgZ9Yh5a6qrp7tnuvv5Pff1CUlMn8t3zDQJpgGYBmD6TAMwDcD0mQZgGoCpdVTjO1PakZ6qAOzfx2yWVQCOHuHg4DQAk3LKZTz7NAcH0dQk8XcwaG6R7dt49PA0ABN8Tp/C//2hnj6NdevF1H32GTOw6no89ph9+eUppo/cKfRZX93JX+zQckn+2RfEcc5/dmGXbO6WnzzHvrPo3oKODpkGYNzO4AC3bUPPMQ1C3LRWZl914Zdt2Gh6T+qB/ezvx9p1sur6KfDVpPGTcXv38NVfsFCk4zCVMp+9yyRT7wIVHnlYw4AEliw1m7ulqWnaBlzqyWXx42f54gsahEynWQ5k7Tp5F+oDaO/A+g1iFakUDx7g4/+kBw9MS8AlnUMHueNlDg6xqRlGkMth3jxzx2+/J83+xOPsPamZDAtFsVZWrpQNmySRmAbgPTuaO17hm3toDCN+D0OGgbnz06Zz1nv6D0NDeOQhFdBPwFpms2bWLNncLfPmTwPw605vL7Zv09Nn2NxEx5Ho042OYPWNpnvLRTg2e3bjhee1uVlFBEAhD0BWr5Hz/NdpAOoOuXMnXn+NAFMpAjG5i0Wk0/LZu83F6pCnfsSeHs1UjLANmcvJvPmmews6O2UagDFnoJ/btrKnh+k0XVfqQGF21Nz6cbN8+UX/z+FhPPKQkvT92n/L58XzZe1aWX2jTANQURdvYOdOLZWYTkPGkIX5nMxfYD55xyUSa+8evPC8zWRojNTZGJZKcvVi032ztLR8sAOx7CheeomHD6nvI5M5/9kwhBjZuOnSWfW6VTh2zPQc1/p/7vviujx6RPvOyboNsmKFfEAl4MAB/uIVDg8x00wj76QCR0bMmrWyefP7ItDwMB55WKn0/ZpdAQBBMQ9rsXyF2bhZUqkPEgClEna8zDf3quMgmRpLl8opFphpMp/9nPG99x9L44Wf26ZmnI+ygBajWcyYKZs2m66uDwYAJ09i+zaePatNdY7m+cyvHM2Zj98my5aNj3546gn2HK95ROe9W74goNywWtatF9e9cgEgsXMHd71OCtO/gvGrSYhFV5vbPzFu2nl4CI88pAA9/8IvsJbZrMyda7q3yOzZVyIAfX3YtlVP9DCToePKu5A2DGFD+fRdpqNjPD/A7t188XltfqciqnN5C3lxHLlpnay5Sa4oAHbt4i92MixrJgMjQgJyYf4nMDqCdevNho3jT4IoR5TOvNtrggCFAhYtMt1bpK1t6gMwPILnX+DhwzaZZNIXIyJgTPwLUbhQQHOL3HW3mQhdPDiIRx9SMfTe1bArkc8jnZJ1683K6yYWgIlNi+x+U//xwXDfAZtK0/NAUJUECMbcft43V9oQGzZMlCVsb8fa9aaQx7uznRE0Z1Au84Xn9blnmctNQQkIAjzzM921R5OuNqVhRIyICAUwIgKIwIhgrCXOZrF4ibnt9onVv489yjNnNJ3+tbSBWoxm0d4hGzfJksUyZSRgNIfv/h99aWeYTlk/KZZiCSWVohAlCZDQseCHIXxfNmyYcLW75RYYkTD8tU4bRNDSgtEsn3mOL7zEIJgKAIzmcN8P7eGecnsbIVDSEkpUMAAhShAgJVJDJEjk81h9o7S1T7j7MWOmrLlJcrlf19FFQEBBMo1kUl/7pT7yFPsGGxuAcoD7HgyP9watzbCArdDdkkoqyfgWShBUQAkRFAuYOdOsXjNJzt+atTJnjikU3o34Y8jkSEsLz/Tpg0/q/iNsXACe+Hn45iHb1kJLsQqrUMJqjERVCCpIQAkSoaVVbNwkrjNJ4Y8x2HKLiIi1v4L1CQoodXiIZNIIQz7xM+4+0JAAnDyrz+0I25utBSw1onio9SpIahggoj4VmsvJkqVO16JJzQHMmo0bbpBcruKSjbG+dWBEMEisjlIpeD6f3mZ3H2o4APjzVzWbh3EQKqxKhIESSq2IgqoipETaiYAS5QBeQtZvwOSftetlZqcp5i8gAlX2p4CIfwAokEwg4fGprfr28UYCIFuU195mOmktxZI20jyqFeWjVmEBC1akAVapRDZr1qyZjJjzncd10d0thFHLev3DOvaPJUIqDwoUSCTEc/nkdp4dbBgAdu3T42dDx2VIWkUYk17qMVAVq1CqkqqwxGgOnbPkpjWXrSQyfwFWrJBsruKPAVJxfqpgxJAItPogmUoitPrYdhaDxgBg7xEGVlVglTUJIEOKVagikgwlrEr8lGWosmXLBRo9J/Ns2CStbVIsnO//VFV/7cGKHNCAgkwSvf189vUGAECVB06GCV+sIiRCRUhaMtQ4DrCk1RoqlrDg0CiWX2MWd13m4ngyiY0bJQxEFYIx7B/zu8Sap6KUSAghEGnN4PXD+mbP5QbgzCB6+0KIDWPuhlWESiVrFI8wAKKYoFBEMmU+fHNDtCYsXSZLrzG53PnsX7XDEanq2R9CCoyBZ/jc7ktXROMEwJDkA4fQUDVUhgpLhJSwKhAVFWSVVsUqh7Ny8wanvbVR+nM2bpZ0WsplXoD9q79W2D+yFNFPOil9o9y2j5MKQLmM7GjtLYdzmitREdE9Vj6WGsZxAC1ZtcZKDmVl3hzZvK6BWvibm7FuvSkWDVnH+FX/p479EbO/QOLHMwnuOMKB7CQCcOAAh4drvxbLLJTVssrvsS8UET3USPVLJBnlkIGaT97qOg3Wmn3dKizsknyhon/Guv+o0/6sExEAroNsCdsPTxYApRIO7mOmqca/VhkoQzK0FfaP1U7sFIVkJSTWviGsWSnLFjXiBEt3txiDMKywP2L2r1dHEETsz4pwQCTjY08vh4uTAsCRwzx7Fp5XU0GeKxAJlTUJUEaqP9TY/wlJqxwtSFOzc8dHG3QuYcYMrFljcnmQNYprJTqmCKWWumDVMRV4Doby+OXJSQHgwAFAxIY1Fs6kjOtJKWSgMaeHcRBQs8aqCJUDo7j9FrejtXEHQ9aukVmzTL44lv2lliGKshSUGgDRr77Lvb1UTjAA586h96QmfJbqxK2zBQlXQ1sVgkjnVO9ohEf/CJYsNL+xoaHH5xwHN28WQqzWRV5CROwvMRT17B/dJlycHMHh/gkG4NABWotikYNDNaznzWRbBkoDILQMasoHoY2kQUsBy+p84RN+fZ9sY56Fc3HtNTKarzF4JS1R8T7rHKRqutQYlELs7+MEAhAE6OlBMgmrGBysvVM6IVfPSRQCgUAhsQ2IRQEhoYreQbnlJmfloqkxPdq9TlpapVCqZCOicrYQY3NENREBCCQ9Hh3ERWmhiwPgRA8GB+i6TCTQd66elHLtfBZKEMAIAKnonzgeHsqzrcX9vdsdTJGTTmHzGlMKoRoVTFGLv6SWF6pZAgEErsG5PM7kJgyAkyeppDFiDPr7OThQl9Ja4bVkTGij2hEquoihIrB6blS+8HGvo2UqDeavWobFC0yuJEDkd5J1Oud8GwBEmYnREk4MTQwAYYjTp+gnYkuVz+HEidqz1y+S5fOckUI0koWo88QqLfT0kFy/1Lvz5qm3l+LDa8VxEWjM80TFF6rDoGYnBCIIladynBAABvqRzUYaBiJwXR4/VnsnEdy2zssWTLXXQAQiUgxYUvdP7kyIyJQDYGY71l9nRovCqIVD6khfVyyrD5uTPgaDiZGAc+dYLKKau/d9nD7FM6drL/jUZnfJXHc4zyqpjfDUgLmz271h8dSjfnQ2rZJZMyRXGpOZqLF/nVNEAQxE0J9FaCcAgJERgHXEdRCEfPutmhBkkvj8R/zBnANqJAHDecyb4d17p48pe1wHH10jFsZyjAFgneapyYHAAKMljAQTAECpCM8f08yUSuHQIa3flHT3Le6KBe7AqIiA5MCouecOv71JMJXP0rlYuQgjhdi5qEXFUgsCxmTuHBQnQgLy+bhgVB80lkrY9VrtkYSHP/hNf7RoSD0zJN3X+Xfd4mDqn4/cIJm0FC1Zn5CoiwDiKg0AA8sJAMBalMsXaOrPZHDwgJ7qrT3yWxvd7pX+iT4YY/7sM4l3GYOZQqctgy0rJVuSSkwwVvOghgoEAVEadwCCAOXgArMlxoDQ7du1XjX98R3+qSHvU93eqkVXAvXjQGcpFnZKtlRzhPgOZzT2RInyREhAGOoFniCSSfSe4p69tcfWXWP+/HPe737MxxV0jMFtq4XGRGRgnQ04Ly4LiUDHGwBGnbRjKF8ZtHAkmcKrr2v9IMOf351YfNWVtpS0ayZWd2G4OCY7XZ+WiO5HrQjjb4TlQtSnAQDP50iWr7yquNLPx66VliYphKz5P+cVBkAlAk4AABxLfVSoH5WKMmm+eYC9p69wAFpS+MhyyQYmLpmNjcsqLqnouAMgQjH1tbhqpTTyzGhckty6Q6/4C0JsWoTFnRgtV0gv9V4pCaHBBebf3icAjiNRF0NMX4FG1I9ZgApJpXj8lP7yrSsQged3h2eGajmuT6wUOhJyrAqSMcWZcQcAjlvBNe7TY03rIeoSkGQSL+/iaO6Kon7/iP7RN8qPbKulF67uwJr5MlSOvZAx7B9lKt9z1e8iAPDdOuoLibhFQOu4wE9gOKcvXlnW+Js/CrK58iNbg8FsTbhvX4aWlBRD4TtyEsaB54y3BBgD14tHKqK+MAopUZJWUMvNsinDvYd57NQVooheP6SPbgtWzNOT5+x9T9WEoC2Fjy5B1krVI6GIAgq4DpLueAMAwPOhBCPqg4j2nIiwjvqEGAcQ+9Od1CtADMi/frhkYD3PzGqzD28tHzpV+1ZbFsq8VmRDVtt4IaIQz0HGmwAAEqkIANSojzrqC2nipoFUkifO2VfenPJC8IOf2x1vlztbVVWSvuSK9v6na0LgGmzpkgKjyeeIFLSAUWlxJkICPJRtpTUViNvEagGIEIAhhTAmk+K2PbZ/ZApT/+ywfufZ8sxWFZjI3Z7dxmdeDfYcqwnB+qswt1WKWnHVKdagI412fwIAyGQIQbVFYExRIs6NRNGJAPBc5Mv86a4pLATf+H/B2Wy5tbnSC0T4LsqB/YfnytXX+A5u6ETOGgIKClBUzMngvZdfLwKAtnaTSsEqNPZ/xlLfRO0bsVioSHOae47ZPcemJAY7j/CJ14O5HVQj8CAOAFiVmU3ctjc8eqYmBDfMlJSPkHHvkAoWpC/ijS4GgFY4Hiyl3uuqRINjqB9HC0Y8V597w5aCKUZ9q/ybp4uea72EiENxIC7EBQS+h4ER/dkvawB0tWBhK0oQAgHR7GN528QA0NyE9naxKlorREStMoxdI6mbqjVQIJXguWH9ye4p5g/9YIfddSKc0Uo4hq6BQ0QYeIAj6RR27Avrkw2LW6VgASBPzG+SucmJAQBA50yUAqLqdFZNgtRGdiigqbrGaEpx+0H2DEwZ6p8a1vu3l2e1qnENHRgH4gocwKE4gINMSg+fCk/VfaOrW+D7CBVF4Pr2i3u7iwNgzmxxPLHKOmZnRO4xHQMxPATEdYW0T7wWTpXLtn5razhYCJpSgANxQBdwRJzoluLC8zlcNvt7a19nfhNaPMkTrQms6ZhIAObPkbY2CTROBCmoJtZIlYRElJmoKCUDBTIJHjqnWw9MAeq/clyf3h9c1QY6Eqkd4yCiu3EErsCBm5BsqXz8XM2ytXvoSHJIcW0rZiUmEgDfw4I5UiiLRiSu/HVEfY3tMONhkoqpEINMgj9+y/bnGloIQuXXXyom3ND3hS7gAg4YqyChW7HGDozHM6N1fynoyCA02HTxS9kvump4zdVwPbGKOBKuuUMEoCaqXUr9kD8FCQ/Zsn1iT0MD8P3ddk9f2NEEGohBpPHFAQzgwDgCR2AEjiRSTrY8hnRlKwtSckMbJhyA+bNl/lWSL0tlYAo1UxwXImJ3OGqViZ5SQWuSr/WEr/U0qEd0cpTfe6Pc2URxwcj1NBADGEhkDBxEEgADx5OSSr0jFAo2zcIljJ5cSt38+mUIFcp6e1ultdQ1CrDiKUU1CkkYffxNzZcbUQ6+tSsYLodNCaER4wgqFDcVOagJhBuJRe1bKNHp85ZZl/K+lwLAikVm7uyoX7VibKNk3JgBtuqvpImFIJPE2ax9/K2GE4KXevXHx8KrIuXjgEbEwBiySvS6O9Gt59e4vahY1445yckCwAg2rXLKKpZRBFDh9IpSimtDcc0AldINVKQ9ya3HdF9fAwlBYPnNN0opN/Q8oStwxBjQETpiDOCQhpEoVGWiTKYTtY2bKQdLWi6xBe0SW3euXSjXdJnRkomFwNRTuXK/Sv26KMFxYBg+uNeGDSMGDxy0bw/bjhRoINH2gSj+MoisrnFqD8IAjoRgZ5PWOUGXfi69d+rWG8VxWbKV5KiMWWx0XnZIEd+qoDnJo4P2yQMNgcDxrD5wsDw7reJI5O1UbS9cwFAM6Ig4EEMawEBF001+10xvXD7ApQMwu00+vNoZKRpb73GaSnGmLhSgIDIDFCpIMW0JffpQeLwBqgXf3m+zgU25YB31I9dTROCIuCJG6EAcEYdwGQKtaV02Sy4zAABuudZcM98MFSuej4lUUB31pZorBSWKHIQCzxWl/uObAS6rLXjhrP3p6fKcNGmknvdZ8T5hQEHkktIIHDEO8jSLOp2udlx+AADc3e10tDgjpUqZLN6IK3V9MoxzFbU2Fqigxde9ffaZY5dNEZUU//NgOeWEjiviwJhY0ccRQGRyY6cIMCIOxQhE8pSNXd54td2/XwCaEvjcRkNjsuVokJM1e1Arn0V1G6koKFAII60+Hz0UnM5fFingPxwLD2XtjATinErlp+p6RtQXAxNLg4hBGWhvcj42fiNv49DA3DVTPr/RFK3kokx11QzUBmuptcdjmVBB0tVCoA/st5NP/iM5/KCnPMtXGgORyMDGtDaRwgEijVQVBQNx2F82Wxa5C8dv2cj4/KMbFpjf2eQUrIxUOia14hpp3DtU80S11tFl2nzuPBP+rHeyheDvjtuiatKNNXt0XQkYouoCVe8IJPJBXRQsvYT87qrxvLjBuCF500LzxW7P8dzBEqLN7xVrjKhjqU4jxR0UKhAjTY7+8FDQX5o8DH7SZ5/vK8/2ScfAQAwhIgYwElldmLEmwYExsNBT1r1nbWJZu2lEAACsmmu+8iFndrtzOi+WlEjziFTb5xWVPDagInF+wsNgwf79wUmyxgWL+06EGWMdR6KJIohEvB/BIMKqBEQqCAYKPVZ07rrG+xcrxvnaHuM8xDK3Re7tdrcs8QbKMlKCQIg4CotXPSKqaFabJ2gFM5O69XT5xTOTgcH/7g2O5sN2L16/JxKpGmEEQ+T7G8CQhmLgGBStngjczy9P/Pt13rh/nom6hMn2HvvYPu3P2/YkxUBFFJVeUohWqB/tiYfRoUDSSe+/rfNavAmc6ztU4Jf2FJpoPXPeMrJKY6VGvwuVIEXZV5KAzpeuSf7LpRMybztRY1ybFzhfu9m9cZ7XVzb5EECtk1cr8QGi8pmhhWnxcKYQfvdwOKHs/+2TYaiacGoNNags2YhvDWiEQsdAiZ6SWdCW+PrG1ARRH5NwGatnjurjB20+CNsTCjFWqr4QEGcm4iWEIXnGOv/uOn/TjAlhi2cG7F8cKs5zNF7QzcqkGyGIZhwqe7GUg2Xm6H1qnvevFjtNEymUk3Eht2OjfODtYG+ftvnqu2JrEwaMvNLKYnIOhmhNe//jRq/JHefvnLP4/bdKQ8Vymxv3FVfpDqlRXwi17C3LnLR7zyLvtlkTPuY/SVfSI/nQYX38SCi0rX5UsGQcK5haWQ3gibJ8ckHiq4vH2dn45ong+73lhV68oBtSG7CS6h1lNuQQ3Y/O8L56tTs7MRlT5pN6Mc+9g/zewfDAoO1MWMeBikSrkDR2TCHCQHGO7l9c628cP3d7f4H3vFVsQegbqVwlIDa/qLQT0+rZ0KQ994vzvc9dNXn7LSb7crb5kA8c0WdPlH1oiw8bVc3iVDYJgbA/QEfG/9tVXmacFNGfHiy/NlSe7ZL1GbTK9zZkQXE2NOvbvK92+Usn98rOkz3MnnblS8ucP13lN6e9kyVRxl0U1bqxhbR7PJYP7jsxPmHBk/325YGg0xlLfcSLRwTssxgR5w+7Et9Y4S2d9OtqX7ZLmveVeP9hu/VcmJawyYOtuqcAwDJwjs5/Wp7Y+P7SXiMhv/h2abQYtLrCd7BeoDwVyIpW/9757pqmy7NYQS5vy+aTp+wDx4ORwM50SSOVtkYBOBDqjEziO9f6GefSFdHfnAgf7C0u8KhjRyYMORCiaJxPzU788RyTdi7bVhe57D2zxwr89tFwR3/Q4WrShRXRSrbueCifmZP62oJLNIlv5fnlt4ttCDxTa+IxgFX2Bpif8e+Z597afpn3SUljNC3zgZP6/RNl0na4SmOsAEBAPUfvr5YlNl3SwtF795d3D5c6PVS1vwFHQozAubXD/cp8b5Z/+dcZSeN0je/O8lvHgz3D5dmeuo6xgAEGQ52RTty/3L9Yj+ixfv2PhwoLPAsxsd9PPROaZt/9g7neZzobZZGaNFTbflF5X6998Ezga9jhgiJCHg/krjnJry24iNBsMOQX3yoVSkGLKwQMWLA4p2Zjm//VBe7VyQba4yUNODfx4rD92xPh0Www16NrJFCepfOflyZvfs8e0X/tCR49VVrgkSIg+6xAzO/N9X9/jtNoO+ykMQdXBgJ+82T4TF/QzLDdk74Q7Sn//uV+83tQRLtz/Mq+YjtC30hZeTqUla3+vfPd1ZlG3OAljTw59KO+8H/1hgOlcI5jT4TOb12V/LcLf40iIvjlfeW3R4LZLvstisb9zCz/njkm5TTo+kBp8NGtnhK/fiLYNhC0wmbF+cslyQ+/q+P48Dn9q6OFuSY8ZZ2FGe/L89wPtTX04lKZCrNz/P4Z/V5v+WwxvDrjfndlos29sDLpC/iHbxX7CwFd9zdmeH8yz53pNfrezCmx2FD++Wznvy9Pbmr3dwzb/3LsV859f+dk8EY2bE96X+tK/IdFXuNTf6pIQHxC5d+dsn99IvzLRc4XZp9fH98+or+zt/zbM8yfdXldiSmzMHYqARCd5/rDb58L/81cb13dTpjTZf7RvvKH2sy/XuBOrWXJUw8AAIeL+vxA+OlOr80TAJb4p7PltJFPdHpT7rtMSQAAEMhZNjkCICRKyowzJfdUT1UArphjpkkwDcA0ANNnGoBpAKbPNAAfyPP/AZ2xJUGOr8uWAAAAAElFTkSuQmCC" 26 | } 27 | ``` 28 | 29 | {% hint style="info" %} 30 | The hash / pointer of the payload is recorded on-chain along with the payload type. This payload type defines how to interpret what storage solution is used and how to retrieve its content on frontend. 31 | {% endhint %} 32 | 33 | 34 | 35 | -------------------------------------------------------------------------------- /protocol-specs-section/specifications/notification-payload-specs.md: -------------------------------------------------------------------------------- 1 | # Notification Payload Specs 2 | 3 | Each notification sent to the protocol is essentially a JSON payload, bytes data or hash / pointer of the JSON payload. The protocol distinguishes payloads content and the storage medium it is on by assigning payload types to each notification. 4 | 5 | {% hint style="info" %} 6 | The JSON Payload can differ with payload types ensuring flexibility of the content, data, storage interpretation and delivery. 7 | {% endhint %} 8 | 9 | ## Notification JSON Payload 10 | 11 | | Parameter | Description | 12 | | :--- | :--- | 13 | | **notification** | \[Required\] Represents the notification typically delivered on the home screen of the platform \(mobile, tablet, web, etc.\), the icon of the channel is automatically added to outline where the notification is coming from. | 14 | | title | \[Required\] The title of the message displayed on the screen, this differs from the **data json** because the title while transforming the payload can be different than the title presented. For example, a secret notification title is always transformed to say **Channel has sent you a secret notification.** | 15 | | body | \[Required\] The body of the message displayed on the screen, this differs from the **data json** because the title while transforming the payload can be different than the title presented. For example, a secret notification body is always transformed to say **Please open the dApp / app to view your notification.** | 16 | | **data** | \[Optional\] The data field present here forms the visual **feedBox** for the user. It indicates the data field the payload will carry. This allows the notification to transform according to the payload type and the content defined on the platform frontend \(i.e. app, dApp, wallet, etc\). | 17 | | type | \[Required\] Each payload has a type which tells how the data should be interpreted, this type is mirrored on the protocol function call as well. | 18 | | secret | \[Optional\] is required for certain payload types to decrypt the data. | 19 | | asub | \[Optional\] is the subject shown in the feed item. | 20 | | amsg | \[Optional\] is the message shown in the feed item, has rich text formatting. | 21 | | acta | \[Optional\] is the call to action of that feed item. | 22 | | aimg | \[Optional\] is the image shown in the feed item, this field is also capable of carrying **other media** links. | 23 | | atime | \[Optional\] time in epoch when the notification should be displayed, if present, the frontend should respect this field and delay the notification till the schedule is reached. If the time is before the current time, the notification is treated as to be dispatched and displayed immediately. | 24 | | **recipients** | \[Optional\] When presented with appropriate payload type allows notification to be delivered to many subscribers \(but not all subscriber\) of that channel. | 25 | 26 | {% hint style="info" %} 27 | If no **data** is carried in the **payload** \(or only **atime** is carried\), it is assumed that the notification is not important and hence **persist \(or appearance\)** in the frontend **feedBox** of the user. 28 | {% endhint %} 29 | 30 | ## Payload Types 31 | 32 | The following are few payload types that are already defined, though they can change as we move forward. Notification payload type for EPNS is infinitely extensible and opens a huge range of possibilities including **multi-factor authentication, payments, blacklisting address \(Multi-sig contract as a channel with exchanges as their subscribers\), etc.** The data defined in the JSON payload they carry is used to interpret and extend that functionality. 33 | 34 | ### Direct Protocol Payload \(Type 0\) 35 | 36 | Direct payloads are special payloads meant for sending directly to the protocol, the delimiter **+** divides the subject and message which are the only two fields it carries. 37 | 38 | ```text 39 | type+title+body 40 | ``` 41 | 42 | {% hint style="warning" %} 43 | It's always recommended to use other payloads for dApp or server interaction. This payload should be used sparingly when it's absolutely necessary. The 'type' here is a special field which is different from the type in identity. 44 | {% endhint %} 45 | 46 | {% hint style="info" %} 47 | Always recommended to interface with **EPNS JS Library** for abstracting these details out. 48 | {% endhint %} 49 | 50 | ### Broadcast Payload \(Type 1\) 51 | 52 | Broadcast notification goes to all subscriber of a channel, the notification payload in this case is not encrypted. 53 | 54 | ```text 55 | { 56 | "notification": { 57 | "title": "The title of your message displayed on screen (50 Chars)", 58 | "body": "The intended message displayed on screen (180 Chars)" 59 | }, 60 | "data": { 61 | "type": "1", 62 | "secret": "", 63 | "asub": "[Optional] The subject of the message displayed inside app (80 Chars)", 64 | "amsg": "[Optional] The intended message displayed inside app (500 Chars)", 65 | "acta": "[Optional] The cta link parsed inside the app", 66 | "aimg": "[Optional] The image url or youtube url which is shown inside the app", 67 | "atime": "[Optional] Epoch time for the notification to be shown or dispatch" 68 | } 69 | } 70 | ``` 71 | 72 | ### Secret Payload \(Type 2\) 73 | 74 | Secret notifications are intended to be delivered to one subscriber of the channel, these are encrypted using ECC\(Elliptic Curve Cryptography\) [`[4]`](../../references-section/references.md) and AES\(Advanced Encryption Standard\) [`[5]`](../../references-section/references.md). The secret which is generated by the channel using whatever means they prefer should be kept to 15 characters or less, this secret \(plain version\) uses AES to encrypt the fields: **asub, amsg, acta, aimg**. 75 | 76 | The rationale behind using ECC with AES is to ensure that the payload is not over bloated. 77 | 78 | ```text 79 | { 80 | "notification": { 81 | "title": "The title of your message displayed on screen (50 Chars)", 82 | "body": "The intended message displayed on screen (180 Chars)" 83 | }, 84 | "data": { 85 | "type": "2", 86 | "secret": "No more than 15 characters, encrypted using public key of the intended recipient", 87 | "asub": "encrypted by secret using AES | [Optional] The subject of the message displayed inside app (80 Chars)", 88 | "amsg": "encrypted by secret using AES | [Optional] The intended message displayed inside app (500 Chars)", 89 | "acta": "encrypted by secret using AES | [Optional] The cta link parsed inside the app", 90 | "aimg": "encrypted by secret using AES | [Optional] The image url which is shown inside the app", 91 | "atime": "[Optional] Epoch time for the notification" 92 | } 93 | } 94 | ``` 95 | 96 | {% hint style="info" %} 97 | Why not just use ECC? ECC increases the length of the cipher text and hence the payload which will be delivered. Using ECC with AES ensure the payload length is kept at a manageable level and allows channels to send more information in the notification while still keeping the best encryption practices. 98 | {% endhint %} 99 | 100 | {% hint style="warning" %} 101 | The discussion on using a public key - private key encryption or a derivation of it is still under discussion. Even if we decide to go with the above encryption for secret messages, we can in the future create a payload type that can offer encryption / decryption in a different way. 102 | {% endhint %} 103 | 104 | #### Example Notification Payload \(Plain\) 105 | 106 | ```text 107 | { 108 | "notification": { 109 | "title": "The title of your message displayed on screen (50 Chars)", 110 | "body": "The intended message displayed on screen (180 Chars)" 111 | }, 112 | "data": { 113 | "type": "2", 114 | "secret": "vBGK71PFl7mzWob", 115 | "asub": "The Great Renewal: Your ENS Domain has expired and someone is about to get them", 116 | "amsg": "[d:ENS] domains from 2017 that have expired.\n\nGo check your [b:@ensdomains] right now and renew your accounts.", 117 | "acta": "https://ens.domains/", 118 | "aimg": "https://i.ibb.co/WKNVN9y/enssamplemsgimg.jpg", 119 | "atime": "1595083821" 120 | } 121 | } 122 | ``` 123 | 124 | {% hint style="info" %} 125 | **Recommended** to use the **EPNS** **JS Library** to handle the generation of encrypted payload easily, it can talk to our protocol to also fetch the public key required. 126 | {% endhint %} 127 | 128 | #### Example Notification Payload \(Encrypted\) 129 | 130 | ```text 131 | { 132 | "notification": { 133 | "title": "The title of your message displayed on screen (50 Chars)", 134 | "body": "The intended message displayed on screen (180 Chars)" 135 | }, 136 | "data": { 137 | "type": "2", 138 | "secret": "e291826a995ab03b0dd69c360f3deb3803e130dc7d3bd94f1016494bc1fad4f4b816524f8cbdd068f0caf94a1cec682ab75755327e4410267721e44f83d73a56e88b911051eb0a2f2ee1ffef5f2cf5419cbc81895cd7d290b70060ef80b727fd52", 139 | "asub": "U2FsdGVkX181J09umWprAgmLOaDyZXojQjLPlJ31G0LDgXHBgnNsFEOKgjqhKJ2vWaPP5Xmt8sIQLmB3YYkjQO1LhrV7sr0FDlwqjLhSimxmI1EnjOdEHyiE1RO7LV0O", 140 | "amsg": "U2FsdGVkX18J7Myet9yljBLtNMpqz86qWgmjrK/9WyP+LD9OVerohkl5jc791UOlU6cV4UFVhdwJHyQSMYNNDPOaJMhxlLF2tL7LIBDeGqPA2AlgWqe2qbF1JC+zjIgBR/+IUfbr0+gz4JUBydK3d1dJGPFYliQTqD7EOjv38No=", 141 | "acta": "U2FsdGVkX188zXRR3URQR2xedjftDOHD5E3k+ggKe+8F6MxW86464rl6y1ZhX3jY", 142 | "aimg": "U2FsdGVkX188AaU187LFzqaibpfoOXb+XkCNbsLpV29CrQOVjC9BfWpxwGXE9Er7OdJ63yblqFYCaqNoGAHCOg==", 143 | "atime": "1595083821" 144 | } 145 | } 146 | ``` 147 | 148 | ### Targeted Payload \(Type 3\) 149 | 150 | Targeted notifications go to a single subscriber of a channel, the notification payload in this case is not encrypted. 151 | 152 | ```text 153 | { 154 | "notification": { 155 | "title": "The title of your message displayed on screen (50 Chars)", 156 | "body": "The intended message displayed on screen (180 Chars)" 157 | }, 158 | "data": { 159 | "type": "3", 160 | "secret": "", 161 | "asub": "[Optional] The subject of the message displayed inside app (80 Chars)", 162 | "amsg": "[Optional] The intended message displayed inside app (500 Chars)", 163 | "acta": "[Optional] The cta link parsed inside the app", 164 | "aimg": "[Optional] The image url or youtube url which is shown inside the app", 165 | "atime": "[Optional] Epoch time for the notification to be shown or dispatch" 166 | } 167 | } 168 | ``` 169 | 170 | ## Extending for Future Payload 171 | 172 | {% hint style="info" %} 173 | The following payloads are in discussion and form an example of how the payload specs is ever expanding and can include more than just information as notification. 174 | {% endhint %} 175 | 176 | ### Multi-Targeted Payload \(Type x\) 177 | 178 | Multi-Targeted notifications go to a more than one subscriber of a channel, the notification payload in this case is not encrypted. The total number of subscribers supported is TBA. 179 | 180 | ```text 181 | { 182 | "notification": { 183 | "title": "The title of your message displayed on screen (50 Chars)", 184 | "body": "The intended message displayed on screen (180 Chars)" 185 | }, 186 | "data": { 187 | "type": "4", 188 | "secret": "", 189 | "asub": "[Optional] The subject of the message displayed inside app (80 Chars)", 190 | "amsg": "[Optional] The intended message displayed inside app (500 Chars)", 191 | "acta": "[Optional] The cta link parsed inside the app", 192 | "aimg": "[Optional] The image url or youtube url which is shown inside the app", 193 | "atime": "[Optional] Epoch time for the notification to be shown or dispatch" 194 | }, 195 | "recipients": { 196 | [0xAb...], 197 | ... 198 | [0xEb...] 199 | } 200 | } 201 | ``` 202 | 203 | ### Blacklist Payload \(Type x\) 204 | 205 | Blacklist payload are a future forward payload meant to only demonstrate how the payload data and type defines what information the payload will carry. 206 | 207 | ```text 208 | { 209 | "data": { 210 | "type": "5", 211 | "blacklist": { 212 | address1, 213 | address2, 214 | .... 215 | address100 216 | } 217 | } 218 | } 219 | ``` 220 | 221 | {% hint style="info" %} 222 | The support for payload types is left to third party frontend / infrastructure services to implement. The accompanying EPNS products however will implement all payloads types which are accepted as official after community discussion. 223 | {% endhint %} 224 | 225 | -------------------------------------------------------------------------------- /protocol-specs-section/the-epns-product.md: -------------------------------------------------------------------------------- 1 | # EPNS Products 2 | 3 | ## Problem Statement 4 | 5 | EPNS notification protocol implements game theory, DeFi incentives and enables sending decentralized push notification in platform agnostic fashion. It's designed to be integrated with third-party wallets so that notifications could finally arrive and achieve the network effect on the blockchain. 6 | 7 | Despite this, it does suffer from the classic **chicken and egg problem**! Which is, for dApps or services to implement the protocol, they would want the notifications to be delivered to their users and see the value before adopting it to **send notifications**, and unless they adopt it, it's going to be tough for user wallets to spend time in integrating a protocol ****and frontend for **receiving notification**. 8 | 9 | ## Solution 10 | 11 | In order to facilitate the adoption of the protocol and to provide value to services, we will also be building the product suite of EPNS. 12 | 13 | ![Ethereum Push Notification Service Protocol / Product](../.gitbook/assets/plainmockupglow.jpg) 14 | 15 | ### **Mobile App** 16 | 17 | Serves the purpose of delivering notifications from decentralized protocol to centralized EPNS Infra to centralized platforms \(iOS and Android\). 18 | 19 | ### dApp 20 | 21 | Enables receiving notifications from web browsers and also enables delivery of notifications from protocol to decentralized carriers. 22 | 23 | ### **EPNS Infra \(Push Service\)** 24 | 25 | Enables carrying notifications from decentralized protocol to centralized solutions \(iOS, Android, Web, etc\). Also enables third-party dApps, services and protocols to start experiencing the notification impact as notifications are delivered following the entire protocol / product lifecycle. 26 | 27 | ### **Showrunners** 28 | 29 | These are channels created and run by us for the benefit of the community and for users to come and see why push notifications transformed the traditional world. Few examples of showrunners which we will be running are: 30 | 31 | * **Wallet crypto movement tracker** 32 | * **ENS domain expiry** 33 | * **Compound Liquidation alert** 34 | * **EthGas abnormal price alerter** 35 | * **Crypto price tracker** 36 | 37 | ### **JS Library** 38 | 39 | Considerably reduces the integration time required for third party dApps, servers. 40 | 41 | We see these products to enable instant value add to the protocol and help in increasing awareness and eventually drive the adoption of the protocol. 42 | 43 | -------------------------------------------------------------------------------- /protocol-specs/epns-protocol/protocol-integration-flow/README.md: -------------------------------------------------------------------------------- 1 | # Protocol Integration Flow 2 | 3 | Integration is designed to keep developer hassle to a minimum and as such, the recommend way to connect to protocol through various architecture are explained. 4 | 5 | * Creating Channel 6 | * Sending Notification 7 | * From dApp / Serverless 8 | * From Server 9 | * From Smart Contract 10 | 11 | 12 | 13 | -------------------------------------------------------------------------------- /protocol-specs/epns-protocol/protocol-integration-flow/creating-channel.md: -------------------------------------------------------------------------------- 1 | # Creating Channel 2 | 3 | The creation of channel is a **one time process** and as such is recommended to do it either from EPNS dApp, EPNS JS library or a custom JS library of your choice. [Information about the channel payload specs is described here](../../specifications/channel-payload-specs.md). 4 | 5 | Interfacing directly via smart contract to protocol to create a channel can also be done by calling it 6 | 7 | * with **public key registry** function 8 | 9 | ```text 10 | createChannelWithFeesAndPublicKey(bytes calldata _identity, bytes calldata _publickey) external 11 | ``` 12 | 13 | * without **public key registry** function 14 | 15 | ```text 16 | createChannelWithFees(bytes calldata _identity) 17 | ``` 18 | 19 | | Parameter | Sub Field | Description | 20 | | :--- | :--- | :--- | 21 | | **\_identity** | | The identity field consists of the following parameters joined together with a delimiter. | 22 | | | payloadtype | payload type not only indicates the content of notification but also the storage implementation stored. | 23 | | | payloadhash | Indicates the hash of the payload through which payload data can be obtained. | 24 | | **\_publickey** | | Pass the publickey of the wallet in bytes | 25 | 26 | | payloadtype | Description | 27 | | :--- | :--- | 28 | | 1 | Represents storage on IPFS with letters Qm happen to correspond with the algorithm \(SHA-256\) and length \(32 bytes\) used by IPFS. | 29 | 30 | {% hint style="info" %} 31 | The delimiter **+** is used for joining the fields together, this is done to optimize the payload written on chain. 32 | {% endhint %} 33 | 34 | {% hint style="success" %} 35 | Example **\_identity**: 1+QmXSuc8iVsNFtsqrFvgHWpa6tJXFLoq2QEWYu2aS6KF8ux 36 | {% endhint %} 37 | 38 | {% hint style="success" %} 39 | Example **\_publickey**: 0x187c0568118be8032ece2499135d16a69b1da955125185c195a900d45eed0a325f2a7bf3ce6eb01375011db55d3a311fd84c2a17d0476edf8c6290f36ed2280b 40 | {% endhint %} 41 | 42 | {% hint style="info" %} 43 | Always recommended to interface with **EPNS JS Library** for abstracting these details out. 44 | {% endhint %} 45 | 46 | {% hint style="warning" %} 47 | This feature of protocol might change for further optimizations in the future. 48 | {% endhint %} 49 | 50 | -------------------------------------------------------------------------------- /protocol-specs/the-epns-product/epns-infra-push-service.md: -------------------------------------------------------------------------------- 1 | # EPNS Infra \(Push Service\) 2 | 3 | ## 4 | 5 | -------------------------------------------------------------------------------- /protocol-specs/the-epns-product/js-library.md: -------------------------------------------------------------------------------- 1 | # JS Library 2 | 3 | -------------------------------------------------------------------------------- /protocol-specs/the-epns-product/showrunners.md: -------------------------------------------------------------------------------- 1 | # Showrunners 2 | 3 | -------------------------------------------------------------------------------- /protocol-specs/the-epns-protocol/activation-of-a-service.md: -------------------------------------------------------------------------------- 1 | # Channel Activation 2 | 3 | ## Concept 4 | 5 | A **service** needs to activate themselves on the protocol as a one time step before they can send notification to their subscribers. When a service is activated on the protocol, they are referred to as a **Channel**. 6 | 7 | The channel is also required to stake fees in DAI which is **50 DAI or higher**, this is used to create a staking pool which in turn interacts with other DeFi protocol to earn interest. This interest is then distributed to all the **subscribers** of that service in a weighted manner preferring the earliest subscriber more than the later ones. 8 | 9 | {% hint style="info" %} 10 | There is always 1:1 mapping between a service \(wallet\) and the channel it creates. 11 | {% endhint %} 12 | 13 | ## Game Theory and User Incentives 14 | 15 | In order to ensure the proper participation of all players, following game theory is applied to keep each player in the system motivated to be a good actor in the ecosystem. 16 | 17 | * Contract owner cannot send notification on behalf of channel unless the control is delegated to it by the channel owner as an on-chain event. 18 | * The **service** needs to deposit **50 DAI or higher** as staking to activate themselves, this ensures that serious players participate in the game. 19 | * The **channel stake** goes to a combined stake pool of channels and starts earning interest using [**AAVE Protocol**](https://aave.com/) ****\(at the time of writing, this can be replaced with a similar DeFi protocol in the future\). 20 | * The **channel owner** decides the fees, since this interest is distributed among their users weighted towards earliest subscriber, and is refundable, having **higher stake incentivizes more users** to subscribe to the channel. 21 | * This **channel** can be deactivated by the **channel owner** with a penalty of **20 DAI**, this ensures that bad actors are unable to abuse the system as monetary loss will occur with each recurrence, small enough for serious players to not worry about it but act as a further deterrent for bad players. 22 | * Upon deactivation, the channel is unable to send notification and his ratio in the **stake pool** is reduced to **10 DAI**, as a result, the proportionate ratio from interest pool for the channel is also reduced according, the channel continues giving its' fair share of interest to all existing subscribers of the channel, though the channel loses the ability to add more users. 23 | * The rest of the penalty \(**10 DAI**\) goes into the revenue pool. 24 | 25 | {% hint style="info" %} 26 | The penalty fee, stake fee can be adjusted in the future in a decentralized manner 27 | {% endhint %} 28 | 29 | ## Interest Generation and Formula 30 | 31 | The stake pool consists of many channels and each have dynamic fees, 32 | 33 | -------------------------------------------------------------------------------- /references-section/references.md: -------------------------------------------------------------------------------- 1 | # References 2 | 3 | \[1\] Blockchain Growth Forecast: [https://www.marketsandmarkets.com/Market-Reports/blockchain-technology-market-90100890.html](https://www.marketsandmarkets.com/Market-Reports/blockchain-technology-market-90100890.html) 4 | 5 | \[2\] Impact of Push Notifications: [https://blog.e-goi.com/infographic-push-notification/](https://blog.e-goi.com/infographic-push-notification/) 6 | 7 | \[3\] IPFS Wiki: [https://en.wikipedia.org/wiki/InterPlanetary\_File\_System](https://en.wikipedia.org/wiki/InterPlanetary_File_System#:~:text=The%20InterPlanetary%20File%20System%20%28IPFS,in%20a%20distributed%20file%20system.) 8 | 9 | \[4\] Elliptic Curve Cryptography: [https://en.wikipedia.org/wiki/Elliptic-curve\_cryptography](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography) 10 | 11 | \[5\] Advance Encryption Standard: [https://en.wikipedia.org/wiki/Advanced\_Encryption\_Standard](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) 12 | 13 | \[6\] Game Theory and Trust: [https://ncase.me/trust/](https://ncase.me/trust/) 14 | 15 | \[7\] IPNS: [https://docs.ipfs.io/concepts/ipns/](https://docs.ipfs.io/concepts/ipns/) 16 | 17 | -------------------------------------------------------------------------------- /risks/risks.md: -------------------------------------------------------------------------------- 1 | # Risks 2 | 3 | You acknowledge and agree that there are numerous risks associated with purchasing **$PUSH**, holding $PUSH, and using $PUSH for participation in the EPNS protocol. In the worst scenario, this could lead to the loss of all or part of the $PUSH which had been purchased. **IF YOU DECIDE TO PURCHASE $PUSH, YOU EXPRESSLY ACKNOWLEDGE, ACCEPT AND ASSUME THE FOLLOWING RISKS:** 4 | 5 | 1. **Uncertain Regulations and Enforcement Actions:** The regulatory status of $PUSH and distributed ledger technology is unclear or unsettled in many jurisdictions. The regulation of virtual currencies has become a primary target of regulation in all major countries in the world. It is impossible to predict how, when or whether regulatory agencies may apply existing regulations or create new regulations with respect to such technology and its applications, including $PUSH and/or the EPNS protocol. Regulatory actions could negatively impact $PUSH and/or the EPNS protocol in various ways. The Company, the Distributor \(or their respective affiliates\) may cease operations in a jurisdiction in the event that regulatory actions, or changes to law or regulation, make it illegal to operate in such jurisdiction, or commercially undesirable to obtain the necessary regulatory approval\(s\) to operate in such jurisdiction. After consulting with a wide range of legal advisors and continuous analysis of the development and legal structure of virtual currencies, a cautious approach will be applied towards the sale of $PUSH. Therefore, for the token sale, the sale strategy may be constantly adjusted in order to avoid relevant legal risks as much as possible. For the token sale, the Company and the Distributor are working with the specialist blockchain department at Bayfront Law LLC. 6 | 2. **Inadequate disclosure of information:** As at the date hereof, the EPNS protocol is still under development and its design concepts, consensus mechanisms, algorithms, codes, and other technical details and parameters may be constantly and frequently updated and changed. Although this white paper contains the most current information relating to the EPNS protocol, it is not absolutely complete and may still be adjusted and updated by the EPNS team from time to time. The EPNS team has no ability and obligation to keep holders of $PUSH informed of every detail \(including development progress and expected milestones\) regarding the project to develop the EPNS protocol, hence insufficient information disclosure is inevitable and reasonable. 7 | 3. **Competitors:** Various types of decentralised applications and networks are emerging at a rapid rate, and the industry is increasingly competitive. It is possible that alternative networks could be established that utilise the same or similar code and protocol underlying $PUSH and/or the EPNS protocol and attempt to re-create similar facilities. The EPNS protocol may be required to compete with these alternative networks, which could negatively impact $PUSH and/or the EPNS protocol. 8 | 4. **Loss of Talent:** The development of the EPNS protocol greatly depends on the continued co-operation of the existing technical team and expert consultants, who are highly knowledgeable and experienced in their respective sectors. The loss of any member may adversely affect the EPNS protocol or its future development. Further, stability and cohesion within the team is critical to the overall development of the EPNS protocol. There is the possibility that conflict within the team and/or departure of core personnel may occur, resulting in negative influence on the project in the future. 9 | 5. **Failure to develop:** There is the risk that the development of the EPNS protocol will not be executed or implemented as planned, for a variety of reasons, including without limitation the event of a decline in the prices of any digital asset, virtual currency or $PUSH, unforeseen technical difficulties, and shortage of development funds for activities. 10 | 6. **Security weaknesses:** Hackers or other malicious groups or organisations may attempt to interfere with $PUSH and/or the EPNS protocol in a variety of ways, including, but not limited to, malware attacks, denial of service attacks, consensus-based attacks, Sybil attacks, smurfing and spoofing. Furthermore, there is a risk that a third party or a member of the Company, the Distributor or their respective affiliates may intentionally or unintentionally introduce weaknesses into the core infrastructure of $PUSH and/or the EPNS protocol, which could negatively affect $PUSH and/or the EPNS protocol. Further, the future of cryptography and security innovations are highly unpredictable and advances in cryptography, or technical advances \(including without limitation development of quantum computing\), could present unknown risks to $PUSH and/or the EPNS protocol by rendering ineffective the cryptographic consensus mechanism that underpins that blockchain protocol. 11 | 7. **Other risks:** In addition, the potential risks briefly mentioned above are not exhaustive and there are other risks \(as more particularly set out in the Terms and Conditions\) associated with your purchase, holding and use of $PUSH, including those that the Company or the Distributor cannot anticipate. Such risks may further materialise as unanticipated variations or combinations of the aforementioned risks. You should conduct full due diligence on the Company, the Distributor, their respective affiliates, and the EPNS team, as well as understand the overall framework, mission and vision for the EPNS protocol prior to purchasing $PUSH. 12 | 13 | -------------------------------------------------------------------------------- /summary-section/summary.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | * Ethereum Push Notification Service Protocol introduces a variety of ways to form information that are extremely powerful and extensible on content using notifications. 4 | * The protocol enables delivery of notification with incentives for users for both centralized carriers \(iOS, Android, Firefox, Chrome, Telegram, User Wallets, etc\) and decentralized carriers. 5 | * The rules of the protocol ensures fair participation and encourage all parties through incentives \(monetary or otherwise\) to achieve win-win situations. 6 | 7 | {% hint style="success" %} 8 | Most of the features of protocol and product including the DeFi aspect were created before writing this whitepaper though as with any project, some of the technical details will change over time for improvements and optimizations. 9 | {% endhint %} 10 | 11 | -------------------------------------------------------------------------------- /team-and-acheivements-section/achievements.md: -------------------------------------------------------------------------------- 1 | # Achievements 2 | 3 | 4 | 5 | ![](../.gitbook/assets/achievementsgsheetv4litepaper%20%282%29.jpg) 6 | 7 | -------------------------------------------------------------------------------- /team-and-acheivements-section/founders.md: -------------------------------------------------------------------------------- 1 | # Founders 2 | 3 | ![](../.gitbook/assets/founder.jpg) 4 | 5 | 6 | 7 | --------------------------------------------------------------------------------