I’m Henrik. I run testnetradar.com, a small site publishing beginner node guides for new testnets. I’m not affiliated with Celestia and I’m not selling anything. I’ve filed five documentation fixes as issues on celestiaorg/docs and wanted to explain where they came from, and float something that may or may not be of interest.
I published a Celestia light-node guide on 2026-09-02. Writing it meant settling first-hand which Mocha is joinable (mocha-4 was scheduled for shutdown the day before, so the docs alone left a reader guessing) and then reconciling the install path against what the binaries actually do. Five things came out of that. The first is the reason I’m posting rather than just filing and moving on.
1. The documented “install latest” one-liner puts a beginner on a dead chain. Install one-liner resolves releases/latest to the mainnet build, which hardcodes mocha-4 · Issue #2586 · celestiaorg/docs · GitHub
The install page publishes:
bash -c "$(curl -sL https://docs.celestia.org/celestia-node.sh)"
Line 55 of that script resolves the version through releases/latest, which today returns v0.31.4, the mainnet build, which hardcodes Mocha Network = "mocha-4" and the mocha-4 genesis hash. So a reader who runs the one-liner and then celestia light init --p2p.network mocha is pointed at the chain that shut down on 2026-09-01.
This is structural rather than a slip. .goreleaser.yaml sets release: prerelease: auto, and every mocha tag carries a semver pre-release suffix, so GitHub marks all of them prerelease and releases/latest can never return one:
v0.32.1-mocha | PRERELEASE | 2026-09-01T15:11:25Z
v0.31.6-mocha | PRERELEASE | 2026-08-31T15:03:12Z
v0.31.4 | release | 2026-07-13T11:55:36Z <- releases/latest
The -v form on the same page works fine. It’s the bare one-liner, the one a beginner will paste, that’s wrong.
2. The version tables are a release behind. Mocha software tables are one release behind (v0.31.6-mocha vs v0.32.1-mocha) · Issue #2587 · celestiaorg/docs · GitHub
The Mocha testnet page’s software table and the install page both name v0.31.6-mocha. v0.32.1-mocha shipped 2026-09-01T15:11:25Z, the same day both pages were last updated.
3. The published systemd unit runs the wrong network. systemd light-node unit omits --p2p.network, so it runs Mainnet Beta against a mocha store · Issue #2588 · celestiaorg/docs · GitHub
The maintenance systemd page’s light-node unit has no --p2p.network. The troubleshooting page says the default network is Mainnet Beta, and nodebuilder/store.go puts the network into the store path. A reader who inits ~/.celestia-light-mocha-5 and installs the published unit gets a service running mainnet against a store it never initialised.
4. The fast-sync snippet pairs a height with the wrong block’s hash. Fast-sync snippet pairs height H with last_block_id.hash, which is the hash of block H-1 · Issue #2589 · celestiaorg/docs · GitHub
The light-node advanced page reads .result.header.height together with .result.header.last_block_id.hash. That hash belongs to block H−1, not H. Checked against the live chain: block 403054’s hash is C1478CAB…39E0, while the snippet pairs it with 75A806C5…8E07C, the hash of 403053. /block returns block_id.hash and block.header.height for the same block, which is the matched pair.
5. Two stale lines that tell a beginner to give up. Mocha page: "mocha-5 has not started yet" and "QuickNode still serves mocha-4" are both stale · Issue #2590 · celestiaorg/docs · GitHub
The Mocha page still says the mocha-5 DA network has not started yet and that the public QuickNode endpoint still serves mocha-4. On 2026-09-02 I got a mocha-5 ExtendedHeader with a real DataAvailabilityHeader back from that endpoint at height 403234, the same height as the consensus head. Both notes are just stale, but the first one reads as “don’t bother yet”.
(One more, and this one was my fault, not yours: I had /how-to-guides/… paths cached. They 404 or redirect now. Current paths are under /operate/.)
Where this came from, and what I’d like to propose.
The site has a harness that extracts every command a guide publishes and executes it in a resource-limited container, and a review box that re-runs them on a weekly timer, so a guide’s badge can’t quietly go stale when an upstream release moves. Defect 1 is exactly the failure that machinery exists to catch: nothing in the docs changed, but releases/latest moved underneath it.
What I’d like to do is point that runner at Celestia’s install path permanently: a weekly execution of your documented light-node path, with the output published, and anything that breaks filed with you before it becomes a line in my guide. Plus the beginner guide kept current as tags move, which given the prerelease behaviour above is going to keep happening.
On funding, plainly. I looked for a grants programme before writing and couldn’t find one: celestia.org/grants is a 404, the Modular Fellows pages are gone, and nothing in either sitemap mentions grants. The Foundation Delegation Program is the only funding I found, and I don’t qualify for it: it requires an active validator with significant stake, and I run a light-node guide, not a validator. I’m not going to pretend otherwise to get in the door. I did notice that “contribute to documentation and new guides and tutorials” is one of your optional criteria there, which is what made me think this was worth a post at all.
So: is there a budget line for documentation maintenance anywhere? If there is, what I’d propose costs USD 2,800 for a year, and I’d rather show the arithmetic than name a round number:
| Line | Amount | Where it comes from |
|---|---|---|
| Infrastructure, 12 months | $60 | $5.00/month, Vultr 1 vCPU / 1 GB / 25 GB SSD, priced 2026-09-02. Your published light-node spec is 500 MB RAM, one core, 20 GB, so this is genuinely all it takes. |
| Maintenance, 36 hours | $2,700 | 3 hours a month at $75/hour. That rate is mine, not a market figure. |
| Total | $2,760, asked as $2,800 |
Milestones would be: $700 for the five fixes filed and the documented path executed end-to-end for the first time; $1,400 for weekly runs through months 2 to 9 with every break reported to you inside the week; $700 for the guide kept current across tags, plus a closing report including whatever didn’t work.
And if the answer is no, the five fixes stand anyway. They’re already written and already filed. I’m not holding documentation fixes hostage to a budget conversation.
One thing I’ll say whether or not money is involved. If Celestia ever funds this, that’s a material connection and it gets disclosed on the Celestia guide itself, at the point of the claim, where a reader sees it, not buried in a policy page. My site already enforces that for affiliate commission and for free hardware, with a build gate that fails if a declared connection isn’t disclosed by name on the rendered page. A grant is the same class of thing.
And it wouldn’t buy the badge. The Celestia guide says verification: pending today, honestly, because no Celestia binary has been run in this project yet. There is no code path in my repository that writes a verification badge from a run result: the machine produces the evidence, a person makes the claim, and the artifact is published so anyone can disagree with them. Funding changes the cadence of the work. It doesn’t change what the badge is allowed to say.
Guide, if it’s useful: How to Run a Celestia Node (Beginner Guide, September 2026)
Happy to be told no on the funding and yes on the fixes. That’s the outcome I’d expect, and it’s a fine one.
Henrik
testnetradar.com, not affiliated with Celestia