Request: delete 7 servers under network.tenzro (publisher no longer controls the verifying domain)

Request

Please mark all versions of these seven servers deleted:

• network.tenzro/tenzro
• network.tenzro/tenzro-canton
• network.tenzro/tenzro-chainlink
• network.tenzro/tenzro-ethereum
• network.tenzro/tenzro-layerzero
• network.tenzro/tenzro-lifi
• network.tenzro/tenzro-solana

All seven are still isLatest: true and advertise https://<host>.tenzro.network/mcp as streamable-http.

Why we cannot do this ourselves

network.tenzro is a DNS-verified namespace and we no longer control tenzro.network. Both auth methods that apply to a domain namespace — /v0.1/auth/dns and /v0.1/auth/http — prove control of exactly the domain we have lost, so we cannot obtain a token for that namespace to set the status ourselves. This is the one case the self-serve path in #1033 does not cover.

We are only asking for soft delete. Per #1132 we understand hard delete is out of scope by design, and soft delete is entirely sufficient here.

Why it matters

The domain now resolves via a wildcard to a parking host, so every one of those endpoints answers a parking page rather than an MCP server:

dig +short mcp.tenzro.network   ->  91.195.240.94   (Server: Parking/1.0)
dig +short mcp.tenzro.xyz       ->  8.219.158.33    (our live fleet)

POST https://mcp.tenzro.network/mcp  ->  405, Allow: GET
POST https://mcp.tenzro.xyz/mcp      ->  200

Clients that discover us through the registry follow the .network entries and fail. This was found by an external user probing registry endpoints, who reported it to us as a bug in our infrastructure (tenzro/tenzro-network#5) — the entries are attributed to us but are no longer ours to fix.

Replacements are already published

The same seven products are live and healthy under a namespace we do verify, xyz.tenzro, with identical server names:

xyz.tenzro/tenzro          https://mcp.tenzro.xyz/mcp          POST -> 200
xyz.tenzro/tenzro-solana   https://solana-mcp.tenzro.xyz/mcp   POST -> 200
xyz.tenzro/tenzro-canton   https://canton-mcp.tenzro.xyz/mcp   POST -> 401 (API-key gated by design)

plus tenzro-chainlink, tenzro-ethereum, tenzro-layerzero, tenzro-lifi. So nothing is lost by removing the .network set — it is strictly stale duplication.

Ownership evidence

tenzro.xyz carries our live v=MCPv1; k=ed25519;p=... TXT record and verifies the xyz.tenzro namespace holding the same seven servers, and we control https://github.com/tenzro. Happy to prove control of tenzro.xyz in whatever form is easiest — a nonce in a TXT record there, a file served on that host, or a reply from the org account.

One systemic note

A domain namespace's proof is checked when publishing but nothing re-checks it afterwards, so a namespace whose domain lapses or transfers keeps live entries pointing wherever that domain now goes, still attributed to the original publisher. Periodically re-resolving the proof and flagging entries that no longer validate would close this generally. Happy to open that separately if it is useful.

Start with the seven network.tenzro server entries and the soft-delete behavior referenced in #1132. Review the /v0.1/auth/dns and /v0.1/auth/http paths to understand why the requester cannot act, and use the stated stale .network endpoints as the failure case. Done means all seven entries are marked deleted without hard deletion.