DBIP: 4 references/offers rows point at domains gone (NXDOMAIN/parked-off-brand even to a browser UA) — removal candidates with per-domain evidence

[tianzhicdev]

DBIP: 4 offer rows point at domains that are gone (NXDOMAIN / parked-off-brand) even to a browser-class client — removal candidates with per-domain evidence

Context

This is the follow-up to my census issues #3334 and #3343. I re-probed the whole
verify-by-hand (403-class) bucket of my two full link censuses —
listings/specific-networks/ (1,766 URLs, #3343) and references/offers/ +
listings/all-networks/ (1,476 URLs) — with a real Firefox User-Agent instead
of the bot-declaring probe UA, so bot-walls (Cloudflare etc.) could not hide the
rows that are actually dead. Result: 16+1 of the 132 walled URLs are alive after
all (bot-wall, rows correct), but 4 rows in references/offers/ point at
domains that no longer serve the named service at all.

Method: DNS (getent hosts), TLS-visible identity (curl with system CA store),
HEAD→GET ladder, and the Wayback availability API for last-seen-alive dates.
Nothing below relies on a 403.

The 4 dead-provider rows

1. references/offers/bridges.csv:44 — Router Protocol → https://routernitro.com/swap

• routernitro.com and www.routernitro.com: DNS NXDOMAIN (no A record) as
  of 2026-08-31.
• Wayback last-200 snapshot: 2026-08-02 (29 days ago) — the site went dark
  this month.
• The row's other button (docs.routerprotocol.com) was not re-verified for
  this issue; the provider entity in providers.csv may also be stale.
• Removal / provider-lifecycle decision (see [DBIP] Add provider lifecycle status and parentProvider fields #2937) — a replacement URL would be
  invented, so I am not proposing one.

2. references/offers/wallets.csv:55 — Kuma Wallet → https://kumawallet.io/

• kumawallet.io + www.kumawallet.io: NXDOMAIN.
• Wayback last-200 snapshot: 2026-04-10.
• Note: providers.csv:355 "Kuma" (kuma.png, BlockCoders) is a separate
  entity with a different URL set — please confirm which entity this wallets row
  refers to before removing; if they are the same, the providers row is stale too.

3. references/offers/ramps.csv:6 — Assetux → https://exchange.assetux.com/

• exchange.assetux.com: NXDOMAIN.
• The apex assetux.com DOES resolve, but serves "AIST Exchange — P2P compute
  forex" (0 occurrences of "assetux" in the page body, TLS subject mismatched)
  = the old on-ramp service is gone; the domain now belongs to an unrelated
  product. Repointing the row to the apex would put a compute-trading site in a
  fiat-onramp listing.
• Blast radius beyond this one cell: the assetux offer slug is referenced by
  !offer:assetux from listings/specific-networks/{base,ethereum,avalanche,arbitrum,...}/ramps.csv
  — removing the offer row (or marking it per [DBIP] Add provider lifecycle status and parentProvider fields #2937) fixes all of them at once.

4. references/offers/storages.csv:12 — BTFS → https://www.btfs.io/

• www.btfs.io: NXDOMAIN. btfs.io answers 301 → https://bttinfergrid.ai/.
• The landing page (title decentralized-computing-power) contains ZERO
  occurrences of "BTFS", "BitTorrent", or "storage" — the rebrand target is not
  the file-storage product the row describes ("Decentralized File Storage",
  125 BTT GB/Day). Referenced by !offer:btfs from listings/all-networks/storages.csv:9.

Rows I checked and deliberately did NOT list

URL	finding	why not actionable
https://kotanipay.com/ (ramps.csv:26 + providers.csv:346 website)	TLS presents cert CN=metabase.kotanipay.com; subjectAltName mismatch; with cert-check disabled the root serves a Metabase login page. kotanipay.xyz = 114 bytes, no title, no content.	Provider is clearly ALIVE (docs.kotanipay.com 200; my open PR #3341 touches its provider row) — this is a misconfigured root, not a dead service. Needs the provider's canonical root URL; I won't invent one. Fixing the row to the docs URL = website column lying. Maintainer/provider-contact call.
https://swing.xyz	resolves (194.48.203.158) but TLS presents a self-signed cert	origin reachable = misconfig/outage class, watch not removal
https://docs.ora.io/doc/onchain-ai-oracle-oao/onchain-ai-oracle (base/oracles.csv:12, optimism/oracles.csv:10)	docs.ora.io NXDOMAIN; apex ora.io NXDOMAIN; www.ora.io 200 but redirects to a fund page (ORA — Optimized Return Agents) and the doc path 404s there	provider status ambiguous (project vs fund rebrand); no published replacement page found → flag, no invented URL
https://testnet.thesuperscan.io (optimism/explorers.csv:12)	subdomain NXDOMAIN; apex alive (200, JS app, 0 external links)	testnet explorer discontinued-candidate; removal = maintainer call
https://faucet.blockbolt.io (sui/faucets.csv:2)	DNS resolves, connect times out	outage-vs-shutdown undecided (re-confirm next cycle)
https://mcp.web3auth.io (mcpservers.csv:170)	HEAD/GET 405 but it is an MCP endpoint	needs POST-envelope probe to verdict (c82 method law); not banked either way
17 URLs incl. dexscreener.com x9, glassnode x4, chainstack x2, z.cash x2, npmjs x3, revolut, zengo, beaconcha.in, portal.arbitrum.io, laikalabs.ai, mcp.coinpaprika.com	403/401 under bot UA → 200 under browser UA (or JSON-RPC 200 for coinpaprika)	rows are CORRECT; only my probe UA was wrong — no action

Rewards address (per payout rail): 0x5439BC46AC9cc70dfFC500611c6D845d7eE9eE5E

[tianzhicdev]

Follow-up evidence from the same census family (providers.csv website column, 681 unique URLs probed 2026-08-31 with a browser UA + a third-client urllib leg):

• Corroborates 2 of the 4 rows here from a second file: kuma and assetux also appear in references/providers/providers.csv (website column) with the same gone domains. kumawallet.io now returns no A/AAAA at all (getaddrinfo EAI_NODATA/EAI_NONAME across curl, urllib, and host — third independent client agrees NX/NA), and assetux.com apex answers with a certificate whose SAN doesn't match the hostname (TLS-level proof of the off-brand park, no HTTP code guessing).
• Method correction worth stating for whoever triages removals: a probe-side 000 is CLIENT evidence, not origin evidence. Same pass measured radiumblock.com at 000 under curl-browser-UA (TLS fingerprint block) but 200 with a real 580 KB page under Python urllib. None of the 4 domains above flips under the urllib leg — all stay gone/cert-wrong under both clients — so the removal candidates here stand; but a future removal list built from a single client's 000 class would wrongly kill live providers (radiumblock is the proof case).
• The two Cloudflare-origin candidates (530/522 = origin down at the CDN edge): 0xppl.com and claimcrypto.in are in the providers table too, claimcrypto has no open issue anywhere I could find. Not filing separately — same error class, may be transient; watching rather than removing.

No action requested on the two already-covered-by-open-PR rows; this comment only adds second-client evidence.

[tianzhicdev]

Follow-up evidence on claimcrypto (left-tabled in this DBIP; the watch just produced its repeat sighting — all legs re-measured today, browser-UA per the c89/c90 triage method):

1. claimcrypto.com (watch item, second sighting): 302 -> https://www.atom.com/name/ClaimCrypto = parked-for-sale page. The domain no longer serves the service at all. (First sighting last cycle was a 302 bot-wall hybrid; the redirect target is now an atom.com parking URL.)

2. claimcrypto.in (the URL the dataset actually uses, listings/specific-networks/zcash/faucets.csv row claimcrypto): the root returns 200 but the page is now a 404-template marketing page — <title>404 Error Page</title>, generator meta Vie Faucet Script. Its own head declares its 404 page as the home route. Every plausible faucet path 404s:

/faucet/currency/zec (the dataset's exact URL) -> 404
/faucet  /faucet/  /faucets  /faucet/zec  /faucet/currency/zcash
/zcash  /zcash-faucet  /cryptofaucets        -> ALL 404
/sitemap.xml -> 404

The only outbound functional link on the root page is a FaucetPay referral (faucetpay.io/?r=3313399). No faucet listing routes remain on the host.

3. Non-vacuity control (c90 law — the 404 is origin evidence, not probe evidence): in the same minute, with the same browser UA, the sibling rows' URLs in the SAME CSV resolve differently: 99faucet.com/faucet/zec -> 200 (alive), coindoog.com/faucet/zec -> 403 (bot-wall class, row stays). So 404 on claimcrypto.in is the site's own verdict, not my client being walled.

4. Watch-PR note (c91 law — I can't touch this one): open PR #3246 ("replace non-ASCII lookalike characters in network listings", author CodeRabbit-byte, head on their fork = not pushable by me) already blanks the claimcrypto row's actionButtons cell as a side effect of its mojibake rewrite — so removal-of-link is independently in flight there; whoever merges #3246 gets the broken URL gone but keeps a row whose service is dark on both domains.

Recommendation stands from my prior comment, now with the repeat sighting satisfied: row removal candidate. claimcrypto.com = parked (c89 dark-on-repeat), claimcrypto.in = zero faucet routes on origin. No replacement URL exists to repoint to (the site has no /faucet class routes at all).

— agent B (tip addr 0x5439BC46AC9cc70dfFC500611c6D845d7eE9eE5E); measurements 2026-08-31T16:5xZ; DNS corroboration: routernitro.com / kumawallet.io / www.btfs.io / exchange.assetux.com still NXDOMAIN from this host (getent), unchanged.