docs(mesa): add Verify the Release page for package verification

[dkijania]

Adds a page that shows operators how to prove, on their own machine, that the published Mesa packages were built from the final pre-fork chain state. This is the verification part of the old upgrading-to-berkeley.md, brought up to date for Mesa. The upgrade steps themselves are not repeated — they already live under Upgrade Steps.

Where it goes

New page at docs/network-upgrades/mesa/verify-the-release.mdx, in the sidebar between Upgrade Steps and Archive Upgrade.

It is a standalone page rather than a step inside Upgrade Steps, because the procedure is optional, is not tied to a point in the fork timeline, and is aimed at exchanges and custodians who must not take a package on trust. Two existing pages now link to it:

• upgrade-steps/upgrade.mdx — resolves the TODO(PR #1133) that asked for an authoritative verification link once one existed. The previous link pointed at mina/blob/mesa/docs/upgrading-to-mesa.md, which 404s.
• upgrade-steps/post-upgrade.mdx — a tip at the top of In-Depth Validation, which covers node and archive health but not the packaged state.

What the page documents

mina-verify-packaged-fork-config, as it exists on release/mesa at scripts/hardfork/mina-verify-packaged-fork-config — not the berkeley version. The flags, checks, and environment variables were read from that script, and the example invocations follow the ones the hardfork pipeline runs in buildkite/src/Entrypoints/GenerateHardforkPackage.dhall.

The three checks are documented separately, with what each one compares and what a pass means:

Check	Compares
config	Fork-config ledger hashes against the precomputed fork block
ledgers	Ledgers exported from the packaged config against ledgers from a config you build
tarballs	RocksDB contents of packaged, self-generated, and S3-published tarballs

The page also states what the checks do not prove — fork-block integrity is a separate job for mina-archive-hardfork-toolbox — and links there.

Artifact availability, verified

Package contents were checked by downloading and unpacking the real artifacts, not read off the build scripts.

mina-mesa (4.0.0-preflight1-b649c79, verified with dpkg -c) carries everything the procedure needs except one program:

• mina-verify-packaged-fork-config, mina, mina-create-genesis, mina-hf-create-runtime-config, mina-rocksdb-scanner

The missing one is mina-create-prefork-genesis, shipped by mina-create-<network>-prefork-genesis-ledger. That package is not yet in a published apt repository; it currently exists in the build cache for all five codenames, and publishing it is planned. The page therefore also documents --reference-data-dir, which lets an operator skip that package entirely.

Docker images exist for the same procedure: gcr.io/o1labs-192920/mina-daemon, mina-archive, and mina-rosetta all carry -mesa tags for the five codenames.

Testing

npx docusaurus build passes. The only broken-anchor warnings are pre-existing ones on the Mesa index page pointing into the glossary; this PR touches neither.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs2	Ready	Preview	Aug 12, 2026 10:39pm