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").
Two additive integrations from origin/whispers/bridgev2 — both pure
insertions, no consumer-contract changes.
LP-333 (internal/bchain/client.go):
Adds SignerMember, SignerSetInfo, EpochInfo + GetSignerSetInfo /
GetEpoch methods on the b-chain JSON-RPC client. The bridge becomes
a CONSUMER of BridgeVM signer-set state: it observes which MPC
nodes are in the active quorum, the threshold, and epoch
transitions, then points new keygen/signing at the current epoch's
members. mpcd remains authoritative on key share material; BridgeVM
is the membership + epoch ledger.
Methods are read-only — the bridge never proposes rotations. Node
operators do that out-of-band via BridgeVM governance. Surface lives
on the same `${nodeUrl}/ext/bc/B/rpc` endpoint as bridge_getInfo,
not on ThresholdVM.
internal/mchain/pool.go:
Adds Pool — round-robin release-wallet selector that the daemon
drains for destination-chain broadcasts. Pure additive; existing
callers don't see it until they choose to consume it.
Tests: bchain (2.3s) + mchain (2.6s) all green. Includes
TestGetSignerSetInfo_HappyPath + TestGetEpoch round-trips against the
mock node.
NOT included in this PR (deliberately scoped out):
- internal/mchain/client.go modifications — branch's version is
behind main (no DashboardURL/Curve/sessions). Main's BTC support
already supersedes the branch's testnet-stopgap path.
- internal/mchain/btc_address.go — branch's file is a TESTNET
base58 stopgap; main's file is the production bech32 derivation
(deriveBTCBech32Address, compressSecp256k1Pubkey). Different
purposes, main's wins.
This is the second slice of the whispers/bridgev2 integration. Per
"x.x.x+1, never lazy major" the bridge's next tag is v1.2.0 once the
substantive features land.
zeekay
venuswhispers