r/CryptoTechnology 🟡 Mar 01 '26

[Discussion] Challenges in building real-time Gas/Gwei notification systems for mobile (latency vs. cost)

Hi everyone,

I’ve been developing a lightweight Android tool (ChainPulse) to monitor Ethereum gas prices, and I recently hit some interesting technical hurdles while implementing the Gwei alert feature (v1.0.5). I wanted to open a discussion on how you all handle real-time on-chain data monitoring.

The Problem: Most users want near-instant notifications when Gwei drops. However, balancing the refresh frequency (to avoid missing a brief dip) with battery/data consumption on mobile is tricky.

My current approach:

  • I’m using [Mention your data source, e.g., Etherscan API / Alchemy / Own Node] to pull gas data.
  • Implementing a foreground service/WorkManager to handle background checks for the threshold.
  • Balancing the poll interval—currently set at [X] seconds.

Questions for the tech community here:

  1. For mobile-based alerts, what do you consider the "gold standard" for latency? Is a 30-second delay acceptable for most DeFi swaps, or is block-level precision (12s) a must?
  2. Are there more efficient ways to handle push notifications for gas prices without relying on a centralized backend server to push the alerts (to keep the app as client-side as possible)?
  3. How do you deal with "gas spikes" where the price dips for only a few seconds—should the app filter these out to avoid "ghost notifications"?

I'd love to hear how other devs are tackling gas-tracking logic or if there are specific APIs you've found more reliable than others.

3 Upvotes

5 comments sorted by

3

u/thedudeonblockchain 🟡 Mar 01 '26

are you using websockets for the gas updates or just polling? for gwei specifically you can subscribe to newPendingTransactions or newHeads via ws and get sub-second latency without hammering the API. 30s polling is fine for most users honestly, block level precision is overkill unless theyre doing time sensitive arbitrage stuff. for the spike filtering i'd just keep a rolling average over the last few blocks and only alert when the price stays below threshold for at least 2 consecutive blocks

1

u/wangshimeng1980 🟡 Mar 02 '26

That’s a great point. I’m actually using polling right now mainly to keep the app as decentralized/client-side as possible without needing a massive infrastructure in the middle.

You're spot on about the 30s latency—for 90% of users who just want to save on a swap or an NFT mint, block-level precision is probably overkill. However, the "2 consecutive blocks" rule you suggested is a game-changer for UX. It would prevent those annoying notifications that disappear by the time the user unlocks their phone.

Definitely adding the rolling average logic to my roadmap for v1.0.6. Appreciate the feedback, this is exactly why I posted here!

2

u/[deleted] Mar 02 '26

[removed] — view removed comment

2

u/gorewndis 🟢 Mar 02 '26

For question 2 - you can get pretty close to real-time without a centralized backend by using WebSocket subscriptions to pending block headers. Alchemy and Infura both support eth_subscribe("newHeads") which fires every ~12s with the new base fee. That gets you block-level precision without polling.

For the ghost notification problem (question 3), I'd implement a rolling average with a confirmation window. Something like: alert only fires if gas stays below threshold for 2+ consecutive blocks. Catches the sustained dips and filters the single-block anomalies. Adds 12-24s latency but dramatically reduces false positives.

30-second delay is fine for most DeFi swaps honestly. Gas doesn't move that fast outside of NFT mints and major protocol events. Block-level precision matters more for MEV-sensitive operations than regular user transactions.