[chillsauce]

Adds Pinax to the indexers section: a provider page at tooling/indexers/pinax.mdx, an entry in tooling/indexers/overview.mdx, and the nav entry in docs.json.

Replaces #2371, which I broke. Same change, 3 files, +51/−1.

What happened there: I amended the commit to correct its author email (it was recorded against a local hostname address that GitHub couldn't map to an account, so the commit showed no author). I did that inside a --depth 1 shallow clone, and the amend lost the parent, turning it into a root commit. The force-push then closed the PR and the diff ballooned to 446 files. Entirely self-inflicted and nothing to do with the content.

This branch is cut cleanly from main (50ed71d) with the original change cherry-picked onto it, so the diff is exactly what #2371 intended to propose.

Sorry for the noise.

[chillsauce]

Rebased onto main — the tooling/ → build/tools/ restructure had put this into conflict.

Three things moved:

• The page is now build/tools/indexers/pinax.mdx
• docs.json registers it under the new path, alongside build/tools/indexers/codex
• Internal links in both the page and the indexers overview updated from /tooling/indexers/… to /build/tools/indexers/…, matching how overview.mdx links to Envio

Diff is back to the original 3 files (+52/−1) and all four link targets resolve. @GigaHierz no action needed on your side — flagging in case you'd already started looking.

[GigaHierz]

Thanks for the PR, and for sorting out the rebase onto the new paths. Pinax is a good fit for the Indexers list. Before we merge, can you confirm two things for Celo specifically: (1) Firehose and Substreams are live on Celo mainnet today, not only RPC, and (2) the Celo Firehose and Substreams endpoints in the table are the ones a new user would use with a standard API key. A link to the Pinax page that lists Celo among supported networks would be enough for us to cite.

[chillsauce]

Thanks @GigaHierz — both confirmed, and your question surfaced something I needed to correct. Pushed a fix.

(1) Firehose and Substreams are live on Celo mainnet today, not just RPC. Verified just now against the live endpoints:

Service	Endpoint	Check
Firehose	celo.firehose.pinax.network:443	serves sf.firehose.v2.Stream, Fetch, EndpointInfo
Substreams	celo.substreams.pinax.network:443	serves sf.substreams.rpc.v2/v3/v4.Stream
RPC	https://celo.rpc.pinax.network	eth_chainId → 0xa4ec (42220)

(2) Those are the endpoints a new user would use with a standard API key. I streamed a live Celo block end to end with nothing but an X-Api-Key header on a normal key — no allowlisting, no special provisioning. The auth column in the table is accurate: X-Api-Key for Firehose, SUBSTREAMS_API_KEY for Substreams, API key for RPC.

Citation: https://pinax.network/chain/celo lists Celo with the services we run for it.

The correction

That same block stream reported detailLevel: DETAILLEVEL_BASE, and the page claimed Firehose carries "call traces, and balance changes". Those are extended block fields — they need an instrumented node, and we don't run one for Celo. The page now says what base blocks actually contain (transactions, receipts, logs, with cursors for resume) and states the limitation explicitly rather than leaving a reader to discover it.

Better you get that from us than from a developer who integrated expecting traces. Diff is now 3 files, +54/−1.

[GigaHierz]

Thanks for the Pinax page, and for owning the endpoint check and the base-versus-extended correction. The structure fits the other indexer pages, and mint validate, mint broken-links --check-redirects and the orphan check pass on this head, which merges cleanly into main. The hostnames and chain IDs also check out: the Firehose and Substreams hosts accept connections on 443, and the mainnet and Sepolia RPC endpoints return 0xa4ec and 0xaa044c.

A few statements need a source or a softer wording before this goes in:

1. Celo Sepolia. The Note says Firehose and Substreams are mainnet only. The Celo page on pinax.network (https://pinax.network/chain/celo) shows a "CeloSepolia" label above the Substreams, Firehose and RPC cards, so it doesn't back that up, and I can't tell which services apply to which network from it. Please link something that states the Sepolia coverage, or drop the Note and the Sepolia section's implication.
2. Unsourced claims. "maintains the open source Firehose and Substreams stack alongside StreamingFast" and "It reads history far faster than sequential RPC calls" have no source on the page, and AGENTS.md section 4 rules out unsourced superlatives and comparisons. Link a source or cut them.
3. Authentication column. SUBSTREAMS_API_KEY is the name of an environment variable, not an authentication method, so the column mixes two things. Something like "API key (set as SUBSTREAMS_API_KEY for the Substreams CLI)" would be accurate if that matches Pinax's docs. Separately, the RPC endpoints answered an eth_chainId request with no key on both networks, while the table says "API key". Please say what a keyless call gets, for example a rate limit, or confirm the key is required.
4. Pages that go stale. The endpoint hostnames and the pricing link can change without us noticing. Please link https://pinax.network/chain/celo as the canonical place for the current endpoints, and keep the table as examples.
5. CI. The broken-links check does not appear on this PR, probably because the workflow is waiting for approval on the fork. I ran it locally and it passes.

I could not run an authenticated Firehose or Substreams stream, so the authentication details are checked only against your description, not against a real stream.

[mintlify]

Preview approval required

This pull request comes from a fork, so Mintlify won't build a preview until someone with write access approves commit 1c54f4b.

Approve preview

[chillsauce]

Thanks @GigaHierz — this was a good review. Four of the five were mine to fix; pushed in 1c54f4b. Point by point:

1. Celo Sepolia — the Note is right, but the page you checked is confusing.

pinax.network/chain/celo has a tab switcher at the top, Celo / Sepolia. The "CeloSepolia" string you saw is the inactive tab's label, sitting directly above the cards belonging to the active mainnet tab. Nothing on that page tells you which services the Sepolia tab actually has — so your reading was reasonable, and the page is at fault, not you. I've opened an internal issue to make the tabs render their own service list.

The underlying coverage is RPC-only on Sepolia:

• celosepolia.rpc.pinax.network answers (0xaa044c), as you found.
• celosepolia.firehose.pinax.network and celosepolia.substreams.pinax.network do not resolve at all — no such hosts.
• The Graph's networks registry carries no Celo Sepolia network, while celo has a full firehose block.

So I've kept the Note and left the Sepolia table at RPC.

2. Unsourced claims — cut both.

"Reads history far faster than sequential RPC calls" is gone; it was an unsourced comparison and the sentence works without it. The StreamingFast co-maintenance line is replaced by a sourced one: the Substreams docs list Pinax among their providers.

While I was at it I gave the base-detail statement a source too, since it's the strongest technical claim on the page: the registry records "evmExtendedModel": false and "blockFeatures": ["base"] for Celo, which matches what sf.firehose.v2.EndpointInfo/Info returns from the live endpoint.

3. Authentication column — you're right on both halves.

SUBSTREAMS_API_KEY was a mechanism masquerading as a method; it now reads "API key; the Substreams CLI reads it from SUBSTREAMS_API_KEY".

And your keyless eth_chainId call is the more interesting one: the table said "API key" and that was simply wrong. The endpoints do answer unauthenticated requests. Those take a rate-limited anonymous path served only from Pinax's own nodes, with no fallback capacity behind them; a key gets you the full routing and per-key limits. There's now a short "Calling RPC without an API key" section saying exactly that, including the chain IDs you'd get back. Thank you for testing it rather than taking the table's word.

4. Staleness — done.

pinax.network/chain/celo is now linked at the top of the Endpoints section and in Resources, with the tables explicitly marked as examples and that page named as the one to trust if they diverge.

5. CI — understood.

I ran both locally against this head: mint validate → build validation passed, and mint broken-links --check-redirects → no broken links found. All four new external links return 200.

One thing I can't close from my side: you noted you couldn't run an authenticated Firehose or Substreams stream. If it's useful for verification I'm happy to arrange a key — otherwise the registry entry above is the closest third-party check on the streaming claims.