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

**URL:** <https://forum.thegraph.com/t/grc-005-dispatch-an-experimental-json-rpc-data-service-on-horizon/6913>\
**Category:** Graph Request for Comment (GRC)\
**Created:** [April 17, 2026, 8:15am UTC](https://forum.thegraph.com/t/grc-005-dispatch-an-experimental-json-rpc-data-service-on-horizon/6913 "2026-04-17T08:15:05Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![AxiomaticAardvark](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/axiomaticaardvark/32/2882_2.png) [@AxiomaticAardvark](https://forum.thegraph.com/u/AxiomaticAardvark)\
**Post date:** [April 17, 2026, 8:15am UTC](https://forum.thegraph.com/t/grc-005-dispatch-an-experimental-json-rpc-data-service-on-horizon/6913/1 "2026-04-17T08:15:05Z")

</div>

# 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 | ✅ Live on Arbitrum One |
| Subgraph | ✅ Live on The Graph Studio |
| npm packages | ✅ Published (`@lodestar-dispatch/consumer-sdk`, `@lodestar-dispatch/indexer-agent`) |
| Active providers | ✅ 1 — `https://rpc.cargopete.com` (Arbitrum One, Standard + Archive) |
| Full payment loop | ✅ Working end-to-end — receipts → RAVs every 60s → `collect()` every hour → GRT to provider |
| Dynamic provider discovery | ✅ Working — gateway polls subgraph every 60s |
| Slashing | ❌ 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`

---

<div class="post-metadata">

**Author:** ![AxiomaticAardvark](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/axiomaticaardvark/32/2882_2.png) [@AxiomaticAardvark](https://forum.thegraph.com/u/AxiomaticAardvark)\
**Post date:** [April 25, 2026, 8:32am UTC](https://forum.thegraph.com/t/grc-005-dispatch-an-experimental-json-rpc-data-service-on-horizon/6913/2 "2026-04-25T08:32:31Z")

</div>

# 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](http://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](http://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](http://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](http://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.