docs(nodes): add BoltRPC as Celo RPC provider

[KubilayJackson]

Summary

• Add BoltRPC to the As a Service RPC provider list on /tooling/nodes/overview
• Celo Mainnet only (HTTPS, WebSocket, debug methods; archive on request for qualifying plans); operated by Matrixed.Link
• Placed after PublicNode; sentence-case #### Supported networks

Review feedback addressed

• Removed ISO/IEC 27001:2022 claim
• Rewrote archive sentence to match BoltRPC pricing (on request / qualifying plans; paid + 14-day trial)
• Rebased onto main; BoltRPC now follows PublicNode

Test plan

• Name link opens https://boltrpc.io
• Operator link opens https://matrixed.link
• Card opens https://boltrpc.io/networks/celo
• Section renders after PublicNode under As a Service
• No ISO/compliance claim in the entry

[GigaHierz]

Thanks for this, and apologies for the slow turnaround.

I did the provider check and Matrixed.Link clears the bar — the Chainlink ecosystem directory lists you as a node operator from April 2022, the Injective validator announcement checks out, and the domain dates to 2021. The BoltRPC Celo page is substantive rather than a templated stub, and the chain facts on it (42220, the L1→L2 migration, fee abstraction) are accurate. So this belongs on the list.

Three things before it can merge.

1. Please cut the ISO/IEC 27001:2022 sentence

I could not corroborate it. matrixed.link/trust states the certificate is effective 2026-02-03 with scope "available under NDA", but there is no certificate number, no issuing registrar, and no accreditation-registry entry I can find — every search result asserting the certification traces back to your own site. There is also an internal inconsistency worth fixing on your end regardless: the site-wide header badge reads "ISO 27001:2022 Operator since 2021" while the FAQ dates the certificate to February 2026.

To be clear about why this is a hard no rather than a nitpick: no other entry on that page makes a compliance claim. If we publish one we cannot verify, we have to police every one that follows. Happy to reinstate the sentence if you can give me a certificate number and the issuing body.

2. Please rewrite the archive sentence

The diff says Celo Mainnet "is served as a full archive node with HTTPS, WebSocket, and debug methods". Your own Celo page walks that back further down:

Archive-only methods are available on request for qualifying plans.
ARCHIVE ON REQUEST (3): eth_getBalance, eth_call, debug_traceTransaction

and the pricing page gates it from Business ($699/mo) upward. A Builder-tier reader would not get what the sentence promises. Something like:

BoltRPC is a multi-chain RPC provider operated by Matrixed.Link. Celo Mainnet endpoints support HTTPS, WebSocket, and debug methods; archive access is available on request for qualifying plans. Paid plans only, with a 14-day trial.

I also could not test any of the capability claims — endpoints.boltrpc.io/rpc/celo returns 401 and there is no keyless endpoint, so eth_chainId, an early-block eth_getBalance, and debug_traceBlockByNumber all went unverified. If you can share a demo endpoint or a temporary key I'll run those and we can state the archive support with more confidence rather than less.

3. Please rebase — the branch conflicts

Three provider entries (node101, PublicNode, and one earlier) landed at the end of the same section since you branched, so this appends to a spot that has moved. The resolution is trivial: put the BoltRPC block after PublicNode at the end of "As a Service".

While rebasing, one style point: the page has drifted between #### Supported Networks and #### Supported networks. Our style guide asks for sentence case on new headings, so #### Supported networks.

One thing worth raising, not blocking

There's no status page — status.boltrpc.io doesn't resolve and /status 404s. Every other as-a-service provider on that page has one. Not a blocker for the listing, but it is the first thing a developer evaluating an RPC provider looks for.

Ping me once it's rebased and I'll re-review straight away.

[GigaHierz]

Friendly nudge on this one — no rush.

To recap what's needed: cut the ISO/IEC 27001:2022 sentence (unless you can share a certificate number and issuing registrar), reword the archive sentence to match your own "available on request for qualifying plans", and rebase — the section has moved since you branched.

The listing itself is not in question; Matrixed.Link's track record checks out. It's just those two sentences claiming more than I can verify.

Still happy to test eth_chainId, an early-block eth_getBalance and debug_traceBlockByNumber if you can share a demo endpoint or temporary key — that would let the entry state archive support with confidence rather than hedging.

[KubilayJackson]

Thanks for the thorough review — all three items addressed and rebased onto main:

1. ISO sentence removed.
2. Archive sentence rewritten to your suggested wording: HTTPS/WebSocket/debug supported; archive on request for qualifying plans; paid plans only with a 14-day trial.
3. Rebased — BoltRPC now sits after PublicNode at the end of As a Service, with #### Supported networks.

Happy to share a temporary key offline if you still want to run eth_chainId / early-block eth_getBalance / debug_traceBlockByNumber before merge. Status page note noted as a follow-up on our side.

[KubilayJackson]

@GigaHierz — demo endpoints for the capability checks you mentioned (eth_chainId, early-block eth_getBalance, debug_traceBlockByNumber):

• HTTPS: https://endpoints.boltrpc.io/rpc/brpc_live_yU5d9XL2ag0pjTu1HQswBuXDsdVrLFd1/celo
• WebSocket: wss://endpoints.boltrpc.io/ws/brpc_live_yU5d9XL2ag0pjTu1HQswBuXDsdVrLFd1/celo

Temporary review key — please treat as short-lived. Happy to rotate once you're done.

[palango]

Checked 839f037 against @GigaHierz's review. The ISO/IEC 27001 sentence is gone, the archive sentence now says access is on request for qualifying plans, the entry sits after PublicNode at the end of "As a Service", and the heading is sentence case. boltrpc.io/networks/celo and matrixed.link both return 200.

[GigaHierz]

All three items are in, and I ran the capability checks against the endpoint you provided. Everything the entry claims is now verified rather than taken on trust. Approving.

---

⚠️ First, please rotate that key

You posted a live API key in a public comment on a public repository. I know you meant it as short-lived and offered to rotate, but it has been publicly readable and is almost certainly already scraped — credential harvesters watch public GitHub events continuously. Please revoke it now rather than after merge. GitGuardian only scans the diff, not comments, so nothing here flagged it for you.

For future reviews: a key in a comment is never really temporary. I have not quoted it back anywhere in this review.

---

What I verified

Identity and freshness — in sync with no lag:

eth_chainId  -> 0xa4ec  (42220, Celo mainnet)
BoltRPC height = 78433674   forno height = 78433674   delta = 0 blocks

Archive — genuine historical state, not just headers. This is the claim I most wanted to test, because serving old blocks is easy and serving old state is the hard part:

eth_call  CELO.totalSupply() @ block 1,000,000
  -> 0x...01f229d6c3eb4f3d7b8ea6a2     (real historical value)

block      1,000,000   getBlock=OK  state OK
block     20,000,000   getBlock=OK  state OK
block     31,056,500   getBlock=OK  state OK
block     40,000,000   getBlock=OK  state OK
block     60,000,000   getBlock=OK  state OK

Full range, no "missing trie node". That is a real archive node.

Debug methods:

debug_traceTransaction(recent tx, callTracer)      -> full trace returned
debug_traceBlockByNumber(recent block, callTracer) -> full trace returned

WebSocket — including live subscriptions:

WS open
eth_chainId -> 0xa4ec
eth_subscribe(newHeads) -> subscribed
newHeads push received, block 78433713

One nuance, for you rather than for the docs

debug_traceBlockByNumber at block 1,000,000 returns block not found: 0xf4240, while eth_getBlockByNumber and eth_call at that same height both succeed. So the data and state are there; only tracing is unavailable for pre-L2-migration blocks.

I am fairly confident that is the general Celo L2 situation rather than anything specific to you, so I have not asked for a doc change — the entry says "debug methods" without promising them across the pre-migration range. Worth knowing if a customer asks.

The diff

Reads correctly now: ISO sentence gone, archive scoped to "available on request for qualifying plans", paid-plans-with-trial stated, placed after PublicNode, and #### Supported networks in sentence case. Thanks for the quick turnaround — and for offering the endpoint, which is what let this move from hedged to evidenced.

Merging once the docs check finishes.

[GigaHierz]

Merged — thanks for turning this around so fast, and for the endpoint. Being able to actually test the claims is the difference between an entry that hedges and one that states what the service does.

Two things on your side:

1. Revoke that key now if you have not already. It was public for roughly 20 minutes on a repo that gets watched.
2. The status page — status.boltrpc.io does not resolve and /status 404s. Every other as-a-service provider on that page has one, and it is the first thing a developer evaluating an RPC provider looks for. You mentioned it as a follow-up; worth doing.

One more for your marketing copy, not for these docs: the site-wide badge reads "ISO 27001:2022 Operator since 2021" while the FAQ dates the certificate to February 2026. Those two cannot both be right, and it is the kind of inconsistency that makes a reader discount the rest of the page. If you do get the certificate number and registrar published, ping me and I am happy to revisit the sentence we cut.

[KubilayJackson]

Cheers, key rotated. The status page is shown after logging in.