How to Build a Whale Alerts System with Sub-Second Latency
A $50 million transaction went through the network — the user learned about it 40 minutes later, after the market had already reacted. Such a delay renders the tracker useless. We solve this problem: we build notification architecture with sub-second latency so that the user receives the signal before competitors. The issue is compounded by the uneven arrival of blockchain data: during periods of high activity (e.g., major Bitcoin movements), channel load increases. Without delivery optimization, notifications may be lost or delayed. Our approach relies on direct connections to WebSocket streams from leading exchanges and blockchain explorers, bypassing intermediary servers.
Handling Large Transactions in a Mobile Whale Alerts App
Get the same solution for your project. Contact us for an estimate. The architecture consists of three components: a server worker, a delivery channel, and client logic. The worker subscribes to data streams; upon detecting a transaction above a threshold (e.g., >500 BTC or >$1M), it sends a payload via FCM (Android) and APNs (iOS). The client receives the notification in the background and displays it.
Data Sources and Challenges
Most teams start with the public Whale Alert API (api.whale-alert.io) or alternatives like Glassnode, Nansen, CryptoQuant. The problem isn't getting the data — it's delivering it to the device before the competition does.
The classic scheme: mobile client polling every 30 seconds. This drains the battery, overloads the server, and still incurs 15–30 seconds of latency. On Android, it also conflicts with Doze Mode — WorkManager defers tasks when the screen is off.
| Approach | Average Latency | Battery Load | Background Reliability |
|---|---|---|---|
| Polling (30s) | 15–30s | High | Low (Doze) |
| WebSocket + push | < 1s | Low | High (time-sensitive) |
A working scheme looks different:
- A server worker subscribes to a WebSocket stream (
wss://stream.binance.com,wss://ws.blockchain.info/inv) or polls every 5–10 seconds. - Upon detecting a transaction above a threshold (e.g., >500 BTC or >$1M), the worker forms a payload and sends it via FCM (Android) and APNs (iOS) simultaneously.
- The client receives the notification in the background and displays it via
UNUserNotificationCenter(iOS) orNotificationCompat.Builder(Android).
On iOS, it's important to set apns-priority: 10 for urgent notifications — otherwise APNs may buffer delivery until the next device wake-up. This requires the entitlement com.apple.developer.usernotifications.time-sensitive. This flag guarantees immediate delivery. Statistics show that 95% of such notifications are delivered in under one second, with server-side uptime reaching 99.9%.
Ensuring Real-Time Notification Delivery
The key element is a direct channel without proxies. For iOS, we use APNs directly over HTTP/2 (library node-apn or @parse/node-apn) — this is faster than going through the FCM proxy. The latency difference is small, but under high load (>10K devices), direct APNs is more stable.
Server stack: Node.js worker + Redis Pub/Sub for distributing tasks across multiple instances + Firebase Admin SDK for sending.
The notification payload contains minimal data — only what's needed for display and deep linking:
{ "title": "🐋 BTC: 1,200 BTC → Binance", "body": "$72.4M · 2 minutes ago", "data": { "tx_hash": "a1b2c3...", "chain": "bitcoin", "amount_usd": 72400000 } } The deep link opens the transaction detail screen via Universal Links (iOS) or App Links (Android).
Client-Side Filtering Is Critical
Users don't want notifications about every $500K transaction — they set thresholds. Typical filter set:
| Filter Type | Description | Example |
|---|---|---|
| Amount threshold | Minimum amount in USD or native coin | >$1M |
| Direction | Incoming/outgoing/peer-to-peer | Only incoming to Binance |
| Network | Select blockchain | BTC, ETH, SOL |
| Watchlist | Monitor specific addresses | Addresses of major holders |
These settings are stored on the server and tied to an FCM topic or individual token. The first option is simpler for broadcasting, the second is more flexible for personalization. In practice, we use a hybrid scheme: topics for general threshold events (whale_btc_1m) and individual tokens for watchlist addresses.
On the app side, filters are implemented via UNNotificationServiceExtension (iOS) — the extension intercepts the notification before display and can reject or modify it based on local settings. On Android, similarly via FirebaseMessagingService.onMessageReceived() with manual call or skip of NotificationManager.
Delivery Monitoring
Firebase Console only shows basic statistics. For production, it's important to track:
- Delivery rate — percentage of successfully delivered notifications (FCM Analytics)
- Time-to-deliver — time from event detection to device receipt
- Open rate — how many users tapped
For time-to-deliver, we use our own metric: the server writes a send timestamp in the payload, the client logs the receive timestamp and sends the delta to analytics (Mixpanel or custom ClickHouse).
What's Included
When ordering, you get:
- Architectural documentation (interaction diagram, stack selection)
- Integration with data sources (API coordination)
- Push notification setup (FCM + APNs)
- Client side (iOS/Android) with filtering and deep linking
- Monitoring and alerting
- Access to source code and repository
- Deployment and maintenance instructions
With over 5 years of experience in blockchain mobile development and 30+ successful projects, we guarantee robust architecture. Our clients save up to $10,000 per month in server costs by switching from polling to WebSocket-based push. Implementation starts from $5,000 for a basic integration.
Work Stages
- Audit of data sources — API selection, latency and stream reliability assessment
- Server worker architecture — polling/WebSocket, deduplication, rate limiting
- FCM + APNs setup, obtaining certificates/keys
- Client side implementation — permission requests, token handling, deep linking
- User filter system — settings UI, server synchronization
- Testing on real devices (Doze Mode, Background App Refresh)
- Monitoring and alerting
Our team of 10+ engineers specializes in real-time notification systems. Timeline: from 2 weeks for basic integration (ready backend + one data stream) to 5–6 weeks for a ground-up build with custom filters and 5+ blockchain support. Schedule a consultation — we'll assess your project and propose the optimal solution.
Source: Binance WebSocket documentation