Local litepaper copy saved as: research/crypto/whitepapers/push-protocol-epns-litepaper.pdf
Key takeaways from primary sources
Push is best understood as wallet-address communication middleware rather than as a pure transport network. The docs focus on how apps, wallets, contracts, and backends can send notifications and chat through Push channels, request boxes, SDKs, and Push Nodes.
The core mechanism to retain is explicit spam gating. Notifications are opt-in / opt-out by channel, and chats initially land in a request box rather than the main inbox until the recipient accepts.
Push Nodes are the main operational control surface in the current architecture. The docs repeatedly say nodes validate payloads, check sender permissions, store or process content, and dispatch notifications or chats.
The current system is not yet fully decentralized in practice. The architecture pages explicitly say Push Nodes are currently run by Push Protocol, while the roadmap points toward a proof-of-stake Push Network in which anyone can run nodes.
Chat and notifications are tightly coupled. Push says every chat message has a notification built in once the recipient has accepted the request, which is a distinctive product-level bundling of message transport and re-engagement.
The chat architecture preserves a notable tradeoff: if a recipient has not yet authenticated into Push, messages may remain plaintext until that recipient generates protocol keys. That is an important distinction from systems that require end-to-end encrypted readiness before first delivery.
The tokenomics and roadmap materials show that Push wants to evolve from an EPNS-style notification protocol into a broader communication network with staking, node roles, and token-governed economics. Whether that roadmap lands matters because the control surface would shift from channel and SDK design into validator / storage / delivery-node incentives.
Specific source signals worth retaining
docs/notifications/ + notification architecture page: clearest explanation of channel-based notifications, subscriber inbox vs spam placement, and Push Node validation / dispatch roles.
docs/chat/ + chat architecture page: best source for request-box gating, bundled notifications, IPFS-backed message storage, Push Node mediation, and the plaintext-until-authenticated edge case.
docs/tokenomics/: shows how Push frames the token as utility, governance, security, and incentives around the communication layer.
docs/roadmap/: most useful source for the gap between current implementation and the planned Push Nodes / PoS / communication-network future.
push-dapp README: confirms the current public product surface and how the project presents itself in repo form.
Legacy EPNS litepaper: useful historical framing for how the project started, but less authoritative than the live docs for current architecture.
Why this entry belongs in the corpus
Push earns a place because it exposes a distinct mechanism for web3-native communication: channel opt-ins plus chat requests, validated by a node layer that can sit between any wallet address and app-facing communication experience.
It is a strong comparison class for XMTP because both target wallet-native messaging, but Push currently expresses spam control through channel and request workflows more than through portable inbox identity or network-level consent portability.
It is a strong comparison class for Waku, Nym, and HOPR because Push sits much closer to the app and wallet integration layer, where the key control surface is not anonymous relay topology but who can notify whom, under what proof and node policy, and how much of the system remains team-operated.
The reusable insight is that “decentralized communication” can centralize at a surprisingly application-shaped layer: channel creation, request handling, node validation policy, notification delivery logic, and SDK defaults may matter more than the nominal existence of a token or future node network.
Whitepaper / docs status
Push has live docs and a legacy EPNS litepaper.
For this pass, the live docs and roadmap were the clearest sources for current architecture; the EPNS litepaper is more useful as historical background than as a precise description of the present system.
Local litepaper path: research/crypto/whitepapers/push-protocol-epns-litepaper.pdf