Repository navigation
Provider inclusion: BlockVectra keyless RPC for Ethereum, Base and Arbitrum #3573
Description
Could you evaluate three more BlockVectra endpoints for the existing keyless public RPC cohorts? This is a provider-inclusion request from BlockVectra, following the four chains already accepted in #3462 and #3500.
| Existing cohort | Chain ID | Keyless HTTPS JSON-RPC endpoint |
|---|---|---|
| Ethereum | 1 | https://api.blockvectra.com/v1/eth_mainnet/public |
| Base | 8453 | https://api.blockvectra.com/v1/base_mainnet/public |
| Arbitrum One | 42161 | https://api.blockvectra.com/v1/arb_mainnet/public |
The public catalog, saved on 2026-11-07T08:19:55.794272+00:00, advertises eth_getBlockByNumber("latest", false) on each route, without an account or API key. Each public route advertises 3 requests/s per IP, per instance; burst 20; batch maximum 10; and a 1,000-block history window. These limits describe the public routes, separately from the keyed service. eth_getLogs is not in their public method lists, so incompatible logs probes and deeper history checks should keep their unsupported/refused outcomes.
We have not run your harness against these three routes or established fresh chain-ID/head-lag results for this submission. Please retain your usual eligibility checks, cadence, error accounting and ranking rules. Serving-backend ownership and effective response-cache TTL are unconfirmed; any latency result should remain an endpoint-level observation, not a direct-node round-trip claim.
At source e0885c19466d3148134f36ecbd145ef9a89cf187, the existing Ethereum, Base and Arbitrum harness groups do not include BlockVectra. Would these fit those cohorts? Happy to prepare a small configuration PR if useful; no new benchmark, harness, credential or special ranking treatment requested.
The Robinhood proposal already posted in the earlier thread remains separate; this request does not resubmit it.
Activity
Flotapponnier commentedon Nov 7, 2026
Thanks for the clear submission. I ran a quick manual check from Europe on 2026-11-07 (around 08:40 UTC), roughly one request per second. This is not a harness result, just a check of whether each route is eligible:
eth_chainIdeth_getBlockByNumber("latest", false)eth_mainnet/publicarb_mainnet/publicbase_mainnet/public-32010 node is syncing; calls are temporarily unavailable(node_syncing)Ethereum and Arbitrum fit the existing keyless cohorts, and we'll add both ourselves, so no config PR is needed. Same rules as every other endpoint: the standard probe every 60 seconds from US-East, EU-West and Singapore, the usual stale-head and error classification, and no special treatment. They'll appear on the pages once they have a full window of data.
One thing to flag: in a burst of 10
eth_blockNumbercalls on the Ethereum route, spaced about 1.2 s apart (below the advertised 3 req/s), one came back-32005 public chain pool is busy(public_pool_busy). Our probe rate is far lower, one call a minute per region. Any such response in production counts as an error in the success rate, like any other refusal.Base is on hold until the route answers. Comment here once the node has caught up and we'll re-check it and add it the same way.
The Robinhood proposal in #3462 stays a separate thread, as you said.
gjwang commentedon Nov 7, 2026
Thanks for checking these. Please go ahead with Ethereum and Arbitrum under the standard cohorts; no config PR from us. Both
public_pool_busyandnode_syncingshould count as errors.Base stays on hold. I’ve passed your exact failure report to our production owner and will follow up here once recovery has been verified. The four chains in #3462 remain separate.
BlockVectra joins the Ethereum and Arbitrum RPC pages (#3573) (#3574)
BlockVectra joins the Ethereum and Arbitrum RPC pages (#3573) (#3575)
Flotapponnier commentedon Nov 7, 2026
Ethereum and Arbitrum are wired in (#3574 on dev, released to production in #3575). Both routes have been probed since about 09:30 UTC from US-East, EU-West and Singapore, every 60 seconds. The rows will appear on https://openchainbench.com/benchmarks/ethereum-rpc and https://openchainbench.com/benchmarks/arbitrum-rpc once the publishing pass picks up the new series. The 24h figures settle over the next day. Base stays on hold until its route stops returning
node_syncing.gjwang commentedon Nov 7, 2026
Thanks — I checked the two pages and their linked JSON at 11:13 UTC. Both public cohorts still list six providers, without BlockVectra:
asOf2026-11-07T11:04:17.620Z.asOf2026-11-07T11:03:47.613Z.Could you check whether the publishing pass is picking up the new series, or whether it is still waiting on something? These are snapshots of the public output; they don't establish why the rows are absent. No change requested to the sampling or ranking rules, and Base stays on hold.
Flotapponnier commentedon Nov 7, 2026
Thanks for checking, you were right that something was stuck on our side.
The probes had been collecting BlockVectra samples on both chains since 10:19 UTC, but the job that turns the raw series into the published rankings reads the bench definitions it was built with, and that build predated the change that added you. I rebuilt it and republished both boards at about 12:10 UTC. Both rows are live now:
The figures cover only the hours since sampling started, so they will move as the 24h window fills. Most of the failed calls are
-32005 public_pool_busy, which is what pulls the Ethereum success rate down. Base stays on hold as agreed.gjwang commentedon Nov 7, 2026
Thanks — both public JSON feeds now list BlockVectra, and the Ethereum HTML does too.
One remaining mismatch: the Arbitrum HTML saved at 12:30 UTC still lists six public providers without BlockVectra (
Date: 11:38:29 GMT,Age: 3129). Its JSON, asOf 12:24:47 UTC, lists seven including us. Could you refresh that cached page too? This is the saved server HTML; I haven’t tested the page in a browser.I’ve passed the reported
public_pool_busyfailures to our production owner. Please keep them counted, with Base still on hold.If you already have a failed sample, its chain, UTC time/region, error code and gateway request ID would help us trace the exact rejection. Please leave out private headers; no extra probe run needed.
Update, 13:09 UTC: the Arbitrum server HTML now lists seven public providers, including BlockVectra. That clears the missing-row observation in my earlier snapshot; no further page-refresh action is needed for that report. The availability issue remains separate.
Flotapponnier commentedon Nov 7, 2026
The Arbitrum page has refreshed on its own since your snapshot: the HTML served at 12:59 UTC lists BlockVectra 4th of seven, the same as the JSON. The failures stay counted, and Base stays on hold.
One correction to my last comment. I wrote that most failed samples were
-32005 public_pool_busy. That came from a few manual calls I made earlier, not from the probes. In the probe logs, every failed latency sample is an HTTP 429. The probe records only the status code and drops the response body, so it has no gateway request ID. Recent examples, with times taken from the log lines:Each region sends one
eth_getBlockByNumber("latest")call per chain per minute, from Railway (us-east, eu-west) and Singapore.Separately, our data-integrity check (not part of the latency ranking) gets
-32601 method is not available on the public endpointforeth_getLogson Ethereum, for example at 13:13:10 UTC from us-east. It also got an HTTP 429 oneth_getBalancein the same pass.gjwang commentedon Nov 7, 2026
Thanks for the correction. I’ve passed those timestamps to our production owner and separated the HTTP 429 probe failures from the manual public_pool_busy result. No confirmed cause or fix yet. Please keep the failures counted and Base on hold; no extra probe run needed.
Flotapponnier commentedon Nov 7, 2026
Thanks, that's all on our side for now. Ethereum and Arbitrum are live and the failures stay counted as they come. I'm closing this issue; for Base, comment here or open a new issue once the node reports synced and we'll check it and add it.