The socket nothing was watching, and a 500 that should have been a 404

Two fixes for defects found after the multichain release went live, and the gate
that stops one of them recurring.

The live socket was refused for every real browser, and nothing saw it. The
overlay rejects a WebSocket upgrade whose Origin is not on its allowlist. The
deployed overlay had no allowlist configured, which under NODE_ENV=production
refuses every origin with 403. A handshake sent with no Origin header at all
is allowed, and that is exactly what curl sends, so every probe reported the
socket healthy while the frontend reconnected in a loop and fell back to its
fifteen second poll.

Pages stayed correct throughout, because the poll keeps the freshness reading
honest and the status rail reports when it last observed the chain rather than
claiming to be live. So this was wasted reconnects and console noise rather
than a page that lied. It was still invisible, and that is the part worth
fixing: a check that talks to a service differently from the way a browser does
can report health the browser never sees. The cutover now sends a handshake
carrying a browser Origin and refuses the release on anything but 101.

An unknown block hash answered 500 instead of 404. Bitcoin Core reports a
hash it does not know as the message "Block not found" rather than as a status,
and the backend turned that into a server error. The overlay's search asks the
block route about every 64 character hex query in order to decide whether it is
a block, so a 500 there made search report the entire Bitcoin chain as
unavailable, on every transaction search, while Bitcoin was healthy and had
already answered definitively. It answers 404 now, matching the convention the
transaction routes in the same file already used.

Both are the same shape, and it is worth naming because it accounts for most of
what was found on release day: somewhere, "I do not know" and "I know, and the
answer is no" were the same value. A missing Origin read as permission. A
definitive negative read as a failure.

What each chain can answer, at publication

Read from /api/v1/chains at 2026-08-29T13:16Z, which is where the live answer
always is. This will go stale and the pages will not.

Bitcoin. Unregressed and at the tip. The Ord authority behind Ordinals,
Rare Sats and Runes is rebuilding its index, so protocol coverage reports
unavailable and every page that uses it states how far behind it is.

Zcash. Fully ready, with Zerdinals, ZRunes and ZRC-20 all reporting ready
and complete coverage, and no degraded reasons. Two defects behind that were
fixed the same day: a synced node reporting itself as still downloading for most
of every block interval, and readiness being withheld by five separate facts
while the reason list was derived from only one of them, so a chain could
withhold readiness and publish an empty list of reasons. A chain that cannot
say why it is not ready is worse than one that is not ready.

Dogecoin. The pending set is live and complete. Confirmed history, address
history and all protocol families remain unavailable: the ord-dogecoin
authority is backfilling a large index and the Doge TAP authority cannot build
against it until their tips agree. The overview states each of these per
protocol rather than showing an empty result as an answer.

Verifying this build

curl -s https://explorer.bitcoinuniverse.io/resources/config.js | grep GIT_COMMIT_HASH
curl -s https://explorer.bitcoinuniverse.io/api/v1/backend-info
curl -s https://explorer.bitcoinuniverse.io/api/v1/chains

The frontend and the backend both publish the commit they were built from, and
they must agree with the tag on this release.

Universe Explorer becomes a three-chain explorer

Until now this explorer read one chain. It reads three.

Dogecoin and Zcash are first-class alongside Bitcoin: the chain selector
switches the whole product, each chain has its own overview, pending set,
transaction, block, address, outpoint and protocol pages, and search runs
against the chain you are on or across all three when you ask it to. Saved
pages and recently viewed items keep the chain and network they came from, so
a Dogecoin address and a Bitcoin one can never be confused for each other.

Chains are not interchangeable, and the product does not pretend they are.
Each chain declares what it can answer at /api/v1/<chain>/status, and the
overview page renders that declaration rather than offering a page for a lookup
the indexer never claimed. Neither Dogecoin nor Zcash offers projected blocks,
and both say so.

• Dogecoin fees are quoted per kilobyte. Nothing is relabelled as sat/vB.
• Zcash fee guidance follows ZIP-317 logical actions, because a transaction's
  cost there is not a function of its byte size.
• Only the transparent side of Zcash is public, and that is a boundary rather
  than a gap. A Zcash page reports the shape of the shielded side and the one
  amount the chain itself makes public. It never infers a shielded sender,
  recipient, or amount.
• Object identifiers do not carry between chains. Switching chains from an
  object page lands on that chain's overview and says why.

Live transport. Chain pages subscribe to their chain's stream and update as
blocks and pending transactions arrive, rather than only on a timer. See the
status section below: this did not work for real browsers until a defect found
after cutover was fixed.

The gateway fix this release depends on. The frontend calls
/api/v1/chains and the /api/v1/bitcoin, /api/v1/dogecoin and
/api/v1/zcash route families, all of which the overlay owns. The gateway was
still sending everything outside /api/v1/universe to the Bitcoin backend, so
every one of those requests answered 404 while the site itself loaded. The
overlay-owned prefixes are named explicitly now, lookalike paths such as
/api/v1/chainstats stay on the backend, and the route table is recorded in
docs/operations/DEPLOYMENT.md and held by scripts/universe/gateway.test.mjs.

Unchanged, and deliberately so. First-party data only: no third-party
blockchain API, hosted indexer, analytics service, or remote font, on any
chain. No accounts, no trackers. Saved state stays in the browser. The source
of the running deployment is published at /source and its commit at
/api/v1/backend-info.

Protocol coverage on the new chains

The registry records Doginals, DRC-20 and Doge TAP on Dogecoin, and Zerdinals,
ZRunes and ZRC-20 on Zcash. Each chain's overview reports the state of each
indexer, including how far behind the chain tip it is. Where an authority is
not answering, the page says that rather than reporting an empty result as an
answer.

Verifying this build

The deployment publishes its own commit. Check it against the tag:

curl -s https://explorer.bitcoinuniverse.io/resources/config.js | grep GIT_COMMIT_HASH
curl -s https://explorer.bitcoinuniverse.io/api/v1/chains | head -c 400

What each chain can actually answer, at publication

The sections above describe what this release makes possible. This is what the
three chains were reporting at 2026-08-29T09:13Z, read from
/api/v1/chains, which is where the live answer always is. It will change, and
the pages track it rather than this text.

Bitcoin. Unregressed. Block, transaction, address and outpoint reads are
complete and at the tip. The Ord authority behind Ordinals, Rare Sats and Runes
is rebuilding its index, so protocol coverage reports as unavailable and every
page that uses it says how far behind it is. Readable is not the same as
current, and nothing here presents a rebuilding index as a live one.

Zcash. Fully live, including all three protocol families. Zerdinals, ZRunes
and ZRC-20 all report ready with complete coverage, one block behind the tip.
Shielded structure is reported without shielded participants, which is a
boundary rather than a gap.

Dogecoin. The pending set is live and complete. Confirmed history, address
history and all three protocol families are unavailable: the ord-dogecoin
authority is in an index recovery that must not be interrupted, and the Doge TAP
authority cannot build against it while it is down. The overview page states
each of these per protocol rather than showing an empty result as an answer.
Dogecoin block and address pages will report that the authority is unavailable
until that recovery completes.

One defect found and fixed after cutover, worth recording because no check saw
it: the live WebSocket was refused for every real browser. The overlay rejects
an upgrade whose Origin is not allowlisted, the deployed overlay had none
configured, and a handshake sent without an Origin header is allowed, which is
exactly what curl sends. Every probe reported the socket healthy while the
frontend reconnected in a loop and fell back to its fifteen second poll. Pages
stayed correct throughout, because the poll keeps the freshness reading honest,
but live transport was not live until it was fixed. A cutover gate that sends a
browser handshake and requires 101 now holds it.

---

Superseded on 29 August 2026 by universe-2026.08.29.2. This release is 8f6005ae0, which is no longer what production serves. Everything described above is still in the product; the status section is a reading taken at 09:13Z and the per-chain picture has changed since, notably Zcash, which is now fully ready. /api/v1/chains is where the live answer is.