refactor: prevent future RpcError variants from breaking downstream matches

CHANGELOG.md

@@ -49,6 +49,17 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   (`current.saturating_add(chunk_size - 1).min(end)` per chunk,
   advancing via `to_block.checked_add(1)` so the loop breaks when
   the chunk ends at `u64::MAX`). Closes #36.
+- Exhaustive `match` arms over `RpcError` written in a downstream crate
+  must now include a wildcard (`_ => ...`) fallback. The enum is now
+  marked `#[non_exhaustive]`, matching the discipline already in place
+  on the crate's other public provider-surface types (`RpcConfig`,
+  `ChainEndpoint`) — so future operational variants (e.g. the
+  `ConflictingRateLimit` variant added in this release, or further
+  per-endpoint health/quota signals) can be added without forcing
+  another breaking change at this boundary. Consumers that already
+  default-handle unknown variants are unaffected; consumers that match
+  only the variants they care about and ignore the rest gain stability
+  across future variant additions. Closes #62.
 
 ### Added
 

src/errors/rpc.rs

@@ -80,7 +80,18 @@ use alloy_transport::TransportError;
 /// };
 /// println!("Error: {}", error);
 /// ```
+///
+/// # Stability
+///
+/// This enum is marked `#[non_exhaustive]`. New variants may be added in
+/// future releases without a major-version bump, so downstream `match`
+/// arms over `RpcError` from another crate must include a wildcard
+/// (`_ => ...`) arm. This mirrors the discipline already applied to the
+/// crate's other public configuration types (`RpcConfig`,
+/// `ChainEndpoint`) so that adding a new operational error variant does
+/// not force every consumer to recompile.
 #[derive(Debug, thiserror::Error)]
+#[non_exhaustive]
 pub enum RpcError {
     /// Failed to fetch logs from the blockchain.
     ///