explore

6,235 Commits 2 Branches 47 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
zeekayandHanzo Dev	a23a81dee7	Brand explorers show only their own chain on validators and DEX On a Zoo, Hanzo, Pars, SPC or Osage host the validators page listed every L1 in the registry, and /dex rendered the Lux D-Chain markets. The network total now sums every L1 only on the Lux primary-network explorer, and /dex answers 404 anywhere else. isPrimaryNetworkHost() is the same predicate as isPrimaryNetworkExplorer(), taking the host from the request. Co-authored-by: Hanzo Dev <[email protected]>	2026-09-23 16:09:21 -07:00
zeekay	87aa0fa367	chains: read each chain from that chain, and list the ones this network runs /chains showed fifteen rows on every network, from a hardcoded table. Four of them — T, R, I, O — are registered on no network at all; the node answers "there is no ID with alias: T". A fifth, M, runs on devnet alone. And every /chains/<slug> page printed the same four numbers: the primary network's validator count, its total stake, its chain count, its threshold. Nothing on Q-Chain's page was about Q-Chain. Fifteen pages, one set of facts. The network already knows its own answer. platform.getBlockchains is the chain list, and it is per-network for free: mainnet and testnet report nine chains, devnet reports ten including M. That is what /chains lists now, joined with configs/app/primaryChains.ts for presentation only — a chain the network reports and we have no metadata for still gets a row, because the network is the source of truth and our table is not. Three facts per chain, each read from that chain: * the blockchain ID, from the registry — the thing that actually tells one chain from another, and it was already on screen while the numbers above it were not * whether the node has bootstrapped it, from info.isBootstrapped, which the gateway routes for every chain. This is how Q-Chain's page now says Syncing where the other nine say Bootstrapped: Q has not come up on any of the three networks and is the sole reason all three report healthy:false * its head, in its own dialect — eth_blockNumber for C, platform.getHeight for P, xvm.getHeight for X. Not avm: that service is gone from this build, and asking it returns "can't find service" rather than a height Validators are the P-Chain's model, so they render on the P-Chain and nowhere else. The head is labelled for the model it comes from — the X-Chain's is an accepted height, not a block height. Where a chain has no head to read, it says so. The gateway routes exactly P, X and C on all three networks; D, A, B, Z, G, K and Q are registered and bootstrapped on the node but their RPC 404s from a browser. Proof it is the route and not the chain: C-Chain's own blockchain ID, /v1/bc/25td8att…/rpc, 404s while /v1/bc/C/rpc returns a height — same chain, same node. Those pages read "No public RPC" and say plainly that the chain is registered and running but not published. A zero there would have read as a measurement. One proxy replaces the P-only one. /v1/pchain hardcoded /v1/bc/P; /v1/node/ <endpoint> resolves the endpoint against the primary-chain table and never treats it as a URL. A chain the gateway does not route comes back 200 carrying a JSON-RPC error rather than 502 — nothing is broken, and 502 put a red failed request in the console of eight of the ten chain pages. Deleted: CHAIN_INDEXER_URLS and the hook that read it — fifteen hostnames of the shape api-indexer-<x>chain.lux.network, none of which resolve. Fifteen of fifteen NXDOMAIN. It fetched them on every chain page and rendered the null. Measured on mainnet, 1440x900 and 390x844, fresh context per URL: 20 of 20 chain/screen rows agree with RPC on both status and head — C-Chain 1,107,826 against a live head bracketed at 1,107,822..1,107,829, P and X at 0, seven reading No public RPC, Q Syncing while the rest are Bootstrapped. /chains lists the same ten chains the P-Chain reports, and 10 of 10 row links reach a real page. Zero 4xx or 5xx from our own origin.	2026-08-08 07:32:01 -07:00
zeekayandHanzo Dev	a3caebadf2	search: the icon sat on the placeholder, and validators counted one L1 of four The magnifying glass was drawn over the leading "S" of the placeholder. The cause is not the search bar: @luxfi/ui's InputGroup measures its adornments correctly and then throws the measurement away, because the clone is guarded on `displayName === 'FieldInput'` — a component that does not exist in the package — and the props it would have set (`ps`/`pe`) are Chakra style props that the Tailwind/gui Input spreads onto the DOM and ignores. Both halves are leftovers of the Chakra→Tailwind port, so EVERY InputGroup in the app is unpadded; the header is just the one you look at every day. Patched at the primitive (patches/@[email protected]) rather than hand-tuning padding at one call site: the offset is the measured width of the actual adornment, so it stays right when the adornment changes, and FilterInput / revoke's SearchInput / the showcase are fixed by the same change. Measured at 1440x900: the icon overlapped the text by 24px and the kbd chip by 52px; both are now 0. The measurement also moves to a layout effect and stops blanking value and placeholder on first render. That blanking was inert while the guard swallowed the clone; with the clone live it flips the field from controlled to uncontrolled on mount, which React warns about and which can eat a keystroke. ClearButton spread `className` over its own visibility classes, so a caller passing one clobbered `invisible` — the header showed a clear button on an empty field. Merged instead, at the component. Placeholder is now "Search or ask anything", and Cmd/Ctrl-K opens an assistant. Nothing in this repo, @luxfi/ui or @hanzo/gui ships a command palette or chat (no cmdk, no palette, one dialog primitive), so this is the smallest thing that works: the existing Dialog, one global listener, and a server-side proxy that holds the credential. The key is deliberately not NEXT_PUBLIC_, so a deployment without one gets a dialog that says exactly that instead of failing silently. Off unless NEXT_PUBLIC_AI_ASSISTANT_ENABLED is set — Ctrl+K is the browser's address-bar shortcut and claiming it to show an error would be worse than not claiming it. Validators read 5 on a network running 20. useCurrentValidators asks ONE P-Chain, the one this deployment points at, but Lux, Hanzo, Zoo and Pars are each sovereign L1s with their own P-Chain and their own validator set — measured 2026-08-06, five each, with four disjoint NodeID sets. The registry gains the node origin per chain; absence of it is the signal that a chain has no publicly reachable node (SPC and Osage are in-cluster only), and those are reported `unavailable` rather than counted as zero. Stake is deliberately NOT summed: each chain bonds its own currency. The proxy resolves `?chain=` through the registry and never from the request, so it cannot be pointed at an arbitrary origin. The new envs are registered with the envs-validator and documented in ENVS.md — the schema rejects unknown NEXT_PUBLIC_* variables and runs at container start, so an undeclared one stops the pod from booting. Co-authored-by: Hanzo Dev <[email protected]>	2026-08-06 19:17:01 -07:00

Author

SHA1

Message

Date

zeekayandHanzo Dev

a23a81dee7

Brand explorers show only their own chain on validators and DEX

On a Zoo, Hanzo, Pars, SPC or Osage host the validators page listed every L1
in the registry, and /dex rendered the Lux D-Chain markets. The network total
now sums every L1 only on the Lux primary-network explorer, and /dex answers
404 anywhere else. isPrimaryNetworkHost() is the same predicate as
isPrimaryNetworkExplorer(), taking the host from the request.


Co-authored-by: Hanzo Dev <[email protected]>

2026-09-23 16:09:21 -07:00

zeekay

87aa0fa367

chains: read each chain from that chain, and list the ones this network runs

/chains showed fifteen rows on every network, from a hardcoded table. Four of
them — T, R, I, O — are registered on no network at all; the node answers
"there is no ID with alias: T". A fifth, M, runs on devnet alone. And every
/chains/<slug> page printed the same four numbers: the primary network's
validator count, its total stake, its chain count, its threshold. Nothing on
Q-Chain's page was about Q-Chain. Fifteen pages, one set of facts.

The network already knows its own answer. platform.getBlockchains is the chain
list, and it is per-network for free: mainnet and testnet report nine chains,
devnet reports ten including M. That is what /chains lists now, joined with
configs/app/primaryChains.ts for presentation only — a chain the network
reports and we have no metadata for still gets a row, because the network is
the source of truth and our table is not.

Three facts per chain, each read from that chain:

  * the blockchain ID, from the registry — the thing that actually tells one
    chain from another, and it was already on screen while the numbers above
    it were not
  * whether the node has bootstrapped it, from info.isBootstrapped, which the
    gateway routes for every chain. This is how Q-Chain's page now says
    Syncing where the other nine say Bootstrapped: Q has not come up on any of
    the three networks and is the sole reason all three report healthy:false
  * its head, in its own dialect — eth_blockNumber for C, platform.getHeight
    for P, xvm.getHeight for X. Not avm: that service is gone from this build,
    and asking it returns "can't find service" rather than a height

Validators are the P-Chain's model, so they render on the P-Chain and nowhere
else. The head is labelled for the model it comes from — the X-Chain's is an
accepted height, not a block height.

Where a chain has no head to read, it says so. The gateway routes exactly P, X
and C on all three networks; D, A, B, Z, G, K and Q are registered and
bootstrapped on the node but their RPC 404s from a browser. Proof it is the
route and not the chain: C-Chain's own blockchain ID, /v1/bc/25td8att…/rpc,
404s while /v1/bc/C/rpc returns a height — same chain, same node. Those pages
read "No public RPC" and say plainly that the chain is registered and running
but not published. A zero there would have read as a measurement.

One proxy replaces the P-only one. /v1/pchain hardcoded /v1/bc/P; /v1/node/
<endpoint> resolves the endpoint against the primary-chain table and never
treats it as a URL. A chain the gateway does not route comes back 200 carrying
a JSON-RPC error rather than 502 — nothing is broken, and 502 put a red failed
request in the console of eight of the ten chain pages.

Deleted: CHAIN_INDEXER_URLS and the hook that read it — fifteen hostnames of
the shape api-indexer-<x>chain.lux.network, none of which resolve. Fifteen of
fifteen NXDOMAIN. It fetched them on every chain page and rendered the null.

Measured on mainnet, 1440x900 and 390x844, fresh context per URL: 20 of 20
chain/screen rows agree with RPC on both status and head — C-Chain 1,107,826
against a live head bracketed at 1,107,822..1,107,829, P and X at 0, seven
reading No public RPC, Q Syncing while the rest are Bootstrapped. /chains
lists the same ten chains the P-Chain reports, and 10 of 10 row links reach a
real page. Zero 4xx or 5xx from our own origin.

2026-08-08 07:32:01 -07:00

zeekayandHanzo Dev

a3caebadf2

search: the icon sat on the placeholder, and validators counted one L1 of four

The magnifying glass was drawn over the leading "S" of the placeholder. The
cause is not the search bar: @luxfi/ui's InputGroup measures its adornments
correctly and then throws the measurement away, because the clone is guarded on
`displayName === 'FieldInput'` — a component that does not exist in the package
— and the props it would have set (`ps`/`pe`) are Chakra style props that the
Tailwind/gui Input spreads onto the DOM and ignores. Both halves are leftovers
of the Chakra→Tailwind port, so EVERY InputGroup in the app is unpadded; the
header is just the one you look at every day. Patched at the primitive
(patches/@[email protected]) rather than hand-tuning padding at one call
site: the offset is the measured width of the actual adornment, so it stays
right when the adornment changes, and FilterInput / revoke's SearchInput / the
showcase are fixed by the same change. Measured at 1440x900: the icon overlapped
the text by 24px and the kbd chip by 52px; both are now 0.

The measurement also moves to a layout effect and stops blanking value and
placeholder on first render. That blanking was inert while the guard swallowed
the clone; with the clone live it flips the field from controlled to
uncontrolled on mount, which React warns about and which can eat a keystroke.

ClearButton spread `className` over its own visibility classes, so a caller
passing one clobbered `invisible` — the header showed a clear button on an empty
field. Merged instead, at the component.

Placeholder is now "Search or ask anything", and Cmd/Ctrl-K opens an assistant.
Nothing in this repo, @luxfi/ui or @hanzo/gui ships a command palette or chat
(no cmdk, no palette, one dialog primitive), so this is the smallest thing that
works: the existing Dialog, one global listener, and a server-side proxy that
holds the credential. The key is deliberately not NEXT_PUBLIC_, so a deployment
without one gets a dialog that says exactly that instead of failing silently.
Off unless NEXT_PUBLIC_AI_ASSISTANT_ENABLED is set — Ctrl+K is the browser's
address-bar shortcut and claiming it to show an error would be worse than not
claiming it.

Validators read 5 on a network running 20. useCurrentValidators asks ONE
P-Chain, the one this deployment points at, but Lux, Hanzo, Zoo and Pars are
each sovereign L1s with their own P-Chain and their own validator set — measured
2026-08-06, five each, with four disjoint NodeID sets. The registry gains the
node origin per chain; absence of it is the signal that a chain has no publicly
reachable node (SPC and Osage are in-cluster only), and those are reported
`unavailable` rather than counted as zero. Stake is deliberately NOT summed:
each chain bonds its own currency.

The proxy resolves `?chain=` through the registry and never from the request, so
it cannot be pointed at an arbitrary origin. The new envs are registered with
the envs-validator and documented in ENVS.md — the schema rejects unknown
NEXT_PUBLIC_* variables and runs at container start, so an undeclared one stops
the pod from booting.

Co-authored-by: Hanzo Dev <[email protected]>

2026-08-06 19:17:01 -07:00