Why does polling balance and nonce on every block get expensive on fast chains?
Last updated: August 25, 2026
If your app calls eth_getBalance or eth_getTransactionCount once per block to track an account's balance or nonce, the cost of that polling scales directly with how fast the chain produces blocks. The code doesn't change, but a chain with a much shorter block time drives far more calls per second for the exact same polling loop.
Why this adds up
Robinhood Chain, for example, produces new blocks roughly every 100 milliseconds, or about 10 blocks per second. A loop that calls eth_getBalance and eth_getTransactionCount on every new block issues about 10 calls per second per method, per address being tracked. Each call costs 20 compute units, so tracking even a handful of addresses this way adds up quickly, and the cost multiplies further with every additional address or method polled per block.
How to reduce this
Track the nonce locally instead of polling it. Increment your local nonce when you send a transaction, and only call
eth_getTransactionCountto resync when you hit an error, such as a nonce-too-low response.Update balances on a trigger instead of on every block. Refresh a balance when you observe a relevant transaction or log, for example through a WebSocket subscription, or on demand when your app actually needs the current value, rather than on every new block.
If polling is still required, use a fixed interval instead of every block, and batch requests where possible to cut down on round trips.
WebSocket subscriptions such as newHeads are billed separately, based on the data delivered rather than connection time, and an idle connection with no events doesn't accrue any cost. On a fast-block chain, using a WebSocket subscription to trigger the patterns above is typically far cheaper than polling every block over HTTP.