Category: wallet-address communication protocol / opt-in notification and chat network / partially decentralized messaging middleware
Summary: Push Protocol is best understood not as a pure transport layer or a simple notification product, but as a wallet-address communication middleware that bundles channel-based notifications, request-gated chat, verification proofs, and a node network into one app-facing developer surface. Its reusable mechanism is the way spam control and delivery policy are expressed through channel opt-ins, chat-request inboxes, signed payload validation, and node-mediated storage / dispatch, while the project’s roadmap shows a persistent tension between current team-run operations and the ambition to become a community-run proof-of-stake communication network.
What it does:
Lets dapps, wallets, smart contracts, and backends send notifications to wallet addresses through Push channels
Supports wallet-to-wallet and group chat with request-box gating before inbox delivery and notifications are enabled
Uses Push Nodes to validate payload formats, sender permissions, and verification proofs before storing or dispatching communications
Stores chat messages on IPFS and notifications on Push Nodes, IPFS, or onchain depending on the client flow described in the docs
Exposes a unified SDK and application layer that bundles notifications, chat, and other communication surfaces into one developer integration path
Publishes a roadmap toward Push Nodes, proof-of-stake security, and a broader “Push Network” / communication layer vision
Key claims:
Push earns a corpus entry because it makes one specific mechanism legible: wallet-address communication routed through explicit opt-in channels and request-gated inboxes, rather than through email-style identifiers or purely app-local spam heuristics.
The current docs show that Push is still best understood as middleware above a node network, not as a fully decentralized transport substrate. They repeatedly say Push Nodes validate, store, and dispatch payloads, while also acknowledging that today those nodes are run by Push Protocol and only later meant to decentralize.
Spam control is the core design surface to retain. Notifications are channel opt-in / opt-out; chat uses request boxes that require recipient acceptance before inbox placement and notification delivery. That makes Push a useful comparison class for XMTP’s network-level consent system, but with more app-visible gating and less portable inbox abstraction.
Push’s architecture docs preserve an important UX-versus-privacy tradeoff: messages sent to addresses that have not yet authenticated into the protocol may remain plaintext until the recipient generates protocol keys. That makes current Push Chat meaningfully different from systems that insist on end-to-end encryption semantics from the first contact.
Verification proofs are another mechanism worth retaining. Push uses proof bundles to validate sender, chain, and content context for notifications and chat, which makes it analytically useful as a signed-message middleware layer rather than only as a consumer app.
Push is also notable for product drift. It began as EPNS-style notifications, broadened into chat and other communications, and now speaks in roadmap language about a proof-of-stake Push Network / L2 for communication. That evolution is relevant because control may migrate from channel operators and app integrations into node economics, token governance, and network-role design if the roadmap is realized.
Whitepaper: Yes, in legacy EPNS form. Push’s original litepaper survives from the Ethereum Push Notification Service era and is useful mainly as historical framing; the live docs and roadmap are more important for understanding the current architecture. See ../whitepapers/push-protocol-primary-sources-2026-05-09.md. Local litepaper copy: ../whitepapers/push-protocol-epns-litepaper.pdf.