RPC Subscription
Abbreviation: RPC
Pronunciation: R-P-C sub-SKRIP-shun
Also known as: RPC PubSub Subscription, Blockchain RPC Subscription, RPC
Definition
RPC Subscription is a persistent or long-lived RPC registration through which a client receives notifications when selected blockchain or node conditions change. It pushes updates and reduces polling, but delivery can be interrupted, duplicated, delayed, or provider-specific and therefore should not be the sole source of authoritative state. A production implementation should record subscription IDs and filters, reconnect with backoff, detect gaps, resynchronize through queries, choose commitment or finality carefully, bound local queues, and unsubscribe cleanly. Key risks include silent disconnects, missed events, duplicate notifications, unsupported methods, inconsistent provider semantics, memory leaks, and acting on a notification before the required finality level.
Overview
RPC Subscription is a persistent or long-lived RPC registration through which a client receives notifications when selected blockchain or node conditions change. It pushes updates and reduces polling, but delivery can be interrupted, duplicated, delayed, or provider-specific and therefore should not be the sole source of authoritative state.
Key risks include silent disconnects, missed events, duplicate notifications, unsupported methods, inconsistent provider semantics, memory leaks, and acting on a notification before the required finality level. Replay of RPC Subscription should preserve original identifiers and timestamps so historical processing cannot masquerade as a new event.
A production implementation should record subscription IDs and filters, reconnect with backoff, detect gaps, resynchronize through queries, choose commitment or finality carefully, bound local queues, and unsubscribe cleanly. The RPC Subscription path should preserve ordering and duplicate evidence so delayed delivery cannot silently overwrite a newer state.
Useful measures include active subscriptions, disconnect rate, reconnect time, notification lag, detected gaps, duplicate events, and successful query-based resynchronization. RPC Subscription is closely connected to Ethereum JSON-RPC, Signature Subscription, and RPC Monitoring. Recovery for RPC Subscription should combine replay controls with an authoritative status check rather than trusting delivery history alone.
A receiver should treat transport acknowledgement and successful downstream processing as separate states for RPC Subscription. An RPC Subscription handler should acknowledge only after durable receipt when the provider’s retry contract depends on the response.
Business actions triggered by RPC Subscription should be idempotent and should verify the current object state before fulfillment or accounting updates. Monitoring for RPC Subscription should track delivery age, signature failures, duplicate rate, retry exhaustion, and unresolved business events.
Key Takeaway
Record subscription IDs and filters, reconnect with backoff, detect gaps, resynchronize through queries, choose commitment or finality carefully, bound local queues, and unsubscribe cleanly.
Sources
- Solana RPC WebSocket Methods — Solana Foundation (2026-08-03)
- JSON-RPC API — Ethereum Foundation (2026-08-03)
- Reactive Streams Specification — Reactive Streams Initiative (2026-08-03)