RPC status
CheckingRPC sample latency unknown
Robinhood Chain / public infrastructure
Robinhood Chain RPC
Live chain health. Measured request traffic. A working API explorer.
One public, keyless endpoint — with honest limits and no invented history.
4663 / 0x1237Network overview
Public status observations, not an uptime promise.
Waiting for a public status observation.
Connecting to shared observations…
Local chain head · observed
UnknownWaiting for a measured block
Public reference · observed
UnknownReference freshness unknown
Sampled block lag
UnknownSigned reference minus local; not a sync percentage
Sync & tip position
Position unknownSync work
UnknownNo sync observation yet
Local / network
UnknownMeasured blocks per second
Net catch-up
UnknownComparable paired samples only
Catch-up ETA
UnknownRecent-rate estimate, never guaranteed
Public endpoint
https://hood-rpc.pastrylabs.cloud
POST / JSON-RPC with eth_getLogs range paging: one complete page per call, with top-level continuation metadata. Public reads, no key required.
Transport & capacity
HTTP/2 · gzip · CORS
5 MiB incoming request limit. Explorer preview: 1 MiB decoded. Historical pages: 1–10,000 blocks. These are not standard RPC response-size limits.
RPC cache retention unknown.
Shared-IP allowance
60 requests / 10 seconds
Every route counts, including errors, assets, polls and cache hits. A batch is one HTTP request. Shared NAT/proxy egress shares this allowance.
429: back off with jitter; Retry-After is not guaranteed.
Freshness and sync work are separate signals. A reachable RPC or “no sync work” does not prove it is at the live tip. No peer count is inferred from unavailable observations.
RPC Analytics
Completed HTTP requests across this public host. A JSON-RPC batch counts as one HTTP request, not one per RPC item.
Open this section to load real aggregate observations.
Coverage unknown. Missing collection is not historical zero activity.
HTTP requests
—RPC requests unknown
Completed request rate
—Requests / requested window seconds · see coverage
Errors
—Server errors / client aborts unknown
Latency p95
—Median latency unknown
Completed HTTP requests
Measured buckets only; absent history is never filled with zeros.
No observations loaded
Errors
Completed request errors, not a count of JSON-RPC batch items.
No observations loaded
Latency distribution
Window p50 / p95 in milliseconds; not a manufactured trend.
No observations loaded
RPC cache outcomes
Recorded request outcomes. Unknown is not counted as a hit.
No observations loaded
Network clients · not people
Host-scoped keyed network identifiers. Shared egress is shared identity.
No observations loaded
RPC methods / request formats & HTTP statuses
JSON-RPC batch means a JSON-array request body, which can contain several calls or notifications and mix methods. It is a request format, not an RPC method: the batch counts once, and its individual items are not expanded in these public method totals. Small positive groups may be combined as other / suppressed.
No observations loaded
Privacy: no raw IPs, user agents, cookies, browser fingerprints, RPC bodies, arguments, IDs or wallets are retained in analytics. Positive client groups below 5 are suppressed. No client hashes or individual client activity are public.
Separate operator telemetry: source IPs, approximate offline geolocation, call targets/calldata and decoded transaction intent are retained in an authenticated operational console, not in public analytics. Private detail history has no time expiry and rolls off oldest data at its byte budget. Known credential/signing methods are suppressed; signed transaction envelopes are excluded from primary detail history but may briefly exist in its protected delivery spool.
How to read these measurements
Requests enter a window at HTTP completion, including errors and client aborts; an unfinished long request does not count yet. Standard RPC batches are one HTTP request. Traffic includes this page, assets, health checks and analytics polls, not only RPC reads. Response bytes describe the edge's logged HTTP response measurement, generally before gzip compression; they are not a guaranteed wire-byte count.
7-day disk-backed Kafka replay feeds the primary 90-day Zstd Parquet analytics store. Parquet is query data, not a backup or a second hot store. A bounded pending tail supports live observations. Windows expire at the exact 90-day cutoff; retention does not mean collection already covers 90 days.
Only the 5-minute window polls automatically while this section is visible. Each poll shares the ordinary IP allowance. Other windows refresh on selection or manually. If collection or storage is unavailable, no healthy or empty fallback is invented.
API Explorer
Build a read-only request, inspect the actual response, and copy working code. Requests run only when you choose to send.
01Build a request
No API keySafe starters — chain and head buttons send one small read. Logs loads a one-block request, without sending.
POST
Public routes & CORS
GET / is the unified dashboard, analytics and explorer; /index.html is an alias. API requests use POST /, GET /status.json or GET /analytics.json?window=5m. GET /llms.txt is the matching text reference. GET /robots.txt, /og.png and /og.svg serve crawler/preview assets; inspect Content-Type because the PNG route can fall back to SVG.
HEAD on GET routes returns headers/status without a body. OPTIONS returns HTTP 204 for CORS; origin * permits public reads with Content-Type: application/json. All requests, including preflights and analytics polls, count toward the IP allowance. Unknown paths return 404; no /docs route exists.
Parameters · synchronized with raw JSON
The explorer sends identified, single read-only calls only. The endpoint supports native notifications and batches; compatible identified read batches coordinate eth_getLogs pages. Native-only blockHash/pending filters can be sent in the raw body. Page width edits update params[1] in the raw request.
This log query has a large or unresolved span. Matching volume can make even a short range expensive. No request runs automatically.
Requests run only when you choose Send or a safe Run starter.
60 HTTP requests / 10 seconds / external IP. Shared NAT or proxy egress shares the allowance. Every request counts: this homepage, status polls, images, GET/HEAD/POST/OPTIONS, failed requests, cache hits, and each log page. A JSON-RPC batch counts as one HTTP request, not per method.
HTTP 429: back off with jitter; Retry-After is not guaranteed. A JSON-RPC -32005 capacity error is distinct from IP rate rejection: reduce matching volume or use smaller pages if response assembly exceeds capacity. This explorer never automatically retries a request.
Transport, caching & large-query expectations
HTTPS supports HTTP/2 and HTTP/1.1; HTTP/3 is not enabled. JSON supports negotiated gzip. Browsers handle compression and protocol selection automatically; curl snippets use --compressed. Compression reduces transfer bytes, not query work.
X-RPC-Cache identifies HIT, MISS or BYPASS when present. Retention is not proof of chain freshness, and cache object/storage limits are not RPC response-size limits. RPC and status HTTP responses are no-store.
Historical pre-paging observations: a user-reported 1,000,000-block call returned -32002 request timed out after 191.8s despite a 600s client timeout and no response cap; that user's 100,000-block call succeeded in 131.2s. Those observations remain historical evidence, not a measurement of the different anchored workload below.
Historical single-call transport · 2026-10-06 (not the current paging contract): one ordinary POST / returned all 1,496,940 logs over 1,000,001 blocks in 443.71s: 1,427,259,676 logical JSON bytes / 257,526,813 gzip bytes. First headers arrived after 364.79s: no successful body begins until every subrange succeeds. The full ordered per-log SHA-256 exactly matched the independent complete 101-page traversal. See the reference for concrete bounds, filter and digest.
Measured, not guaranteed: the earlier paged traversal took 610.49s; a separate anchored 100k query took 61.79s. Different filters, density, load and bounds change latency. No matched Envio comparison was measured. During the new single-call run, 442 public-head checks had zero errors; maximum sampled latency was 2.01s and maximum observed unchanged-head interval was 2.16s. This is not a zero-impact guarantee. No starter automatically runs a million-block query or traversal.
One complete page, not necessarily the full range: identified supported eth_getLogs ranges return a native result array for up to 10,000 inclusive blocks, plus top-level bounds and a cursor for the remainder. Tags resolve once; explicit numeric bounds remain exact, including after head rollback. Compatible read batches share a tag snapshot and preserve complete siblings on item errors. Incompatible mixed batches remain native opaque. Four shared workers, twenty active response owners and a rolling 24 GiB temporary-response budget including overhead bound admission through EOF/close. Capacity failures use -32005; per-request work deadline is 900s, native page wait 190s, snapshot/ordinary wait 8s. Pages can fail independently. No traversal-wide timer, automatic retries or cross-page hash pin.
Errors preserve native error.code/message/data; paging and retry guidance are top-level only. resume_cursor retries the same failed page (null before bounds resolve), never a success checkpoint. Gateway-generated timeout/capacity guidance recommends eth_getLogs on POST / and discards partial results. Validate the entire successful page, durably process every log (including empty pages), then save and manually pass the exact cursor with the same width. Null cursor establishes completion only on a validated success at the frozen end.
Historical caller failures & separately verified transport paths
Current older-range failure: the user reports repeated ordinary v4 Swap calls over 50,000,000–50,999,999 returning HTTP 502 with “server closed connection” at 274.58s, 276.90s, 275.62s and 275.514s despite gzip and a 1,800s client timeout; no logs were received. A subsequent report returned HTTP 503 with the same wording. The earlier 204.85s invalid/incomplete-response failure is also recorded. Graceful reload/drain behavior has been fixed and exercised, but the repeatable cutoff is not yet attributed or resolved. Successful calls from a different transport path, and the recent-range paged measurement, are not proof that this caller's failure is fixed. Python urllib inherits environment proxy settings unless an explicit opener is used.
Latest error-issuer evidence: a subsequent retry failed at 275.381s with Server: mitmproxy 12.2.3. That identifies the caller environment's proxy as the 502 issuer, not which component caused its server-side connection to close. A matching origin request remained connected beyond seven minutes and later reached HTTP 200 while its delivery stalled downstream. The closing cause is still unresolved; the existing caller transport has not been changed.
Separately verified exact-filter direct call · 2026-10-06: one standard POST /, caller ID 1, using the supplied address/topic over 50,000,000–50,999,999, returned HTTP 200 and all 4,030,585 logs with zero invalid logs. Final headers arrived at 867.601s; complete transfer, decoding, validation and hashing took 952.058s. The response was 3,844,898,728 decoded JSON bytes / 644,103,537 gzip bytes. Environment proxies were explicitly disabled for this run. Its full ordered per-log digest matched the independent complete topic-only read of the same range. This verifies that transport path and result, not the cause or resolution of the user's 275s failures; no independent older-range paged traversal is claimed.
02Inspect the response
Not sentSend a request to see an actual response, or choose “Illustrative response” for a clearly labeled example.
No actual response headers yet.
No request has been sent.
- jsonrpc / id / result
- JSON-RPC version, caller identity and complete method result. eth_getLogs returns the native array, with decimal page bounds, query_to_block, next_block and resume_cursor at the top level when handled. A log includes address, topics, data, block/transaction identity, indices and removed; removed indicates reorg removal.
- error.code / error.message / error.data
- HTTP 200 can still contain a JSON-RPC failure. -32002 with “request timed out” is a query deadline; HTTP 503 is service unavailability/maintenance. Native error.data is unchanged. Top-level resume_cursor on failure describes a same-page retry filter, never a success checkpoint; unresolved null is not completion. Never interpret an error as an empty successful result.
- page_from_block / page_to_block
- Inclusive decimal block bounds of the complete page, not a log-count or byte cap. Every matching log in those bounds is returned on success.
- query_to_block / resume_cursor
- Decimal frozen end and a self-contained filter for the next page. After validating and processing the complete page, pass the exact cursor as params[0], with the same page_blocks in params[1]. A null success cursor means completion only at the frozen end.
- Retry-After / service ETA
- 503 may include a retry interval and public estimated recovery time. An ETA is not a guarantee and can be unknown or overdue; it is separate from chain catch-up ETA. 429 may omit Retry-After.
- checked_at / block_lag / syncing
- Health observation time, signed sampled public-head minus local-head gap, and the node's sync claim. syncing = false does not prove public-tip freshness. “Tracking live tip” requires fresh paired header observations; no genesis-total “100%” is inferred.
Manual page continuation
No complete successful page yet. Your cursor never advances on error, cancellation, or a truncated display.
Browser display budget: 1 MiB of decoded response bytes. Larger previews are incomplete, never partial success, and enable no cursor. Use generated code or reduce page_blocks.
Page & failure contract
POST / method eth_getLogs takes [filter, page_blocks?], width 1–10,000/default 10,000. Omitted bounds retain native latest/latest; numeric bounds stay exact signed64 and moving tags resolve once. blockHash/pending/native-only calls and notifications retain native semantics with no artificial continuation. Eligible identified read batches coordinate one page per log item. A page is complete for its inclusive bounds, not for the full requested range while a cursor exists. Every page can independently fail; no cross-page hash pin or automatic retry.
Continue only after full HTTP success, valid JSON, matching ID, native result array, valid top-level page bounds/next_block and an exact unchanged-criteria next/frozen cursor. Durably process every log before acknowledgment, including empty pages. Errors may expose a same-page retry filter but never establish success. Unresolved error null is not completion. Keep the last processing-acknowledged checkpoint on errors, cancellation or truncated data. This explorer sends only identified single reads.
03Take this request with you
Generated from your current endpoint, query and JSON — one request, no traversal or automatic retry.
Snippets read the full response; unlike the browser preview they have no 1 MiB display budget.
JSON-RPC protocol & complete method reference
Every public route and the maintained method catalog. Availability and historical-state limits are explicit. Examples are never sent automatically.
JSON-RPC 2.0, with this endpoint's transport contract
The protocol is transport-independent. This service uses HTTP POST and positional parameter arrays; protocol-defined named parameters are not a promise that this Ethereum implementation accepts them. Official JSON-RPC 2.0 specification ↗
Public routes
Open this tab to load the generated route contract.
The method catalog is generated from the same maintained contract as OpenAPI and llms.txt.