There is no hard Anther-level limit on the number of concurrent block or operation streams, but developers should treat streams as RPC-backed polling loops, not as an unlimited firehose.

StreamBlocks starts one goroutine and emits blocks on a buffered channel of 10. StreamOperations also starts one goroutine and emits operations on a buffered channel of 100. Both poll dynamic global properties, walk blocks sequentially, and respect context.Context cancellation.

The main practical limits are node/API throughput and duplicated work. StreamOperations fetches all operations for each block with get_ops_in_block, then applies the type filter client-side, so heavy indexers should avoid starting many overlapping operation streams for the same range. Prefer one canonical stream per cursor/range, then fan out internally with your own bounded worker pool.

For catch-up indexing, GetBlockRange is often a better primitive, but it caps requests at 1000 blocks per call. For live indexing persist your last processed block, always drain the error channel, and cancel streams with context deadlines or shutdown contexts.

The client’s node rotation state is mutex-protected, so shared clients are usable, but multiple heavy streams will still multiply RPC load. For very large indexers, shard intentionally by block range or operation type and rate-limit against your node pool.