User Notification

Notifications are triggered by specific on-chain events recorded in transaction logs. Common triggers include:

• Token transfers (incoming/outgoing)
• Contract state changes (e.g., governance proposal created)
• Wallet activity (large deposits, approvals)
• Oracle price updates These events are emitted via EVM logs or similar mechanisms on other VMs, which notification services index and parse.

Notifications are delivered through multiple channels to ensure user reach:

• In-App/In-Dapp Alerts: Displayed within the application interface.
• Email: Traditional but reliable for non-urgent updates.
• Push Notifications: Mobile and desktop alerts via services like Firebase Cloud Messaging.
• Telegram/Discord Bots: Popular for community and project-wide alerts.
• SMS: Used for critical security alerts (e.g., withdrawal confirmations). The choice of channel depends on urgency and user preference.

Users or applications subscribe to specific event streams using filters. Key filtering parameters include:

• Contract Address: Listen to events from a specific smart contract.
• Event Signature: The specific event (e.g., Transfer(address,address,uint256)).
• Topic Filters: Indexed parameters within an event log.
• Wallet Address: Monitor activity for a specific EOA or contract wallet. This prevents notification spam by focusing only on relevant on-chain activity.

Reliable notifications require robust backend infrastructure:

• Blockchain Node Connection: A full or archive node to listen for new blocks and transactions.
• Event Indexer: Service that parses transaction receipts and logs for emitted events matching subscriptions.
• Message Queue: Manages and prioritizes alert delivery (e.g., RabbitMQ, Kafka).
• Delivery Service: Handles the mechanics of sending via chosen channels (email servers, push services). Services like The Graph can be used to index complex event data.

Critical considerations for trustworthy notifications:

• Verification: The notification system must cryptographically verify the event originated on-chain to prevent spoofing.
• Rate Limiting: Prevents users from being spammed by high-frequency events.
• Opt-in/Opt-out: Users must have clear control over subscription management.
• Critical Alert Prioritization: Security events (e.g., a smart contract upgrade) should be prioritized over informational ones. Failure here can lead to alert fatigue or missed critical warnings.

Practical applications of user notifications:

• DeFi: Alert for liquidation risk, successful trade execution, or yield harvest opportunities.
• NFTs: Notify on bid activity, sale completion, or airdrop eligibility.
• Governance: Alert users when a new proposal is live or their vote is required.
• Security: Immediate alert for suspicious wallet activity (unexpected large transfer).
• Wallet Activity: Confirmations for sent transactions or incoming deposits. These transform passive holding into active portfolio management.

Automated monitoring of liquidity provision, lending positions, and yield farming strategies to prevent loss.

• Liquidation Risk: Alerts when collateralization ratios on protocols like Aave or Compound approach dangerous thresholds.
• Price Feed Updates: Notifications for oracle price updates that affect leveraged positions or synthetic assets.
• Reward Claiming: Reminders to harvest staking or liquidity mining rewards before they expire or diminish.

Keeping community members informed about participatory events in decentralized autonomous organizations.

• Proposal Alerts: Notifications when a new governance proposal is live for voting on Snapshot or on-chain.
• Voting Deadline Warnings: Reminders before a proposal's voting period ends.
• Delegation Updates: Alerts when a user's voting power delegate casts a vote or changes their stance.

Event-driven alerts for non-fungible token ecosystems, crucial for traders and collectors.

• Floor Price Changes: Notifications when the floor price of a tracked collection on a marketplace like Blur or OpenSea moves significantly.
• Listing & Sales: Alerts for new listings, sales, or bids on specific NFTs or from watched wallets.
• Airdrop & Allowlist Opportunities: Notifications for claimable airdrops or newly opened mint allowlists for held assets.

Proactive alerts for potentially malicious activity, serving as a critical line of defense.

• Smart Contract Exploits: Alerts when a protocol a user interacts with is flagged for a vulnerability or hack.
• Phishing & Impersonation: Warnings about fraudulent websites or social media accounts mimicking legitimate projects.
• Unusual Activity: Notifications for transaction patterns from a user's address that deviate from the norm, potentially indicating a compromised wallet.

Notifications for developers and node operators about changes to the underlying blockchain or protocol layers.

• Network Upgrades: Alerts for upcoming hard forks (e.g., Ethereum's Dencun upgrade) requiring client updates.
• RPC Endpoint Status: Notifications of downtime or degraded performance for node providers like Alchemy or Infura.
• Gas Fee Predictions: Alerts based on predictive models for optimal transaction batching during low-fee periods.

A major threat is notification spoofing, where malicious actors mimic legitimate alerts to trick users. Best practices to mitigate this include:

• Verifiable Sources: Notifications must be cryptographically verifiable (e.g., signed by a known service key) or delivered through a trusted, authenticated channel like the official wallet interface.
• Clear Context: Alerts should include the transaction hash, block number, and the specific protocol or dApp involved.
• No Embedded Links: Avoid clickable links in notifications that could lead to phishing sites; instruct users to navigate to the official interface manually.

Effective notifications must be understandable and prompt correct user action. This involves:

• Plain Language: Avoid raw contract calls; explain the action (e.g., 'Approving UNI spending' vs. 'call to approve(address,uint256)').
• Risk Severity Levels: Use standardized tiers (Info, Warning, Critical) with corresponding UI cues.
• Actionable Steps: For critical alerts, provide clear next steps (e.g., 'Revoke this approval at revoke.cash' or 'Contact support immediately').
• Rate Limiting: Avoid alert fatigue by bundling notifications or allowing user-defined thresholds for triggering alerts.

The security of the notification system depends on the integrity of its data sources. Key considerations are:

• Node Provider Reliability: Using a decentralized set of RPC providers or a highly available service to avoid missing events.
• Oracle Security: For price-based alerts (e.g., liquidation warnings), depend on decentralized oracles like Chainlink to prevent manipulation.
• Indexing Latency: The system must index chain data with low latency to ensure timely alerts, especially for time-sensitive actions like arbitrage or liquidation.

Monitoring user addresses for events creates significant privacy challenges. Best practices to address this include:

• Client-Side Monitoring: Where possible, perform monitoring locally in the user's wallet or client application to avoid exposing address lists to a central service.
• Data Minimization: Services should not store transaction histories longer than necessary for alerting.
• Transparency: Clearly disclose what data is monitored, how long it is retained, and whether it is shared with third parties. This is crucial for compliance with regulations like GDPR.

Notifications are triggered by specific state changes recorded on a blockchain. Common triggers include:

• Transaction confirmations (success/failure)
• Token transfers (incoming/outgoing)
• Smart contract events (e.g., a governance proposal is created)
• Wallet activity (new approvals, large withdrawals)
• Price or liquidity threshold breaches on a DEX

Alerts are delivered through various channels to reach users where they are:

• In-app/In-dApp notifications within a wallet or application interface.
• Push notifications via mobile apps using services like Firebase Cloud Messaging.
• Email alerts for less time-sensitive summaries or security events.
• SMS/text messages for critical security alerts (e.g., withdrawal confirmations).
• Webhook calls to external systems for developer integrations and automated workflows.

Specialized protocols and services power the notification stack:

• The Graph indexes blockchain data, allowing queries for specific events that can trigger notifications.
• EPNS (Ethereum Push Notification Service) and WalletConnect Notify are dedicated Web3 notification protocols.
• Oracle networks like Chainlink can provide external data (e.g., price feeds) as triggers.
• Indexers from nodes or RPC providers (Alchemy, Infura) offer custom event streaming APIs.

Integrating notifications requires a backend service that:

1. Listens to blockchain events via WebSocket connections or polling indexed data.
2. Filters & Processes events based on user-defined rules and subscriptions.
3. Formats & Routes the alert to the appropriate delivery channel (push, email, etc.). Tools like OpenZeppelin Defender provide automation frameworks to listen for and react to contract events.

Notifications enable proactive user experiences across DeFi, NFTs, and DAOs:

• DeFi: Alerts for liquidation risks, successful trades, or yield farming rewards.
• NFTs: Notifications for bid activity, sale completion, or new drops from followed collections.
• DAOs & Governance: Alerts for new proposals, voting periods, and execution results.
• Security: Immediate warnings for suspicious transactions or unexpected smart contract interactions.

Effective systems prioritize user consent and data minimization.

• Opt-in subscriptions: Users explicitly choose which alerts to receive.
• Decentralized identifiers (DIDs): Can be used to manage notification preferences without linking to a central identity.
• On-chain preferences: Storing subscription settings on-chain (e.g., via a smart contract) gives users full control and portability across frontends. The goal is to provide utility without spam or compromising wallet privacy.

The foundational on-chain mechanism that triggers notifications. Smart contracts emit structured events (or logs) when specific state changes occur, such as a token transfer or governance vote. These events are the primary data source that off-chain indexers and oracles listen for to generate alerts.

• Example: An ERC-20 Transfer(address from, address to, uint256 value) event.

The client-side interface where users receive and manage notifications. Modern crypto wallets (e.g., MetaMask, Rainbow) integrate notification SDKs to display alerts directly in their UI. This involves signature verification to prove ownership of the notification target address without paying gas.

• Critical for UX: Notifications appear natively alongside wallet balances and transaction history.

Mechanisms to protect users from unsolicited or malicious alerts. Key strategies include:

• Subscription Models: Users must opt-in to specific notification channels.
• Staking/Sybil Resistance: Channel creators may stake tokens to establish reputation.
• Rate Limiting: Capping the frequency of messages from a single source.
• User-Controlled Filters: Allowing users to mute channels or set granular preferences.