Nodeops

NodeOps Documentation Audit

One-line state of the docs: a sprawling two-surface documentation set (DePIN node/compute docs at docs.nodeops.network plus a separate CreateOS API/MCP surface) that is internally contradictory on the things that cost developers money — bond formulas, CU definitions, deploy domains, auth — and whose own machine-readable index points at a 404.

1. The product a developer first meets (CreateOS) is absent from the documentation they're sent to (significant)

Location: https://nodeops.network/ vs https://docs.nodeops.network/Learn

Problem: The marketing homepage pitches CreateOS — "Deploy AI-generated apps in 60 seconds — no DevOps, no Docker, no complexity." But the primary "Documentation" destination, docs.nodeops.network/Learn, defines the product as "the leading economically-secured, permissionless, DePIN coordination Protocol" and never mentions CreateOS in its navigation — it is entirely about nodes, compute bonding, staking, and tokenomics. CreateOS docs live on a completely separate surface (nodeops.network/createos/docs/...).

Consequence: A developer who arrives via the homepage expecting "deploy an AI app, no Docker" clicks Documentation and lands in a DePIN/token-staking protocol manual with no bridge back to the thing they were sold. The two surfaces share no navigation, so neither human nor AI agent can discover that CreateOS docs exist from the main docs site.

The fix: Cross-link the two doc surfaces. Add a top-level "CreateOS" entry to the docs.nodeops.network navigation pointing at nodeops.network/createos/docs, and add a one-paragraph orientation on /Learn explaining the relationship between NodeOps Network (infra layer) and CreateOS (deploy layer) that the homepage already draws.

2. The official llms.txt index advertises a FAQ URL that returns 404 (significant)

Location: https://docs.nodeops.network/llms.txt → https://docs.nodeops.network/Learn/FAQ/faq

Problem: llms.txt lists [NodeOps FAQ](https://docs.nodeops.network/Learn/FAQ/faq) as "Find answers to common questions about NodeOps Network…". Fetching that exact URL in real Chromium returns HTTP 404 / "Page Not Found." Sibling FAQ pages under the same path (e.g. /Learn/FAQ/community-rewards) return 200, so this is a specific broken entry, not a section-wide outage.

Consequence: llms.txt exists precisely so AI coding agents can index docs efficiently — and the entry for the general FAQ is a dead link. An agent following it requests the advertised URL, gets a 404 body, and either drops the FAQ entirely or ingests the "Page Not Found" text as if it were content. (Impact is bounded to one skipped page since siblings resolve — hence significant, not critical.)

The fix: Either restore the page at /Learn/FAQ/faq or remove/repoint the entry in llms.txt to the correct landing URL, and add a link-check of every URL in llms.txt to CI so the machine index can't drift from reality.

3. Case-sensitive routing means the changelog link is a coin flip (significant)

Location: https://docs.nodeops.network/changelog vs /Changelog

Problem: /changelog (lowercase) returns 404 while /Changelog (capitalized) returns 200. Routing is case-sensitive, and llms.txt/in-page references mix the two casings.

Consequence: Any link, bookmark, or agent that lowercases the path — a common normalization — lands on a 404 even though the page exists. Case-sensitive doc routes are a silent, hard-to-debug source of dead links across the whole site.

The fix: Add case-insensitive redirects (or canonical lowercased routes) for top-level doc paths, and standardize one casing convention everywhere it's linked.

4. The compute bond formula contradicts itself across three pages — per CU vs per machine (critical)

Location: /Get-Started/Cloud-Compute/Provide-Compute, /Tokenomics/node, /Learn/Ecosystem/providers

Problem: Three pages give incompatible bond rules:

• Provide-Compute: "2000 $NODE + 200 $NODE for every CU" (per Compute Unit).
• Tokenomics: "A base bond of 2,000 $NODE… An additional 200 $NODE per machine is required for each new unit added" — and this sentence is itself self-contradictory ("per machine" vs "for each new unit").
• Providers worked example: a 1/2/4-CU machine bonds "200, 400, & 800 $NODE for each machine" — i.e. 200 per CU.

So Provide-Compute and Providers agree on per-CU, while Tokenomics says per-machine — a real numerical contradiction (a 4-CU machine bonds 800 $NODE under one reading, 200 under another).

Consequence: This is staked capital. A provider budgeting from the Tokenomics page under-bonds by up to 4x, and "Failing to meet these prerequisites may result in slashing… suspension of the provider's wallet… the machine being banned." The contradiction has direct financial and account-loss consequences.

The fix: Pick one canonical formula (the worked example implies 200 × CU per machine), state it once in a single source-of-truth reference, and have the other pages link to it rather than restating it. Fix the self-contradictory "per machine / for each new unit" sentence.

5. "1 CU" is defined two different ways across the canonical pages (significant)

Location: /Reference/compute-requirements, /Learn/Ecosystem/providers, /Tokenomics/node

Problem: The Reference and Providers pages define 1CU = 1 vCPU, 2GB RAM, 30GB NVMe Disk, while Tokenomics defines 1 CU = 1 CPU, 2GB RAM, 30GB storage. "vCPU" vs "CPU" and "NVMe Disk" vs generic "storage" are not interchangeable when CU is the unit you bond against and get paid for.

Consequence: Because bond size and rewards both scale with CU, an ambiguous CU definition compounds the bond contradiction in #4 — a provider can't compute their CU count reliably, and the min() calculation shown in the Providers example depends on which resource definition applies.

The fix: Define CU once, precisely (vCPU vs physical CPU, storage class), in the Reference page and reference it everywhere CU appears.

6. The "Core mint formula" renders with no formula, and the ratio is named two ways (significant)

Location: /Tokenomics/node → "Core mint formula" and "Supply"

Problem: Two defects on the token's core mechanic:

• The "Core mint formula" section reads literally:

  Where:

  • is daily protocol revenue (USD)
  • is $NODE Token Price
  • is the Burn/Mint ratio (adjusted each epoch)

  There is no equation above "Where:", and each bullet begins with a missing variable symbol ("is daily protocol revenue" with nothing before "is"). The math markup failed to render and left only the legend.

• The same number is named inconsistently on the page: the prose calls it the "burn/mint ratio" ("Dynamic burn/mint ratio: starts at 0.2"; "initial burn/mint ratio of 0.20") while the example-cycle table header calls it "Mint/Burn Ratio."

Consequence: The token's emission/burn mechanic — central to anyone evaluating $NODE economics — is undocumented in practice (readers see definitions for variables that never appear), and the inverted "burn/mint" vs "mint/burn" naming makes it unclear which direction the 0.20→0.72 ratio moves.

The fix: Restore the actual formula (likely a LaTeX/MathJax block that didn't compile), re-attach each variable symbol to its definition, and standardize one ordering of the ratio name across prose and table.

7. Tokenomics allocation line items don't sum to the stated total supply (significant)

Location: /Tokenomics/node → Supply / allocation

Problem: Stated "Total supply at genesis: 678,833,730 $NODE." The six allocation line items (203,650,119 + 105,221,229 + 13,576,675 + 101,825,059 + 101,825,059 + 152,137,590) sum to 678,235,731, roughly 597,999 $NODE short of the stated total. (The percentages do add to 100%, which makes the token-count mismatch easy to miss.)

Consequence: A reader reconciling the cap table can't — nearly 600k tokens are unaccounted for. For a financial primitive, an allocation table that doesn't foot undermines trust and is the kind of thing exchanges and auditors flag.

The fix: Recompute the line items against the genesis total (or correct the total) so the allocation sums exactly, and add a "Total" row that displays the sum.

8. Restaker onboarding points to "the GitHub repo" with no URL (significant)

Location: /Learn/Ecosystem/restakers → "Operator onboarding"

Problem: The entire onboarding instruction is: "Please follow this link to the GitHub repo for steps to onboard as an operator on the NodeOps Network" — but no link/URL is rendered. (Separately, the Providers page at /Learn/Ecosystem/providers has its own orphaned blocks: the line "In NodeOps Network, every provider must bond:" is followed by no bond amount, and a "Failing to meet these prerequisites may result in:" list appears with surrounding empty bullet structure.)

Consequence: Restaking operators provide the network's cryptoeconomic security ("payment verification, rewards calculation, and Node score calculation"), yet the onboarding path is a dead end — there's no destination to follow. On the Providers page, the missing bond amount under "every provider must bond:" leaves the most important number blank on the page a provider reads first.

The fix: Insert the actual GitHub repository URL and expand onboarding into concrete steps, and fill in the missing bond amount on the Providers page.

9. CreateOS deployment domain contradicts itself: createos.io vs createos.nodeops.network (critical)

Location: /createos/docs/API-MCP/CreateOS-Skills vs /createos/docs/Build-Deploy/Deploy

Problem: The Skills/API page says a deployed app returns https://yourapp.createos.io. The Deploy guide says the project name "becomes your subdomain: myproject.createos.nodeops.network." Two different live-app domains for the same deploy flow.

Consequence: Developers (and agents driving the documented TriggerLatestDeployment() flow) can't know where their app actually lands, can't configure DNS/CORS/callbacks correctly, and may hit a domain that doesn't resolve. For a "deploy in 60 seconds" product, the deployed URL is the single most important output.

The fix: Verify the real deployed-app domain and use it consistently in every CreateOS doc; if both domains are valid (e.g. custom vs default), state the rule explicitly.

10. CreateOS auth story is mixed and the API key's provenance is never explained (significant)

Location: /createos/docs/API-MCP/CreateOS-Skills

Problem: The page says "When connected via MCP… no API key is required for basic operations. The MCP server handles authentication automatically," then immediately: "For direct REST API calls, use the header: X-Api-Key: <your-api-key>." There's no end-to-end explanation of where <your-api-key> comes from, when MCP auth applies vs REST, or what "handles authentication automatically" actually does.

Consequence: Developers can't tell which auth model applies to their integration, and the REST path references a key the docs never show you how to obtain. This is exactly the failure mode where a developer copies the REST call and gets 401 with no idea how to get credentials.

The fix: Add one auth section that explains both paths end-to-end: how to obtain an API key, the X-Api-Key header format, and precisely what MCP does for auth so a reader knows when no key is needed.

11. CreateOS Skills install snippet leaks UI chrome into the copyable command (minor)

Location: /createos/docs/API-MCP/CreateOS-Skills → "Installation"

Problem: The "Install CreateOS Skills with a single command" code block leaks rendering artifacts into the copyable text — a stray "Bash" language label and a "1" line-number artifact appear inside the install snippet alongside the real command npx skills add https://github.com/NodeOps-app/skills --skill createos.

Consequence: A developer or agent that copies the whole block gets a command prefixed with non-command tokens ("Bash", "1"), which fails when pasted into a shell — the same copy-paste hazard flagged in #14. Agents are especially prone to ingesting the artifacts as part of the command.

The fix: Render the language label and line numbers as non-selectable UI outside the copyable region (or strip them), so the install block yields exactly the runnable command.

12. Template schema gives two incompatible, unexplained resource notations (significant)

Location: /Reference/template-schema

Problem: The overview table tells users to specify resources Kubernetes-style as quoted strings — cpu: "500m", memory: "128Mi", with "Allowable Values" of m for millicores and Mi for memory. But every actual YAML schema and example on the same page uses bare integers — cpu: 200, memory: 400 — where cpu is millicores and memory is megabytes. The two notations are mutually incompatible and the page never reconciles them.

Consequence: Copy-paste fails either way: a developer following the table writes cpu: "500m" into a schema that expects an integer, or follows the example and contradicts the documented "Allowable Values." Agents extracting the template have no way to choose the correct form. (Severity is significant rather than critical because it's unclear whether the parser accepts both forms — the docs don't say.)

The fix: Pick one notation, convert every table cell and example to it, and delete the other; if both are accepted, document the parsing rule explicitly (e.g. integer = millicores/MB).

13. Template schema example misspells the service against its own image (minor)

Location: /Reference/template-schema → "Example Jupiter notebook"

Problem: The example names the service jupiter and titles the section "Jupiter notebook" / "Jupiter Notebook," while the image it deploys is jupyter/base-notebook. The well-known project is "Jupyter," so "Jupiter" is a misspelling repeated in the service name and headings.

Consequence: The Jupiter/jupyter mismatch breaks any search or grep that maps the documented service to the well-known Jupyter image, and reads as a typo on a Reference page developers copy verbatim.

The fix: Fix "Jupiter" → "Jupyter" throughout the heading and service name so the example matches the jupyter/base-notebook image it references.

14. Changelog mixes the new command inside the old-command code fence (significant)

Location: /Changelog → "Provider onboarding command update"

Problem: The code block is malformed — the literal text New command sits inside the old-command code fence, immediately above the new curl line:

curl -L https://get.atlasnetwork.dev | sh -s - ZxEsuA… New command curl -L https://serve-pre-mainnet.nodeops.network | sh -s - ZxEsuA…

Consequence: A provider skimming the changelog can't visually separate the deprecated command from its replacement and may run the old get.atlasnetwork.dev installer. Copy-paste of the block yields a fenced blob containing a stray "New command" line.

The fix: Close the old-command fence, render "New command" as a heading outside the block, and put the new command in its own fence.

15. Legacy "Atlas" branding and inconsistent domains survive across provider docs and the GitHub org (significant)

Location: /Changelog and https://github.com/NodeOps-app

Problem: Provider-facing commands still reference the old "Atlas" product: the install command curl -L https://get.atlasnetwork.dev | …, and log monitoring that "should now target the nn-provider service rather than the atlas service" with the old command journalctl -fu atlas*. Separately, the GitHub org landing page lists CreateOS at the typo'd domain creatos.nodeops.network (missing the second "e") and gives a contact email at a third domain, hello@nodeops.xyz, alongside nodeops.network.

Consequence: Operators copying stale commands hit the deprecated get.atlasnetwork.dev installer or watch the wrong systemd service for logs. The creatos typo sends people to a domain that won't resolve to the real createos.nodeops.network, and a third contact domain muddies which hostnames are canonical.

The fix: Audit docs and the GitHub org for atlas/atlasnetwork and the creatos typo, replace with current nodeops/nn-provider/createos.nodeops.network equivalents, and standardize on a single canonical domain in org metadata and contact info.

16. $NODE contract address shown in two different casings, presented as distinct entries (significant)

Location: /Learn/FAQ/token

Problem: The same 20-byte address is listed for Ethereum as all-lowercase 0x2f714d7b9a035d4ce24af8d9b6091c07e37f43fb, while Arbitrum and BSC are EIP-55 checksummed 0x2F714d7b9A035d4ce24af8d9b6091c07E37f43Fb. They're the same address, but the block is duplicated on the page and the inconsistent casing makes them look like separately-formatted "Contract details."

Consequence: Casing is how EIP-55 lets wallets and tooling catch typos. Presenting the same address in mixed casing across chains invites a developer to assume the addresses differ, or to distrust the lowercased one — risky on a page where a wrong paste means lost funds.

The fix: Use the checksummed (EIP-55) form consistently for all three chains, and de-duplicate the repeated contract block.

17. The no-withdrawal credits policy is a one-line callout, and payment links go nowhere (significant)

Location: /Get-Started/Pay-for-Services

Problem: The fact that credits are non-refundable is stated only in an inline callout: "When you add credits to your dashboard, they are bound there until you use them. There's no withdrawal mechanism." On the same page, the accepted stables/tokens list is hidden behind a "Show me accepted stables and tokens" control with no inline enumeration, and "Source." renders as bare text with no destination link.

Consequence: This is a money-loss policy — once you top up, you can't withdraw — buried where a paying developer can easily miss it. Meanwhile the accepted-asset list and source link don't resolve inline, so a developer can't confirm what they can actually pay with before committing funds.

The fix: Promote the no-withdrawal policy to a prominent, standalone warning near the top-up step, enumerate accepted stables/tokens inline, and fix the dead "Source." link.

18. Supported-LLMs list has broken nesting that mismatches models and descriptions (significant)

Location: /Reference/llms-supported

Problem: The markdown nesting is broken so model names and descriptions don't line up. "Llama-3.2-3B-Instruct-Q5_K_M" is buried as a sub-bullet under Qwen2.5-7B, then "Meta's Llama 3.2 model (3B parameters)" appears as a separate top-level bullet; similarly "Qwen2-0.5B-Instruct-Q5_K_M" is nested under DeepSeek while "Tiny 0.5B instruct model" floats on its own.

Consequence: A developer (or agent) reading the supported-models reference cannot reliably tell which capabilities/description belong to which model id — and the model id is exactly the string they need to pass programmatically.

The fix: Fix the list structure so each model id is a top-level item with its description bullets nested beneath it, and validate the rendered output.

19. Changelog entries are out of chronological order and stale (minor)

Location: /Changelog

Problem: Under "Apps," dates run 20250922 → 20250822 → 20250820 → 20250721 → 20250818 → 20250815 → 20250810 → 20250723 → 20250625 (the 20250818 entry is out of place), and elsewhere 20250303 precedes 20250309. The most recent entry is 2025-09-29 — roughly nine months before today (2026-06-18) — so the log reads as abandoned. There's also a typo, "gNODE withdrawl."

Consequence: A changelog that isn't sorted and hasn't updated in months erodes its core purpose: readers can't trust it to reflect the current state of a fast-moving token/protocol, and out-of-order dates make it hard to reconstruct what changed when.

The fix: Sort entries strictly by date (descending), add recent entries or a note on cadence, and fix "withdrawl" → "withdrawal."

20. Token FAQ contains errors that misinform on exchanges and reward waves (minor)

Location: /Learn/FAQ/token

Problem: Multiple defects: heading typo "Where can I lean about $NODE" (learn); exchange listed as "DigiFinix" (the exchange is DigiFinex); and the question "What is Wave-1 & Wave-2?" is answered beginning with "Wave-3: gNODE replaces the previous reward points" before it addresses Wave-1/Wave-2. The restricted-jurisdiction list (including the United States) is also buried inside an FAQ answer rather than surfaced as a standalone notice.

Consequence: A misspelled exchange name can send users searching for the wrong venue; an answer that opens with the wrong wave confuses the reward timeline; and a U.S.-resident developer can easily miss that they're barred from buying $NODE because the restriction is tucked into an FAQ answer.

The fix: Fix the typos and the exchange name, reorder the Wave answer to address Wave-1/Wave-2 first, and surface the restricted-jurisdiction list as a prominent standalone notice.

21. The same compute-requirements spec is maintained verbatim on three pages (minor)

Location: /Reference/compute-requirements, /Get-Started/Cloud-Compute/Provide-Compute, /Learn/Ecosystem/providers

Problem: The "Machines must…" requirements block (CPU ≥2, RAM ≥4GB, ≥80GB NVMe, ≥1Gbps, ≥99% uptime, Debian 12+/Ubuntu 22.04+, kernel 6.7+) is duplicated across all three pages, each maintaining its own copy.

Consequence: This is the drift mechanism behind findings #4 and #5 — three independent copies of the same spec guarantee they'll eventually disagree (as the CU definition already does). When requirements change, one copy gets missed.

The fix: Keep the spec in the single Reference page and have the Get-Started and Ecosystem pages transclude or link to it instead of restating it.

22. CreateOS Deploy guide shows "Option 2" with no "Option 1," and the org links a sunsetted Staking Hub (minor)

Location: /createos/docs/Build-Deploy/Deploy and https://github.com/NodeOps-app

Problem: Under "Deploying via GitHub Repository," the text says it "supports both AI-assisted and manual configuration modes," then jumps straight to "#### Option 2: Manual Configuration" — there is no "Option 1." (The input URL /createos/docs/Deploy also silently redirects to /createos/docs/Build-Deploy/Deploy, indicating recently moved doc paths.) Separately, the GitHub org links $NODE staking to portal.nodeops.network/stakinghub, although the changelog indicates the Staking Hub was sunsetted and folded into the Portal.

Consequence: Readers look for the missing "Option 1" (the AI-assisted mode) and find no heading for it; the AI-assisted path the intro promised is effectively undocumented. The stale stakinghub link sends stakers to a sunsetted destination.

The fix: Label the AI-assisted mode as "Option 1" with its own steps, and update the GitHub org's staking link to the current Portal route.

23. UNO incentives page has an orphaned reward callout embedded mid-list (minor)

Location: /Guides/Community-Incentives/uno

Problem: Inside the bulleted list of UNO holder utility, a "UNO rewards have dropped" callout is embedded mid-list between the "Platform access and discounts" and "Favourable unlocks" bullets, breaking the list structure: "UNO rewards have dropped / Each UNO NFT grants access to one 2CU machine to allow you to farm its workload rewards in gNODE."

Consequence: The callout reads as a stray list item rather than a distinct announcement, so the actual reward mechanic (a 2CU machine per NFT to farm gNODE) is easy to misread as just another utility bullet rather than the headline incentive.

The fix: Pull the "UNO rewards have dropped" callout out of the utility list into its own clearly-formatted notice, and keep the utility bullets as a clean, parallel list.

What they do well

• A machine-readable llms.txt index exists and is well-organized by topic — the right instinct for agent-consumable docs (it just needs its links validated, per #2).
• Provider economics include concrete worked examples (the CU min() calculation, the 200/400/800 bond scaling) — when consistent, these are exactly the kind of copy-able math developers need.
• Consequential policies are at least stated somewhere (credits are non-refundable, restricted jurisdictions, slashing risks) rather than omitted — the problem is placement and consistency, not absence.

Top 3 recommendations

1. Establish one source of truth for the money-critical specs — the bond formula and the CU definition — in the Reference section, and have every other page link to it instead of restating it (fixes #4, #5, #21).
2. Bridge the two doc surfaces and validate every link — connect docs.nodeops.network and nodeops.network/createos/docs in navigation, add case-insensitive redirects, and CI-check every URL in llms.txt so the FAQ 404 and /changelog casing trap can't recur (fixes #1, #2, #3).
3. Make CreateOS docs copy-paste-safe for humans and agents — settle the deployed-app domain, document the MCP-vs-REST auth flow end to end, fix the template schema's contradictory resource notation, and strip UI chrome from install snippets (fixes #9, #10, #11, #12).