Logo
New RPC users get 35% off their first monthView the offer
dRPC
dRPC5 min read

dRPC Notices About Filtered Results: What They Mean for RPC Users

A practical guide to dRPC notices about filtered results, including why similar entries are omitted and how to repeat a search with the omitted results included.

TL;DR

dRPC notices about filtered results explain that a search or listing may hide entries that are very similar to the results already shown. The notice is a relevance and deduplication message, not an error. Users who need the omitted entries can usually repeat the search with the omitted results included, then verify endpoint details directly before use.

What a dRPC notice about filtered results means

A dRPC notice about filtered results appears when a search, directory view, or provider listing decides that some entries are too similar to the results already displayed. The notice typically states that, in order to show the most relevant results, some entries very similar to the ones already shown have been omitted.

This is a presentation and relevance behavior, not a connectivity failure. The notice does not mean that dRPC endpoints are unavailable or that a chain is unsupported. It means the interface has collapsed near-duplicate or closely related entries so the visible list is easier to scan.

  • The notice is informational and usually appears alongside search results or provider listings.
  • Omitted entries are described as very similar to entries already displayed.
  • The notice does not confirm or deny the health of any specific RPC endpoint.
  • Filtering behavior can vary by interface, query, and time.

Why similar RPC entries are omitted

RPC directories and provider search pages often contain many entries that differ only slightly, such as regional variants, load-balanced hosts, or multiple endpoints for the same network. Showing every near-duplicate can bury the most useful result. Filtering reduces repetition and keeps the first page focused.

For dRPC specifically, a filtered-results notice may appear when a query matches several closely related chain names, endpoint labels, or provider descriptions. The exact filtering logic is controlled by the interface showing the notice and may change over time.

  • Near-duplicate endpoint labels or chain names may be grouped.
  • Regional or load-balanced variants may be treated as similar entries.
  • The visible result set is intended to be the most relevant subset, not a complete inventory.
  • Filtering rules are interface-specific and may not be documented in detail.

How to repeat a search with omitted results included

When a notice about filtered results appears, look for a control or text link that offers to repeat the search with the omitted results included. Selecting it usually re-runs the same query without the similarity filter, so you can review the entries that were hidden.

If no such control is available, adjust the query to be more specific, for example by adding a chain name, network identifier, or endpoint label. More specific queries often reduce the need for filtering and surface the entry you need.

  • Use the repeat-search option when it is offered by the interface.
  • Make the query more specific if the repeat option is unavailable.
  • Compare omitted entries by chain, network, and endpoint host before choosing one.
  • Re-check the notice after changing the query, because filtering may apply again.

Verifying dRPC endpoints after revealing omitted results

Once omitted results are visible, verify each candidate endpoint directly rather than relying on the listing alone. Confirm the chain ID, the endpoint host, and whether the endpoint is intended for the network you plan to use. Raw endpoint examples are shown below in plain text for reference only.

Endpoint availability and supported methods can change. Treat any listed endpoint as a candidate to test, not as a guarantee. Use your own validation steps, such as a basic chain ID request, before wiring an endpoint into production code.

  • Confirm the chain ID matches the network you intend to use.
  • Check whether the endpoint is public, authenticated, or restricted.
  • Test with a minimal request before relying on the endpoint.
  • Do not assume that a visible or omitted listing implies uptime or performance.
Example endpoint format (plain text, not a link):
https://lb.drpc.org/ogrpc?network=ethereum&dkey=YOUR_KEY

Example chain ID check with curl:
curl -X POST https://lb.drpc.org/ogrpc?network=ethereum&dkey=YOUR_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

Common questions about dRPC filtered-results notices

Users often encounter the filtered-results notice while searching for dRPC endpoints, reading a dRPC RPC review, or comparing dRPC pricing and API details. The notice is separate from account, billing, or login behavior. It concerns how search results are displayed, not how the provider operates.

If you are looking for a specific chain or endpoint and the notice keeps appearing, combine the repeat-search option with a narrower query. Record the endpoint details you find, then validate them independently. This keeps the filtered-results notice from being mistaken for a missing or broken endpoint.

  • The notice is about result display, not account access or billing.
  • Repeat the search with omitted results included when the option is available.
  • Use narrower queries to reduce similarity filtering.
  • Validate any endpoint before use, regardless of how it was found.

Never Worry about Infrastructure Again

OnFinality takes away the heavy lifting of DevOps so you can build smarter and faster.

Get Started