dRPC

• Name: dRPC
• URL: https://drpc.org/
• Category: blockchain RPC infrastructure / routing middleware / managed and self-hosted chain-access company
• Tags: ethereum-ecosystem solana-ecosystem
• Summary: dRPC belongs in companies/ because the durable dependency is a named operator packaging NodeCloud, NodeCore, and NodeCraft into one chain-access control plane. The useful question is not just which RPC URL do I hit? but who decides auth, rate limits, upstream selection, failover policy, region topology, supported-network inventory, managed analytics, and the escape-hatch boundary between self-hosted routing and the hosted vendor shell.
• What it does:
  • Sells managed multichain RPC access for dapps and chains, with the homepage and chain directory framing dRPC as a broad chain-access vendor rather than a single-network endpoint provider
  • Publishes NodeCore as an open-source RPC load balancer that can front JSON-RPC, WebSocket, REST, Tendermint / CometBFT-style, and other blockchain API shapes across many chain families
  • Packages NodeCraft as a tailored services layer for custom routing, fallback, observability, compliance, and regional optimization on top of the same routing stack
  • Maintains a public chain directory that exposes current support breadth and per-network flags such as archive, MEV, premium, or public availability
  • Offers auth, access-control, and integration surfaces that let teams keep part of the stack self-hosted while still coupling to dRPC-managed analytics, keying, or support workflows
• Key claims:
  • The homepage positions dRPC as AI-powered RPC infrastructure, advertises 130+ chains across 220+ networks, 8 geo-distributed clusters, 60+ upstream RPC providers, and 4B+ daily requests serving 4000+ dapps
  • The live chain directory currently lists 134 chains across 223 networks and exposes chain-by-chain feature flags such as archive, MEV, premium, and public access, which is a stronger operator signal than generic multichain marketing
  • The NodeCore README describes a fault-tolerant, API-agnostic RPC load balancer with intelligent upstream scoring, hedging, retries, caching, rate limiting, quorum verification, scoped auth controls, Prometheus metrics, and a public gRPC API
  • NodeCore also documents Tor hidden-service deployment and deploy anywhere posture, which makes the open-source escape hatch real, but the README still explicitly notes integration paths back into DRPC for centralized key management and analytics
  • That split is exactly why the company note matters: even when part of the routing stack is open source, the practical leverage can still collect around the hosted service shell, support, chain metadata stewardship, managed credentials, and the easiest default operating path
• Whitepaper: No classic dRPC whitepaper or litepaper is the important artifact here. The clearest current primary materials are the official homepage, live chain directory, and NodeCore repository / README collected alongside the earlier source bundle in ../whitepapers/drpc-primary-sources-2026-04-25.md.
• Sources:
  • https://drpc.org/
  • https://drpc.org/chainlist
  • https://github.com/drpcorg
  • https://github.com/drpcorg/nodecore
  • https://raw.githubusercontent.com/drpcorg/nodecore/main/README.md

Internal linkages

• Alias note for legacy project placement: drpc.
• Strong operator-platform comparisons: alchemy, quicknode, chainstack, and tenderly.
• Useful control-surface contrast when the question is builder-owned routing instead of vendor packaging: self-hosted NodeCore deployments and other operator-run RPC routers.

Protocol / company boundary

• dRPC is better kept as an entity note than as a standalone projects/ note because the practical dependency is a named company packaging hosted endpoints, routing logic, support, chain inventory, auth, and managed workflow rather than a neutral protocol primitive with its own durable governance surface.
• The analytically useful split is not protocol versus protocol. It is self-hosted NodeCore escape hatch versus company-run NodeCloud / NodeCraft operating shell.
• Keep [[../projects/drpc]] only as an alias so legacy links keep resolving without pretending dRPC is a separable protocol layer.

Control surface

• Practical leverage sits in credentials, rate limits, upstream-provider selection, retry and hedging policy, regional routing, chain-support admission, premium-versus-public network exposure, and whether a team keeps analytics and operational visibility inside the dRPC-managed shell.

• The open-source story matters, but it does not erase the company boundary. Many teams will still inherit dRPC’s hosted defaults, support workflow, chain metadata, and commercial packaging before they self-host anything.

• Read dRPC here as an operator-shaped chain-access company first and as just another RPC endpoint second.

• Last reviewed: 2026-08-09 UTC