GRC-005: Dispatch - An Experimental JSON-RPC Data Service on Horizon

Governance & GIPs Graph Request for Comment (GRC)
1

GRC-005: Dispatch — An Experimental JSON-RPC Data Service on Horizon

Stage: RFC (Request for Comment)
GRC: 005
Authors: @cargopete (Petko Pavlovski)

Summary

This GRC introduces Dispatch — a community-built JSON-RPC data service running on The Graph’s Horizon framework. The contract is deployed on Arbitrum One, the subgraph is live, and the first provider is serving real traffic with a fully working payment loop.

This is an independent community experiment, not an official Graph Foundation or Edge & Node initiative. The goal of this GRC is to share the design openly, get feedback on the core mechanisms, and explore whether the Graph community wants to develop this direction further.

Background: why RPC?

Every dApp on Earth quietly depends on Alchemy or Infura. When your frontend calls eth_getBalance, that request almost certainly hits a centralised API run by a handful of companies. They can go down, rate-limit you, reprice overnight, or — in the extreme — be compelled to censor specific addresses.

The Graph has done a remarkable job decentralising subgraph data. But the most fundamental piece of Ethereum infrastructure — plain JSON-RPC — has stayed centralised. Pocket Network and Lava have tried to address this with their own token networks. The question this experiment asks is: can The Graph’s existing infrastructure — Horizon staking, GraphTally payments, the indexer ecosystem — support a decentralised RPC market without a new token or new payment primitives?

The answer, as far as this experiment has demonstrated: yes.

The core idea

The Graph’s Horizon framework makes it straightforward to define new data services. A data service is a contract that implements a standard interface (IDataService): providers register their stake, offer a service, and get paid per unit of work via GraphTally micropayments. The SubgraphService uses this for subgraph indexing. Dispatch uses the same infrastructure for JSON-RPC.

The insight is that Horizon already has all the pieces: HorizonStaking manages stake and slashing authority. GraphTallyCollector handles per-request micropayments. PaymentsEscrow holds consumer funds. What was missing was one layer — a DataService implementation that speaks JSON-RPC rather than subgraph POIs.

RPCDataService is that layer. From a staking, payment, and GRT flow perspective, it is nearly identical to SubgraphService.

How it works

Providers

A provider is a Graph indexer who runs an Ethereum node (Geth, Erigon, Reth, or similar) alongside the dispatch-service binary. They stake at least 10,000 GRT via a Horizon provision, register with RPCDataService, then call startService for each chain and capability tier they want to serve.

Capability tiers reflect the actual infrastructure differences between node types:

  • Standard — any full node: recent chain state (~128 blocks), all standard RPC methods
  • Archive — archive node: full historical state at any block number
  • Debug/Trace — debug APIs enabled: debug_traceTransaction, trace_block, etc.

A provider running one archive node can register for both Standard and Archive on the same chain. Their stake is shared across all chains they serve — there is no per-chain stake splitting.

Consumers

Consumers interact through two paths:

Via the gateway (easy path): A single HTTP endpoint. The gateway handles provider discovery, quality scoring, payment signing, and routing. The consumer needs no configuration beyond the endpoint URL and a GRT deposit in escrow. This path trusts the gateway to route honestly.

Via the consumer SDK (trustless path): The SDK discovers providers from the subgraph, signs TAP receipts with the consumer’s own key, and dispatches requests directly. No third party can forge payments on the consumer’s behalf. The consumer pays per request directly to the provider they choose.

Payments

Payments use GraphTally (TAP v2) — the same micropayment primitive that subgraph queries use today.

The flow is:

  1. Consumers deposit GRT into PaymentsEscrow before making requests.
  2. For each request, the gateway signs a small EIP-712 receipt — essentially a cheque for a specific amount of GRT made out to a specific provider. This receipt travels alongside the JSON-RPC request.
  3. The provider validates the receipt signature before serving the request. Invalid or forged receipts are rejected.
  4. Receipts accumulate off-chain. Periodically (every 60 seconds), they are aggregated into a single signed voucher (a RAV — Receipt Aggregate Voucher) with a cumulative total value.
  5. The provider submits the RAV on-chain via RPCDataService.collect(). GRT flows from the consumer’s escrow to the provider’s wallet.

The cumulative RAV value is monotonically increasing — it always represents the running total, never resets. This means the provider can batch partial receipts safely, and there is no window where previously-claimed GRT can be disputed.

Stake-backed accountability

When a provider collects fees, RPCDataService locks five times the collected amount in their stake for the duration of the thawing period (minimum 14 days). This is the same 5:1 stake-to-fees ratio as SubgraphService.

The mechanism: a provider with 10,000 GRT can collect at most 2,000 GRT before their entire provision is tied up in stake claims. This creates a meaningful cost-of-fraud: a provider who serves bad responses and gets caught loses far more in locked stake than they gain from the fraudulent fees.

The verification problem

This is the genuinely hard design question, and it is worth being direct about it.

For subgraphs, The Graph uses Proof of Indexing — a deterministic hash over the indexed state that lets the network detect disagreements between providers. JSON-RPC has no equivalent. Most RPC responses cannot be efficiently proved correct on-chain:

  • eth_call results require full EVM re-execution to verify
  • eth_blockNumber and similar methods depend on which block a node has synced to — two honest nodes may honestly disagree
  • eth_estimateGas is explicitly non-deterministic by design

Dispatch currently handles this with two mechanisms:

Attestations. Every response carries a provider-signed cryptographic commitment to the (chain, method, params, result) tuple. This creates a tamper-evident audit trail — a consumer can prove that a provider claimed a specific response. Providers that omit or forge attestations are penalised in quality scoring and receive less traffic.

Quorum. For deterministic methods (eth_call, eth_getLogs, eth_getBalance, etc.), the gateway queries multiple providers and takes the majority result. A provider in the minority is penalised. This makes systematic lying expensive — you need to control a majority of the selected providers.

What these two mechanisms do not give you is cryptographic proof of correctness. They make dishonesty unprofitable and detectable, but cannot eliminate it. Dispatch is currently economically secure, not cryptographically secure. This is the same position as Pocket Network and Lava today.

A stronger model exists for a subset of methods: EIP-1186 Merkle-Patricia Trie proofs. For methods like eth_getBalance, eth_getStorageAt, and eth_getCode, responses can be verified against Ethereum’s state root without EVM re-execution. This would enable on-chain fraud proofs and genuine slashing. It requires a trusted block header oracle and an on-chain MPT verifier — both exist as building blocks but have not been integrated. The slash() function on RPCDataService currently reverts unconditionally. Slashing is a clear future direction, not a current capability.

What is and isn’t implemented

Working:

  • RPCDataService contract on Arbitrum One
  • dispatch-service and dispatch-gateway Rust binaries
  • Full TAP payment loop: receipts → RAV aggregation → on-chain collect() → GRT to provider
  • Dynamic provider discovery via subgraph
  • Quality scoring, geographic routing, quorum dispatch, rate limiting
  • Consumer SDK and indexer agent npm packages

Not implemented:

  • Slashing — slash() reverts. There is no mechanism to penalise a provider on-chain for serving wrong responses.
  • Permissionless chain registration — chains are added by the contract owner. A bond-based permissionless model is a natural future step but is not built.
  • GRT issuance rewards — providers earn query fees only. GRT issuance would require Graph governance approval.

Implementation status in brief:

Component Status
RPCDataService contract :white_check_mark: Live on Arbitrum One
Subgraph :white_check_mark: Live on The Graph Studio
npm packages :white_check_mark: Published (@lodestar-dispatch/consumer-sdk, @lodestar-dispatch/indexer-agent)
Active providers :white_check_mark: 1 — https://rpc.cargopete.com (Arbitrum One, Standard + Archive)
Full payment loop :white_check_mark: Working end-to-end — receipts → RAVs every 60s → collect() every hour → GRT to provider
Dynamic provider discovery :white_check_mark: Working — gateway polls subgraph every 60s
Slashing :cross_mark: Not implemented — slash() reverts

What this means for the Graph

Nothing in the existing network changes. SubgraphService, HorizonStaking, GraphTallyCollector, and PaymentsEscrow are all reused unchanged. Existing indexers and delegators are unaffected.

Existing Graph indexers are the natural first movers. If you are already staking GRT and running an Ethereum node, the barrier to becoming a Dispatch provider is one configuration file and a registration transaction.

The payment primitives are already battle-tested. TAP receipts, RAV aggregation, and GraphTallyCollector are the same primitives the Subgraph network uses in production today.

The most significant open question is governance, not engineering. The contract parameters — minimum stake, thawing period, chain allowlist, CU pricing — are currently owner-controlled. If this grows, the community needs to decide how governance of those parameters should work.

Open questions

These are the design questions worth the community’s attention:

On verification: Is the current economic model (attestations + quorum) sufficient to bootstrap a real market? Or is the absence of cryptographic guarantees a fundamental barrier to adoption? What would it take to add EIP-1186 proof verification and on-chain slashing?

On pricing: The current default is roughly $10.80 per million requests. What is the right pricing model across method types and capability tiers? Should archive queries carry a different base price than standard queries at the protocol level?

On the gateway’s trust role: The managed gateway path requires trusting a centralised operator for routing. Is this an acceptable tradeoff for ease of use, or should the trustless SDK path be the primary user interface? How should the network evolve so the gateway becomes less necessary?

On chain addition: Owner-controlled chain allowlists are safe but not permissionless. A bond-based model (where anyone can add a chain by locking GRT) would be more aligned with The Graph’s values. What is the right threshold, and who governs it?

On minimum stake: 10,000 GRT minimum provision with a 5:1 stake-to-fees ratio means a provider can collect at most 2,000 GRT before their full provision is locked. Is this enough economic skin-in-the-game given that slashing doesn’t exist yet?

Deployed addresses (Arbitrum One, chain ID 42161)

Contract Address
HorizonStaking 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03
GraphPayments 0xb98a3D452E43e40C70F3c0B03C5c7B56A8B3b8CA
PaymentsEscrow 0xf6Fcc27aAf1fcD8B254498c9794451d82afC673E
GraphTallyCollector 0x8f69F5C07477Ac46FBc491B1E6D91E2bb0111A9e
RPCDataService 0xA983b18B8291F0c317Ba4Fe0dc0f7cc9373AF078

Subgraph: https://api.studio.thegraph.com/query/1747796/rpc-network/v0.2.0

GitHub: https://github.com/cargopete/dispatch

3 Likes
GRC-006: Mainline — A Firehose Data Service on Horizon
2

Dispatch (Graph Horizon JSON-RPC Data Service MVP) vs. dRPC: Gap Analysis & Roadmap

Framing

Dispatch is an MVP, community-built decentralised JSON-RPC data service for The Graph’s Horizon framework — aligned with the “Experimental JSON-RPC Data Service” Q3 2026 window of The Graph’s 2026 Technical Roadmap and stacked alongside the SubgraphService (GIP-0068) and the planned Substreams data service. dRPC, by contrast, is a four-year-old production decentralised RPC platform (Dproxy gateway + a fork of Dshackle on each provider) supporting 100+ chains across 190+ networks and 8 geo clusters via a network of 50–60+ independent node operators, with paid SLAs up to 99.99% uptime and 5,000 RPS, billed at a flat $6/M requests. This analysis maps Dispatch’s MVP capabilities to dRPC’s production benchmark dimension-by-dimension, then prioritises what Dispatch needs to graduate into a dRPC-class production data service running natively on Horizon — letting Graph indexers monetise JSON-RPC alongside subgraphs and substreams.

Gap Matrix

Severity legend for production parity on Horizon: MUST = blocker for any production rollout; SHOULD = required for credible commercial adoption; NICE = differentiator or post-GA.

Capability Dimension Dispatch MVP dRPC.org Production Gap / Delta Severity
Chain coverage breadth 10 EVM chains: ETH, Arbitrum One, Optimism, Base, Polygon, BNB, Avalanche, zkSync Era, Linea, Scroll 100+ chains, 190+ networks; adds 2–3 chains/month; supports EVM, Solana, Bitcoin, Cosmos Hub, TRON, Starknet, Hyperliquid, Sui, etc. ~10× chain gap; no non-EVM (Solana/Bitcoin/Cosmos/TON) MUST (Solana, Bitcoin) / SHOULD (rest)
Archive / trace / debug coverage Per-method tier detection with archive routing via block-param inspection; Standard / Archive / Debug / WebSocket capability tiers Full debug_* and trace_* (callTracer, prestateTracer, vmTrace, replayTransaction, traceFilter, traceCallMany) on paid tier; archive same price as full nodes Method coverage parity exists conceptually but unproven at scale; no published support matrix per chain SHOULD
Method support — MEV / private tx Not implemented in MVP MEV-protected endpoints on Ethereum, Base, BSC, Polygon, Arbitrum, Solana (premium, from $1); Solana stake-weighted QoS; no documented native eth_sendBundle, but mev+ endpoints route eth_sendRawTransaction/eth_sendTransaction through private relays No MEV story at all in Dispatch SHOULD
WebSocket subscriptions Full WebSocket subscription proxy eth_subscribe (newHeads, logs), Solana accountSubscribe/programSubscribe/logsSubscribe/blockSubscribe; not newPendingTransactions Likely on par for EVM; no Solana subs (because no Solana) SHOULD
Streaming / gRPC interfaces None (HTTP + WS JSON-RPC only) Yellowstone Geyser gRPC for Solana streaming (accounts/tx/blocks/slots); Dshackle exposes gRPC natively to dRPC’s gateway No streaming / no gRPC transport NICE (HTTP+WS suffice for first GA)
Sticky sessions / stateful filter methods Not specified; gateway dispatches to 3 providers concurrently for all methods Explicit “sticky session” strategy for filter method-group (eth_newFilter, eth_getFilterChanges, eth_getFilterLogs); single-provider routing without retries; provider opts-in via method-groups: enabled: - filter label Dispatch has no sticky-session affinity model — running 3-way quorum on filter methods will return inconsistent IDs MUST
Provider network size & geographic distribution MVP — community implementation, no production providers running yet 50–60+ independent providers across 8 geo clusters (incl. Asia-Southeast, Asia-Northeast, US, EU regions tracked publicly) Fundamental supply-side bootstrap problem; The Graph has indexers but most don’t run RPC infra MUST
Latency / SLA tiers QoS scoring (latency EMA 35%, availability 35%, freshness 30%); no SLA framework Free tier 100 RPS / 210M CU / public nodes only; Growth $6/1M @ 5K RPS / 99.99% uptime; Enterprise unlimited RPS + bespoke SLA from 300M req/mo; status page tracks “100% uptime” per chain No SLA contracts, no tiered RPS policy, no published p50/p99 latency commitments MUST
Response correctness verification (a) Per-response operator-key attestation over keccak256(chain_id ‖ method ‖ keccak(params) ‖ keccak(result)), returned in X-Drpc-Attestation; (b) 3-way quorum for 9 deterministic methods, majority wins, minorities QoS-penalised Optional client-driven quorum_of / quorum_from verification via Custom Endpoints + DRPC SDK + DRPC-Sidecar; provider response signing (DSHACKLESIG, RS256) when client supplies a nonce; otherwise trust Dispatch is actually stronger here in the MVP: forced 3-way + always-on attestation vs. dRPC’s opt-in. But Dispatch’s 3× cost overhead is likely uneconomic at scale — needs adaptive verification (sample-based, dispute-triggered) SHOULD (refine, don’t remove)
Slashing / fraud proofs / arbitration slash() reverts unconditionally; no fraud proofs, no Merkle-Patricia Trie verification per EIP-1186, no block header trust oracle, no canonical truth oracle None — dRPC uses reputation only: bad providers get fewer requests or are removed manually dRPC has no slashing either, but it doesn’t claim to be a Horizon data service. For Horizon, the Arbitration Charter (GIP-0009) and Dispute Manager pattern set an expectation: data services on Horizon are typically slashable up to 10% with arbitrator-driven disputes. Dispatch must answer how — at minimum a path MUST (path) / SHOULD (impl)
Provider onboarding & quality vetting indexer-agent automates register/startService/stopService; subgraph for discovery; permissionless via 10K GRT provision Manual selection by dRPC team based on “reliability, quality of service”; provider installs Dshackle (Kotlin/JVM), associates Team ID via Discord; reputation-based payouts; can use dRPC free for own infra Dispatch’s permissionless model is philosophically better, but lacks vetting — unbounded Sybil risk. Need staking + reputation thresholds + benchmark gates MUST (gate)
Rate limiting & DDoS Per-IP token-bucket rate limiting via governor Free tier: 120K CU/min/IP, batch capped at 3, max 2s timeout, 10K log entry cap; Paid tier: only deposit-bounded Comparable basics; missing per-key quotas, batch caps, log caps, timeout enforcement SHOULD
Authentication & access control Consumer SDK signs per-request EIP-712 receipts; gateway issues receipts API key as URL dkey= param or Drpc-Key HTTP header; per-key Network Whitelisting; Tags & Descriptions; team roles; provider auth via JWT/RSA key-pair Dispatch lacks: API-key abstraction over receipts (UX), per-key chain whitelisting, team/role hierarchy, key rotation/deletion UI SHOULD
Billing / payments model TAP v2 receipts → RAVs (60s) → RPCDataService.collect() (hourly) → GraphTallyCollector → PaymentsEscrow → GraphPayments → GRT to indexer; 4×10⁻⁶ GRT/CU base, 3× for quorum Pay-as-you-go USD or crypto deposit, $6/1M requests flat, recurring card payments, low-balance alerts, referral program Dispatch’s trust-minimised micropayments on GraphTally (GIP-0054) is a structural advantage — but UX needs fiat on-ramp, auto-top-up, and clearer cost predictability SHOULD
Escrow / credit management Horizon PaymentsEscrow + 14-day thawing for indexer provisions (GIP-0066) Off-chain account balance, deposit-and-deduct model managed in Dproxy Dispatch’s on-chain escrow is more robust but more friction; need consumer-side abstraction SHOULD
Observability / dashboards / alerting Prometheus metrics on indexer + gateway Real-time analytics dashboard, Statistics API (/api/metrics/json), Prometheus endpoint (/api/metrics/prom), WebSocket Events tab, Error Log, Performance Dashboard, public Status Page with per-chain uptime, Slack/email/webhook alerts Big gap: no consumer dashboard, no public status page, no breakdown by chain/method/provider MUST (dashboard) / SHOULD (status, alerts)
Failover & redundancy 3-way concurrent dispatch implicitly provides redundancy for quorum methods; weighted-random top-k for non-quorum Multi-round selection: best-latency → all → custom fallback; auto-retry on retryable errors with another provider; “handles most failure cases without provider-side retries” Dispatch’s 3-way default is wasteful for non-deterministic / cheap methods; needs configurable strategy registry SHOULD
Key management & operator security Operator key signs attestations; audit found H-3: single-EOA owner could inject fake state roots (acknowledged disabled) Provider-side TLS + JWT; signing keys via PKCS#8 RSA; SSL termination guidance Dispatch should mandate hardware/HSM-class key management for operator keys; document key-rotation runbook (graph-network’s tap-agent already supports operator_mnemonics rotation) SHOULD
Gateway redundancy / multi-gateway federation Single dispatch-gateway reference impl; consumer SDK supports direct P2P to indexers Single Dproxy gateway brand (centralised control plane), but provider-side Dshackle servers run per-region with per-DNS SSL; “Running multiple Dshackle servers behind a single DNS name is not supported” Dispatch’s permissionless gateway model is a real differentiator. Need to demonstrate ≥2 production gateway operators + a federation handshake / cross-gateway QoS gossip protocol SHOULD
Indexer integration with existing stack Runs alongside Geth/Erigon/Reth/Nethermind via dispatch-service sidecar Dshackle is the unified upstream adapter; Erigon/Nethermind are explicitly tested for sticky-session methods, Geth flagged slow for eth_getFilterLogs Dispatch design is good (sidecar) but hasn’t proven multi-client compatibility; needs a published Feature/Client Support Matrix analogous to subgraph GIP-0008 MUST (matrix)
Data privacy / anonymisation Not specified OFAC/MEV-blocking via private relays; Tor support documented; no compliance certifications listed NICE
Governance Independent community implementation aligned to GRC-005; follows Horizon governance Founder-led private company (P2P.org spinout, 2022) Dispatch’s path through GRC → GIP → Graph Council ratification is a strength (legitimacy, decentralised governance, eligibility for protocol issuance), but needs to actually progress through stages SHOULD
Audit posture One audit found 3 High (H-1 CEI in collect(), H-2 owner can drain rewards pool, H-3 fake state roots) + 2 Medium; some findings reference disabled paths No public smart-contract surface (off-chain only); SOC2/ISO claims absent in public docs (competitors like Chainstack cite SOC2 Type II) Dispatch must clear remaining audit issues + commission a second-pass audit on the contract surface that ships MUST
Ecosystem developer tooling / SDKs TypeScript consumer-SDK only Official JS SDK (@drpcorg/drpc-sdk); native curl/node-fetch/Web3.js/Go/Python/HTTP code snippets per chain page (none are first-party SDKs); compatibility with web3.js / ethers / viem on standard JSON-RPC Need first-party SDKs in Rust + Python + Go (Dispatch already has Rust workspace internally). Drop-in Web3.js/ethers/viem provider compatibility is non-negotiable for adoption MUST (drop-in compat) / SHOULD (multi-lang SDKs)
Status / incident communication None Public status.drpc.org per-chain uptime, public incident posts (e.g., “Increased Latency Asia” auto-posted) MUST
Rewards / issuance integration Not implemented; “no GRT issuance / rewards pool”; RFC argues no canonical truth on RPC, so unsafe to issue rewards n/a — dRPC has no token This is intentional in MVP, but for parity with SubgraphService and to qualify under the Rewards Eligibility Oracle (REO) being scoped for Q1 2026, Dispatch needs a measurable “value delivered” proxy SHOULD (post-GA)

Prioritized Roadmap (P0 → P2)

Effort: S ≤ 4 weeks, M = 1–3 months, L = 3–9 months. Buckets: CT = on-chain contracts, OFF = off-chain services, ECO = ecosystem/governance, EXT = external integrations.

P0 — Must ship before any production label

  1. Resolve security audit findings [CT, S]
    Re-audit RPCDataService.sol post-disable of withdrawRewardsPool and slash paths; fix CEI ordering in collect() (H-1); document explicitly which audited paths are dead-code in the deployed bytecode at 0xA983b18B8291F0c317Ba4Fe0dc0f7cc9373AF078. Commission a fresh independent review prior to mainnet GA. Without this, GIP advancement is blocked.

  2. Sticky-session routing for filter / stateful methods [OFF, M]
    Implement provider-affinity for eth_newFilter, eth_getFilterChanges, eth_getFilterLogs, eth_uninstallFilter, and eth_newBlockFilter — single-provider, no quorum, no retries by default. Mirror dRPC’s method-groups: filter opt-in label so providers self-declare capability. Also gate on per-client compatibility (Erigon/Nethermind known good; Geth slow on getFilterLogs).

  3. Drop-in EVM JSON-RPC client compatibility [OFF, S]
    Validate end-to-end Web3.js / ethers v6 / viem / web3.py / ethers-rs compatibility without the Consumer SDK (transparent receipt issuance from gateway to anonymous HTTP clients). Without this, the addressable market is whoever rewrites their app to use consumer-sdk — i.e. nobody.

  4. Consumer dashboard + status page [OFF, M]
    Per-key request analytics (CU spent, requests/sec, error rates, p50/p95/p99 latency by chain & method), CSV export, low-balance alerts. Public per-chain status page (Atlassian Statuspage or self-host) with auto-incident posting. dRPC publishes a Statistics API at /api/metrics/json and a Prometheus scrape at /api/metrics/prom — match this surface.

  5. Indexer Feature / Client Support Matrix [ECO, S]
    Publish a feature-support-matrix analogous to GIP-0008 but for RPC: which method × chain × client × archive/full combinations are eligible for service, payment, and (eventually) reward; which are “experimental.” This is the canonical-truth surface the Arbitration Council will need.

  6. Provider bootstrap program [ECO, M]
    Mirror dRPC’s Startup/Sponsorship program and “free for own infra” carrot. Recruit 5–10 founding indexers committed to running ≥3 chains with archive in ≥3 geographic regions. Without ≥10 providers across ≥3 regions covering the top-5 chains, QoS routing has nothing to optimise.

  7. Per-region provider QoS + same-region routing already implemented — verify with synthetic load from EU/NA/APAC; publish baseline latency benchmarks. (Already in Dispatch design, just needs proof.) [OFF, S]

  8. Slashing / dispute path RFC [ECO, M]
    Write follow-on GRC: even if Dispatch doesn’t slash on response correctness in v1, it must specify slashable conditions for non-controversial offences — fake provisioning (claims to serve a chain, doesn’t), griefing (returns errors > N% of attestation-signed responses), under-collateralized stake-to-fees ratio. Align with the Horizon Arbitration Charter (GIP-0009) and Horizon’s flexible slashing cap of 10%.

P1 — Required for credible commercial adoption

  1. Add Solana, Bitcoin, and 5+ Cosmos / non-EVM chains [OFF + EXT, L]
    Solana is the single biggest ecosystem gap. Solana adds non-trivial work: account/program/logs/block subscriptions, stake-weighted QoS, optionally Yellowstone Geyser gRPC streaming as an add-on. Reuse Dshackle’s chain abstractions where licensing permits or build native Rust adapters per chain.

  2. Adaptive verification economics [OFF, M]
    Replace blanket 3× dispatch with: (a) sample-based attestation auditing (e.g., 5–10% replay against canonical “anchor” providers); (b) on-demand quorum when consumer requests quorum_of=N header (mirrors dRPC’s Custom Endpoints with quorum_of/quorum_from); (c) full quorum default only for eth_call/eth_getLogs on transactional paths. Cuts cost from 3× to ~1.1× while preserving correctness signal.

  3. MEV-protected endpoint variant [OFF + EXT, M]
    mev+ URL prefix or X-Dispatch-Privacy: private header that pins eth_sendRawTransaction to MEV Blocker / Flashbots Protect / Beaverbuild relays on ETH, and equivalent on Base/BSC/Polygon/Arbitrum/Solana. Charge premium CU (mirrors dRPC’s “$1 unit” pricing).

  4. WebSocket subscription scaling + reconnection semantics [OFF, M]
    Document and harden: max concurrent subscriptions per key, automatic resume on provider failover (sticky enough that subscription IDs survive), back-pressure handling, exclusion of newPendingTransactions (matches dRPC’s stance) or explicit support if a provider opts in.

  5. Multi-language SDKs [OFF, M]
    First-party Rust (already in workspace), Python, and Go SDKs — including the receipt-signing primitive. Direct Web3.js/ethers/viem providers that wrap receipt issuance transparently (no SDK install needed for read-only).

  6. Per-key controls: chain whitelisting, rate limits, team roles [OFF, S]
    Match dRPC’s per-key Network Whitelisting, Tags, Team access, and Key Deletion features.

  7. Gateway federation v0 [OFF + ECO, L]
    Specify gateway ↔ gateway protocol so 2+ independent gateway operators can: (a) share QoS observations (provider scoring is reproducible), (b) honour each other’s RAVs (or interoperate on a common GraphTally aggregator), (c) avoid double-charging consumers. This is what makes Dispatch “decentralised at the gateway layer” in a way dRPC structurally cannot match.

  8. Enterprise-tier SLA framework [ECO + OFF, M]
    Define and publish: 99.9% / 99.95% / 99.99% tiers with measurement methodology, RPS commitments, exclusions, and credit remedies. Even before legal SLA contracts, publish target SLOs.

  9. Trace/debug tier hardening [OFF, M]
    Verified debug_traceTransaction, debug_traceCall, trace_transaction, trace_block, trace_replayTransaction (with vmTrace) coverage on Ethereum, Base, Arbitrum, Polygon — the four chains where dRPC publishes full debug docs. Publish per-chain support matrix.

P2 — Nice-to-have / differentiators / post-GA

  1. gRPC / Yellowstone-style streaming [OFF, L]
    Once Solana is in, expose Geyser gRPC as a paid add-on per dRPC’s marketplace pattern.

  2. Permissionless chain registration [CT + ECO, L]
    The MVP punts on this for safety. Long-term, on-chain registry of (chainId, canonical clients, finality semantics) voted in by curation signal or Council, replacing the current static support matrix.

  3. EIP-1186 Merkle-Patricia Trie proof verification [OFF, L]
    Optional consumer-side / gateway-side verification of eth_getProof responses against a trusted block-header oracle. Closer to a real correctness guarantee for state-reads. Listed as deliberately not in MVP; a credible path here is the deepest moat Dispatch could build.

  4. Issuance / rewards eligibility [CT + ECO, L]
    Track The Graph’s Rewards Eligibility Oracle work. Once REO ships for SubgraphService Q1 2026, design the analogous “value delivered” proxy for RPC (signed-attestation throughput, QoS-weighted served CUs, etc.) — this unlocks GRT issuance into the Dispatch fee market.

  5. NodeHaus-equivalent for chains [ECO, L]
    A “for-chains” product line that lets new L1/L2 foundations spin up their public RPC on Dispatch indexers with a branded faucet, observability dashboard, and 24/7 SLA — matches dRPC’s NodeHaus which deploys “within 48 hours to 1 week.”

  6. Geographic expansion to ≥6 regions [EXT, L]
    dRPC operates 8 geo clusters. Dispatch needs ≥6 (NA-East, NA-West, EU-West, EU-Central, APAC-NE, APAC-SE) with ≥2 providers per region for failover.

  7. Compliance certifications [ECO, L]
    SOC 2 Type II is a competitor differentiator (Chainstack pitches it explicitly vs. dRPC). Probably a year-2 concern, but flagging for institutional adoption.

Closing Note: The Two Structural Challenges

Two challenges sit underneath the entire roadmap and warrant explicit framing:

1. Response correctness verification without canonical on-chain truth. This is the deepest issue, and Dispatch’s RFC is correct that RPC has no canonical on-chain truth that can be safely arbitrated. Subgraphs have Proofs of Indexing reproducible by an Arbitrator (GIP-0009); a substreams data service can lean on Firehose determinism (GIP-0053). RPC has neither. dRPC sidesteps this entirely: it just trusts (or sometimes 2-of-3 quorums) its vetted partners, with no slashing, no fishermen, no arbitrators. Dispatch’s MVP (forced 3-way quorum + always-on operator-key attestation) is technically stronger than dRPC’s opt-in quorum_of — but the 3× cost makes it economically untenable at production volume, and operator-key attestation only gives non-repudiation, not correctness. The credible production path is adaptive verification: a tunable mix of (a) sample-based replay against anchor providers, (b) consumer-requested quorum, (c) economic skin-in-the-game via Horizon stake plus out-of-band dispute mechanisms (e.g., zk-proofs of state-reads over time, EIP-1186 proofs for state methods, fishermen for non-deterministic methods graded by attestation divergence). Without resolving this, Dispatch occupies an uncomfortable middle: trust-minimised in name, but in practice not really slashable, while paying the latency/cost overhead of decentralisation.

2. Provider network bootstrapping. dRPC took ~3 years and a P2P.org incubation to assemble 50–60+ providers across 8 geo clusters. Dispatch starts with ~0 production providers in MVP. The Graph’s existing indexer set is a credible cold-start audience — they already have the staking, GRT, and operational discipline — but most don’t run Geth/Erigon/Reth/Nethermind in archive mode across 10 chains in 6 regions today. The single highest-leverage move in the roadmap is therefore P0 #6: a serious indexer-onboarding program with reimbursable infra grants, a published reference deployment (Docker Compose already exists per project knowledge), and chain-by-chain coverage targets — with a clear policy that until coverage thresholds are met, Dispatch routes to public/foundation endpoints as fallback (mirroring dRPC’s free-tier-uses-public-nodes pattern). Otherwise the QoS engine is optimising over an empty set.

The strategic bet worth making clear: Dispatch does not need to beat dRPC on chain count or latency in year one. It needs to be credibly equivalent on the top 10 EVM chains while delivering two things dRPC structurally cannot — non-custodial micropayments via GraphTally and a federated, governance-legitimate gateway layer — both of which the Horizon framework gives it for free, provided the security and provider-bootstrap problems above are solved.