Request
Please mark all versions of these seven servers deleted:
network.tenzro/tenzronetwork.tenzro/tenzro-cantonnetwork.tenzro/tenzro-chainlinknetwork.tenzro/tenzro-ethereumnetwork.tenzro/tenzro-layerzeronetwork.tenzro/tenzro-lifinetwork.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.
Request
Please mark all versions of these seven servers
deleted:network.tenzro/tenzronetwork.tenzro/tenzro-cantonnetwork.tenzro/tenzro-chainlinknetwork.tenzro/tenzro-ethereumnetwork.tenzro/tenzro-layerzeronetwork.tenzro/tenzro-lifinetwork.tenzro/tenzro-solanaAll seven are still
isLatest: trueand advertisehttps://<host>.tenzro.network/mcpasstreamable-http.Why we cannot do this ourselves
network.tenzrois a DNS-verified namespace and we no longer controltenzro.network. Both auth methods that apply to a domain namespace —/v0.1/auth/dnsand/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:
Clients that discover us through the registry follow the
.networkentries 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:plus
tenzro-chainlink,tenzro-ethereum,tenzro-layerzero,tenzro-lifi. So nothing is lost by removing the.networkset — it is strictly stale duplication.Ownership evidence
tenzro.xyzcarries our livev=MCPv1; k=ed25519;p=...TXT record and verifies thexyz.tenzronamespace holding the same seven servers, and we control https://github.com/tenzro. Happy to prove control oftenzro.xyzin 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.