luxd serves chain routes under /v1/chain, and the node, cli and sdk releases
already ship it. The deployed gateways still answer the old prefix, so remote
reads break until they are redeployed; the estate moves together rather than
sitting half converted.
Lines that record an observation - a probe, a status code, a past release -
keep the prefix they were written against, as do URLs on hosts that are not
ours. Avalanche endpoints move to /ext/bc, which is the path that host serves.
The rename to /v1/chain is real in luxd source, but the deployed fleet has not
taken it yet: probed just now, api.lux.network, api.lux-test.network,
api.zoo.network and api.hanzo.network each answer 200 on /v1/bc/C/rpc and 404 on
/v1/chain/C/rpc. Composing /v1/chain against those hosts reaches nothing, which
is the failure the rename set out to prevent.
The move belongs with the node redeploy, not ahead of it.
luxd serves chain routes under /v1/chain; the /v1/bc prefix it replaced is
gone, so anything composing it reaches nothing. Lines that record an
observation - a probe, a status code, a past release - keep the prefix they
were written against, as do URLs on hosts that are not ours.
luxd serves exactly one HTTP prefix — /v1 (node server/http/server.go
baseURL). /ext/ was removed some releases ago, so every Lux and Zoo URL
in this repo was pointing at a 404.
Measured 2026-07-27:
api.lux.network/v1/bc/C/rpc 200 eth_chainId 0x17871 (96369)
api.lux.network/ext/bc/C/rpc 404
api.lux-test.network/v1/bc/C/rpc 200 eth_chainId 0x17870 (96368)
api.zoo.network/v1/bc/C/rpc 200 eth_chainId 0x30e08 (200200)
api.zoo-test.network/v1/bc/C/rpc 200 eth_chainId 0x30e09 (200201)
control api.lux.network/v1/bc/ZZZNOPE/rpc 404
ZOO_MAINNET/ZOO_TESTNET were doubly wrong: legacy prefix AND a "Z" chain
alias that 404s on both prefixes. Zoo's EVM answers under bc/C.
Avalanche endpoints deliberately keep /ext/ — that is their API, not
ours (measured: api.avax.network/ext/bc/C/rpc 200 0xa86a, /v1 404).
B-chain/T-chain URLs move to /v1 as well; BridgeVM is still undeployed
(re-verified today: /v1/bc/B/rpc 404 while /v1/bc/C/rpc 200, so the 404
is "no such chain", not "no such prefix").
Rule: luxfi/bridge ships ONLY the Lux brand. Foreign-org bridge tenants
(Hanzo, Zoo, Pars, SPC, ) live in their own repos as thin
shims that consume @luxfi/bridge plus their own brand package.
- rm manifests/tenants/{hanzo,zoo,pars,spc}.yaml (carried foreign-brand
logos/colors/names into a Lux repo)
- REQUIREMENTS.md: drop tenant goal, drop Phase 2
Zoo-tenant stand-up + Hanzo-as-tenant deliverables, drop
@zooai/brand / @hanzoai/brand publication tasks; scope tenant work
to Lux only and embed target to luxfi/exchange
- docs/LLM.md (symlinked as CLAUDE.md/AGENTS.md/QWEN.md/GEMINI.md):
drop @zooai/brand / @hanzoai/brand from the architecture legend;
rewrite "Hanzo-side bridge" section as "foreign-brand tenants live
in their own repos"
- add app/bridge/public/.well-known/bridge.json declaring brandId=lux,
domain bridge.lux.network, peers [] (federation peers via runtime
ConfigMap), capabilities [bridge, mpc], apiVersion 1
- add BRAND-AUDIT.md documenting findings + actions
Kept (not org brand): "Liquid <TOKEN>" wrapped-asset names are Lux's
own bridge token brand (Liquid BTC, Liquid ETH, ...), wrapper minted
on Lux C-Chain per manifests/schema.yaml. Kept (chain identity):
manifests/tenants/lux.yaml, manifests/chains/*, chain RPC config,
teleporter contracts.
zeekay