Sample audits · Earlier documentation audits

Helius Gatekeeper documentation, June 2026

Helius Gatekeeper Documentation — Independent Review. Published in full as delivered; only internal notes and delivery correspondence were removed.

AuditedHelius Gatekeeper documentation
Date11 June 2026
How it ranearlier documentation audit; severities are as rated in that report and were not re-rated
Re-check, 11 October 20268 unchanged, 1 fixed, 3 partly fixed

Related: Helius docs: pages changed or added since May

2
Critical or High as first rated
7
Medium as first rated
3
Low as first rated
0
Informational as first rated

Severities as published in our original report; these findings were not re-reviewed by hand the way the sample audits were. The 11 October 2026 re-check status is shown under each finding where it maps.

Prepared for: Helius, Developer Documentation team Date of review: 2026-06-11 Revision: v2 (2026-06-11) — counts and one verification statement corrected after independent re-verification of every finding against the live publication (F-1 second-occurrence characterization, F-2 occurrence count, F-3 endpoint-form counts, F-9 index-content description); no findings added or removed, severities unchanged Documents reviewed: Helius Gatekeeper publication surface as it stands at the date of review — 6 documents totaling ~48 KB:

Review type: Documentation quality, correctness, and developer-integration-readiness assessment focused on the Gatekeeper edge-gateway publication surface and its cross-document consistency with adjacent announcement content.

Relationship to prior review. This is a focused review of the Gatekeeper sub-surface that was outside the scope of the 2026-05-28 broader Helius API documentation review. The Gatekeeper section received only incidental coverage in that earlier work; this is a dedicated pass.

Executive summary

The Gatekeeper publication surface is small (6 documents) and the announcement is clearly written. The vendor migration story is well-served: a developer reading the migration guide can move to the Gatekeeper Beta endpoint in under five minutes, and the rollback path is explicit. The performance pitch in the announcement blog includes concrete cold-vs-warm latency comparisons with a methodology link. The corpus is strong on these dimensions:

The corpus carries 12 findings across the documentation quality dimensions reviewed.

Documentation is usable for integration and the Gatekeeper Beta endpoint is straightforwardly adoptable. No finding rises to a security-critical or integration-blocking severity. The two highest-priority items are both publishing-pipeline hygiene issues that affect downstream agent / mirror / automated consumers more than human browser readers: a malformed JavaScript code recipe in the Enhanced WebSockets announcement blog (F-1), and a class of internal links across the documentation pages that are correct when rendered to HTML but broken when the same files are consumed as raw markdown (F-2). Both are vendor-side cosmetic-to-publishing-pipeline fixes — neither prevents a developer from successfully integrating Gatekeeper.

Top-priority items requiring attention:

SeverityCountHighest-impact findings
Critical0—
High2F-1: malformed JavaScript code recipe in the Enhanced WebSockets blog (fails at parse with SyntaxError: Invalid or unexpected token); F-2: a class of internal links in the documentation files resolve correctly in browser-rendered HTML but return HTTP 404 when followed from the published raw-markdown form
Medium7F-3 (trailing-slash convention inconsistency across the canonical endpoint URL); F-4 (acronym gTFA never expanded); F-5 (performance benchmark provenance via personal gist); F-6 (Chinese-language pages link to English-only destinations); F-7 (Chinese localization covers documentation pages but not announcement blogs); F-8 (announcement blogs excluded from the sitemap); F-9 (documentation-index banner directs to a known-incomplete index)
Low3F-10 (cross-document supported-endpoints wording variance); F-11 (relative-temporal rollout-plan anchor decays silently); F-12 (WebSocket recipe in the canonical reference document lacks production-grade event handlers)

Methodology

The review was a systematic read-through of every file in the local mirror, applying a documentation-quality checklist for vendor-published API surfaces, with extensions for the Mintlify authoring platform, multi-language documentation (English + Chinese), and announcement-blog content as a distinct publication class adjacent to reference documentation. The checklist covered:

Each finding was severity-graded against developer-impact criteria:

Substrate verification was mechanical and reproducible: curl for HTTP-status confirmation on the live publication; grep over the local mirror for cross-document URL and link variance counts; ES-module-aware Node parse validation for JavaScript code-fence syntactic correctness; live HTML comparison vs raw-markdown form for the internal-link integrity finding.

Finding IDs (F-1 through F-12) are opaque sequence numbers with no semantic content outside this report.

Findings

High

F-1 — Malformed JavaScript code recipe in the Enhanced WebSockets announcement blog

Unchanged Re-check of the published text, 11 October 2026.

Category. Code correctness — vendor-published recipe fails syntactic validation Affected document. blog/introducing-next-generation-enhanced-websockets (lines around 147-167, and again around 196-201)

Observation. The blog publishes a complete production-positioned recipe ("Monitor New Raydium Launchpad Pools") in JavaScript using the Enhanced WebSockets endpoint. Two regions of the code fence are malformed across multiple lines:

  1. Around line 147, the constant declaration is split across an unintended newline with the string literal opening on its own line:
   const
   RAYDIUM_LAUNCHPAD_PROG
   = '
   LanMV9sAd7wArD4vJFi2qDdfnVhFxYSUg6eADduJ3uj
   ';
  1. Around line 196, an analogous spurious linebreak appears before the accountKeys.map statement (a stray newline-plus-indent inside the message handler). This second occurrence is syntactically harmless on its own — JavaScript tolerates the break — but it is the same pipeline artifact and visually corrupts the recipe.

Executing the published code fragment fails immediately at the parse stage with SyntaxError: Invalid or unexpected token; the fatal error is the multi-line single-quoted string literal in item 1 (a single-quoted string cannot span lines) — the error is reported before module resolution, so it is independent of whether the ws dependency is installed. (Verification note: because the snippet begins with an import statement, Node 22's module auto-detection makes bare node --check silently pass it; use node --input-type=module --check < snippet.js, or save as .mjs and run node --check, both of which correctly report the error.) The code as published will not compile, and a developer following the blog's "getting started" path by copy-paste will receive a syntax error at module load before any Gatekeeper-related behavior is exercised.

The root cause is almost certainly publication-pipeline (Mintlify or CMS post-processing) introducing spurious linebreaks into the code fence rather than authoring error in the source. The same recipe rendered with the correct single-line constant declaration would compile cleanly.

Developer impact.

Recommendation.

Fix the rendered code fence so the constant declaration appears on a single line:

const RAYDIUM_LAUNCHPAD_PROG = 'LanMV9sAd7wArD4vJFi2qDdfnVhFxYSUg6eADduJ3uj';

Add a pre-publication step that syntax-validates every JavaScript code fence in published blog content and fails the publish on error. The gate must be ES-module-aware: bare node --check silently passes import-leading snippets on Node 22+ (it only checks CommonJS sources), so use node --input-type=module --check < fence.js or write fences to .mjs files before checking. Apply the analogous syntactic-validation step for Python (python -c "compile(open('x').read(),'x','exec')"), Rust (rustc --emit=metadata), and shell (bash -n) code fences across the publication pipeline.

F-2 — Internal links in documentation pages return 404 when followed from the published raw-markdown form

Fixed Re-check of the published text, 11 October 2026.

Category. Link integrity — selective-working-surface Affected files. docs/gatekeeper/overview (3 links), docs/gatekeeper/migration-guide (1 link), Chinese localization equivalents (3 + 1 links) — 8 occurrences in the Gatekeeper sub-surface alone; likely far more across the broader documentation corpus

Observation. The Gatekeeper documentation pages contain internal links of the form [LaserStream endpoints](/laserstream/grpc#mainnet-endpoints) — root-relative paths missing the /docs/ prefix. The Mintlify-rendered HTML for the same page rewrites these links to /docs/laserstream/grpc#mainnet-endpoints before serving, so a human reader navigating the rendered documentation in a browser follows the rewritten link and arrives at the correct page. The published raw-markdown form, however (which Helius itself invites consumers to fetch via the documentation-index banner at the top of every page), preserves the unrewritten /laserstream/grpc#mainnet-endpoints form.

Verification — comparing the live HTML and the live raw-markdown:

$ curl -sL https://www.helius.dev/docs/gatekeeper/overview \
    | grep -oE 'href="[^"]*laserstream[^"]*"' | head
href="/docs/laserstream/grpc#mainnet-endpoints"

$ curl -sL -o /dev/null -w "%{http_code}" \
    "https://www.helius.dev/laserstream/grpc"
404

$ curl -sL -o /dev/null -w "%{http_code}" \
    "https://www.helius.dev/docs/laserstream/grpc"
200

The same broken-when-raw / working-when-rendered pattern appears in 8 link occurrences across the 4 Gatekeeper documentation pages (the Chinese pages carry the same root-relative form with a /zh/ prefix, equally missing the /docs/ prefix). The pattern is consistent enough across the substrate that the issue is almost certainly an authoring convention (root-relative without /docs/ prefix) combined with HTML-renderer-only link rewriting — not a per-file mistake.

The documentation-index banner at the top of every page reads:

> Documentation Index
> Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

which explicitly invites agent / mirror / automated consumers to use the raw-markdown form as the authoritative surface — exactly the surface where these links are broken.

Developer impact.

Recommendation.

Either (a) rewrite the link path values in source markdown to include the /docs/ prefix consistently:

- [LaserStream endpoints](/laserstream/grpc#mainnet-endpoints)
+ [LaserStream endpoints](/docs/laserstream/grpc#mainnet-endpoints)

or (b) configure the Mintlify .md export to apply the same /docs/ prefix rewrite that the HTML renderer applies. Option (a) is more portable and reduces the gap between the two surfaces. The pattern likely repeats across the broader documentation corpus — a bulk grep -rE '\]\(/[a-z]+/' scan over the full markdown tree will surface every instance.

Until fixed, every published .md file that contains internal-link path values is unreliable for non-browser consumption, undermining the publisher's intent in supporting .md-form fetching at all.

Medium

F-3 — Trailing-slash convention inconsistency across the canonical Gatekeeper endpoint URL

Unchanged Re-check of the published text, 11 October 2026.

Category. Cross-document URL canonicity Affected files. All 6 documents in the Gatekeeper sub-surface

Observation. The canonical Gatekeeper endpoint URL is documented in two non-identical forms across the 6 documents:

Both forms route correctly (Solana RPC client libraries normalize the URL), but a developer who reads the overview and the migration guide side-by-side sees inconsistent canonical form. The same inconsistency repeats for the mainnet.helius-rpc.com URL across the same files.

Recommendation. Choose one canonical form (the with-slash form matches the blog usage and the legacy convention in Helius SDK examples) and apply it uniformly across the 6 files. A single-line sed pass over the Gatekeeper documentation files will normalize the substrate.

F-4 — Acronym gTFA used as canonical example but never expanded

Unchanged Re-check of the published text, 11 October 2026.

Category. Documentation terminology hygiene Affected files. blog/introducing-gatekeeper, docs/gatekeeper/overview (2 occurrences), Chinese localization equivalents (2 occurrences)

Observation. The acronym gTFA appears 5 times across the substrate as the canonical example of "Helius-specific RPC endpoints" in the supported-methods enumeration. The acronym is never expanded anywhere in the substrate. A grep for the most likely intended expansion (getTransactionsForAddress) returns zero matches across the Gatekeeper sub-surface. Chinese-language readers see the acronym in the same un-expanded form in the translated documents.

Developer impact. Readers unfamiliar with the Helius enhanced-transactions surface cannot identify what gTFA references; the bare acronym serves no exemplary function for the unfamiliar audience.

Recommendation. Replace the first occurrence per file with the expanded form: getTransactionsForAddress (gTFA). Subsequent occurrences may use the acronym. Apply the same in the Chinese localization (the English-form expansion plus translated context).

F-5 — Performance benchmark provenance via personal gist

Unchanged Re-check of the published text, 11 October 2026.

Category. Source durability for marketing-grade benchmark claims Affected file. blog/introducing-gatekeeper (line around 93)

Observation. The cold-vs-warm connection timing tables that are the load-bearing performance claim of the announcement (showing 4.6× cold-connection speedup and 7.8× warm-connection speedup) are sourced via the inline link:

Source: A full breakdown of getSlot timing details
https://gist.github.com/0xIchigo/4cabc8b01802a9a3767a72c92e13eeae

The cited gist is hosted on an individual GitHub user's personal account, not within the helius-labs GitHub organization. Gists are:

The 4.6× and 7.8× multipliers are quotable headline numbers; their durability depends on a personal gist URL remaining live and un-edited indefinitely. This is a publishing-provenance issue, not a measurement-correctness claim — the numbers may be entirely accurate today.

Recommendation. Republish the benchmark measurements at a helius-labs-owned URL — for example github.com/helius-labs/benchmarks/gatekeeper-getSlot.md or helius.dev/benchmarks/gatekeeper-getSlot.json — including reproducible methodology, raw measurement output, and measurement-rig configuration. The personal gist can remain as a complementary detailed breakdown reference but should not be the primary citation for the headline numbers.

F-6 — Chinese-language pages link to English-only destinations

Unchanged Re-check of the published text, 11 October 2026.

Category. Internationalization — cross-locale link targets Affected file. docs/zh/gatekeeper/overview (2 occurrences around lines 276 and 280)

Observation. The Chinese-language overview page contains call-to-action cards at the bottom with href values pointing to English-locale URLs:

<Card title="尝试 Gatekeeper" icon="rocket"
      href="https://www.helius.dev/docs/gatekeeper/migration-guide">
<Card title="了解 Gatekeeper" icon="book"
      href="https://www.helius.dev/blog/introducing-gatekeeper">

A reader who is consuming the Chinese localization and clicks the "Try Gatekeeper" card lands on the English migration guide rather than the Chinese version (/docs/zh/gatekeeper/migration-guide, which exists and is reachable). The "Learn About Gatekeeper" card unavoidably lands in English because the blog has no Chinese translation (see F-7), but the migration-guide card could be locale-correct.

Recommendation. When generating the Chinese-locale version of each page, rewrite same-domain href values to the corresponding Chinese-locale path where one exists. For destinations that exist only in English (the blog cards), add a "translation not available — English content shown" tooltip or banner so the reader is not surprised by the language switch.

F-7 — Chinese localization covers documentation pages but not announcement blogs

Partly fixed Re-check of the published text, 11 October 2026.

Category. Internationalization — content-class coverage gap Affected files. blog/introducing-gatekeeper, blog/introducing-next-generation-enhanced-websockets (no Chinese versions exist)

Observation. The documentation pages have Chinese parallels (docs/zh/gatekeeper/overview and docs/zh/gatekeeper/migration-guide, both substantively translated). The two announcement blog posts have no Chinese parallels:

$ curl -sL -o /dev/null -w "%{http_code}" \
    "https://www.helius.dev/zh/blog/introducing-gatekeeper.md"
404
$ curl -sL -o /dev/null -w "%{http_code}" \
    "https://www.helius.dev/zh/blog/introducing-next-generation-enhanced-websockets.md"
404

The translation effort is gated to documentation-class content; announcement / blog / detailed-architectural content remains English-only. A Chinese-speaking integrator who reads the documentation in Chinese and then clicks "Read our blog" (per F-6) reaches English content. The 4.6×/7.8× performance numbers, the architectural rationale, and the integration recipe in the Enhanced WebSockets blog are unavailable in Chinese.

Recommendation. Either (a) extend localization coverage to blog content (matching the documentation-page parity policy), OR (b) publish an explicit per-content-class translation-policy statement so readers know blog content is English-only by design, OR (c) auto-redirect /zh/blog/* requests to the English equivalent with a "translation not available; English content shown" banner.

F-8 — Announcement blogs excluded from the sitemap and from llms.txt

Partly fixed Re-check of the published text, 11 October 2026.

Category. Discoverability — content-class indexing gap Affected files. docs/sitemap.xml, docs/llms.txt, blog posts (not indexed)

Observation. The sitemap.xml indexes 4 Gatekeeper documentation URLs (2 English + 2 Chinese) but no blog URLs across the entire www.helius.dev site:

$ curl -sL https://www.helius.dev/docs/sitemap.xml | grep -ic blog
0
$ curl -sL https://www.helius.dev/docs/sitemap.xml | grep -ic gatekeeper
16

The llms.txt similarly does not enumerate blog content. An agent or automated tool that uses the sitemap or llms.txt as its discovery surface — per the documentation-index banner's explicit direction — cannot discover the introducing-gatekeeper announcement at all. Yet that announcement is the primary source for the performance claims, the architectural rationale, and the supported-surfaces enumeration that an integrator needs.

Recommendation. Add /blog/* URLs to sitemap.xml (Next.js sitemap generation should include blog routes; this may be a one-line configuration change). Extend llms.txt to enumerate consumer-relevant blog announcements as a separate section. Both changes also benefit search-engine indexing.

F-9 — Documentation-index banner directs to an index that does not enumerate the page itself

Partly fixed Re-check of the published text, 11 October 2026.

Category. Banner correctness / self-referential discoverability Affected files. All 4 documentation pages in the Gatekeeper sub-surface (English + Chinese)

Observation. Every Gatekeeper documentation page begins with the 3-line blockquote banner:

> Documentation Index
> Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

The banner explicitly directs the reader (or agent) to llms.txt as the discovery surface. Per the prior review of the broader documentation corpus (2026-05-28), llms.txt enumerates a small subset of the actual published documentation surface (the vendor's own llms-full.txt says so: "Per-product llms.txt files (LaserStream, Sender, RPC, DAS, etc.) will land in follow-up PRs and be appended below."). For the Gatekeeper sub-surface specifically, llms.txt mentions Gatekeeper only as two Beta endpoint URLs in its endpoints section (https://beta.helius-rpc.com/?api-key=… and the corresponding wss:// form); the Gatekeeper documentation pages themselves (/docs/gatekeeper/overview, /docs/gatekeeper/migration-guide, and their Chinese equivalents) are not enumerated anywhere in the index — the banner directs an agent to an index where the page it is on does not appear.

The banner therefore actively directs the agent audience away from the canonical discovery surface (the sitemap, which does enumerate the Gatekeeper pages) toward an index that omits them.

Recommendation. Either (a) complete the llms.txt index per the vendor's published commitment before keeping the banner active, OR (b) replace the banner reference with "Browse via sitemap at /docs/sitemap.xml" (the sitemap is reasonably complete for the documentation surface), OR (c) remove the banner entirely until the index it points to is comprehensive.

Low

F-10 — Cross-document supported-endpoints list wording variance

Unchanged Re-check of the published text, 11 October 2026.

Category. Cross-document consistency for shared technical content Affected files. blog/introducing-gatekeeper (lines ~122-133), docs/gatekeeper/overview (lines 35-43 and 252-254)

Observation. The list of Gatekeeper-supported surfaces appears in three places — the announcement blog, the documentation overview's "Supported Methods" section, and the documentation overview's FAQ answer — with three non-identical wordings of the same underlying fact.

For example, the WebSocket support claim renders as:

The three forms are equivalent in meaning; a careful reader reconciles them. An integrator cross-referencing three pages to confirm the Enhanced WebSockets support claim sees minor verbiage drift and must decide which form is canonical.

Recommendation. Extract the supported-surfaces enumeration to a single source-of-truth (a Mintlify shared snippet or include directive), then reference it from all three places. This is the standard single-source-with-references fix for cross-document consistency.

F-11 — Rollout-plan relative-temporal anchor decays silently

Unchanged Re-check of the published text, 11 October 2026.

Category. Temporal-anchor authoring hygiene Affected file. docs/gatekeeper/overview (lines around 227-231)

Observation. The "Rollout Plan" section lists three timeframes with no absolute-date anchoring:

* Now: Public beta available to all users
* Coming Weeks: Additional optimizations and performance improvements
* Coming Months: Gradual migration of all traffic to Gatekeeper as the default

The announcement blog publishes with a date frontmatter (2026-02-11), giving its "Today" claim a concrete anchor. The documentation overview's "Now" floats. Four months after the original publication, "Coming Weeks" is ambiguous: did the optimizations land? Are we past the "Coming Months" milestone? A reader returning to the page in 2027 will have no way to assess the freshness of the rollout commitments.

Recommendation. Replace relative-temporal anchors with anchored-date language: "As of February 2026: public beta. Targeting Q3 2026 for default-traffic migration milestone." Or add a per-section Last reviewed: stamp at the file header so re-readers can assess decay.

F-12 — WebSocket recipe in the canonical reference document lacks production-grade event handlers

Unchanged Re-check of the published text, 11 October 2026.

Category. Recipe production-readiness Affected file. docs/gatekeeper/overview (lines around 129-155)

Observation. The WebSocket recipe in the documentation overview registers only two of the standard WebSocket event handlers — open and message — and uses the production-positioned commitment: 'confirmed'. The recipe omits:

The companion recipe in blog/introducing-next-generation-enhanced-websockets (the Raydium Launchpad example, in the lines around 209-213) DOES include all three: error handler, close handler, and a 30-second heartbeat ping. Within the same vendor's same Gatekeeper publication surface, the canonical reference document carries the less production-ready recipe; an integrator who reads the canonical reference and copy-pastes ends up with the inferior pattern.

Recommendation. Add the error handler, close handler with reconnect-on-drop, and heartbeat ping to the documentation-overview WebSocket recipe so it matches the production-grade pattern shown in the announcement blog. Better still: extract the canonical WebSocket recipe to a single source-of-truth snippet and reference it from both pages so the two never drift.

Closing note

The Gatekeeper publication surface is small, the migration story is clear, and the announcement is well-written. The two High-severity items (F-1, F-2) are both publishing-pipeline issues — neither requires authoring effort beyond fixing the pipeline and the affected substrate. The Medium-severity items concentrate on cross-document consistency, internationalization coverage, and discoverability infrastructure — all addressable through publishing process refinements rather than per-page authoring.

The strongest opportunities for ongoing investment are: (1) extending the localization policy to the announcement blog tier so the Chinese-speaking audience has equivalent access to the architectural rationale (F-7), (2) closing the discoverability gap that excludes the announcement blog from the agent-readable index (F-8, F-9), and (3) tightening the publishing pipeline so vendor-published recipe code is syntactically validated before publish (F-1) and so the raw-markdown form is link-equivalent to the rendered HTML form (F-2).

None of the findings block adoption of the Gatekeeper Beta endpoint by a developer with conventional integration discipline. The verdict of PASS WITH NOTES reflects that posture: the corpus is fit for purpose, with corrective recommendations.

*Independent documentation review prepared 2026-06-11; revision v2 issued 2026-06-11 after independent re-verification of all findings (corrections: F-1 second-occurrence characterization + ES-module-aware verification method and pipeline recommendation, F-2 occurrence count 6 → 8, F-3 endpoint-form counts 13/19 → 12/16, F-9 index-content description). Substrate is a local mirror of the Helius Gatekeeper publication surface as it stood at the date of review. Mechanical verification commands and substrate counts are reproducible against the live www.helius.dev publication.*