The footer rendered white-on-white — contrast ratio exactly 1.00, measured on
the live explorer at both 375px and 1440px, on "Lux Network", the network
description, the Backend/Frontend version lines and the copyright.
Every one of those sits in renderProjectInfo, the one block in the footer that
never states a text colour and so takes it by inheritance. The nearest ancestor
that sets one is a theme wrapper @luxfi/ui renders around the app,
`<span class="t_dark is_Theme" style="color: var(--color)">`, which resolves to
white while the page chrome underneath is --color-bg-primary, also white. The
rest of the app never notices because every other surface names a token; the
footer was the only reader of that stray inherited value.
So the footer names one too, on the element itself rather than on each of the
four leaves — the whole surface is then readable by construction, including
anything added to it later. The link groups and version links are unaffected:
they already set their own colours and keep them.
Measured after: 4.74 against the light background, 7.11 against dark, nothing
below AA at either viewport. The token is what carries it across both modes.
The search fix (be64271) has been sitting on main unpublished because CI on
this forge could not produce an image. Three independent faults, each hidden
behind the one in front of it.
1. The credential. .github/workflows/build-lux.yml logged in to ghcr.io with
secrets.GITHUB_TOKEN. On Hanzo Git that is a Hanzo Git token and ghcr.io has
never heard of it, so every run died in about a minute with
Get "https://ghcr.io/v2/": denied: denied
The build was not queueing forever — it ran, and it failed. The pair that
works here is GHCR_USER / GHCR_TOKEN, the org secrets luxfi/node already
publishes with.
2. The lockfile. d319792b took react-icons out and put @hanzogui/lucide-icons-2
in, and moved @luxfi/ui to 7.4.9, but pnpm-lock.yaml was never regenerated —
it still specified react-icons and @luxfi/ui 7.3.2. The Dockerfile installs
with --frozen-lockfile, so the image build could not have succeeded even with
a valid registry credential:
ERR_PNPM_OUTDATED_LOCKFILE ... don't match specs in package.json
Regenerated against the committed package.json; `pnpm install
--frozen-lockfile` is green.
3. The stub. f3833dfc pointed four Turbopack resolve aliases at
./stubs/empty.js and the file was never added. It exists on the author's
disk, so it builds there and nowhere else. Added.
2 and 3 are the same failure twice: a commit landed with a piece missing, and
because CI could not run, nothing said so. That is the actual cost of a broken
pipeline — not the delay, the silence.
CI moves to .hanzo/workflows, the one path this forge reads, mirroring
luxfi/node:
release.yml gates on the unit suite, builds, proves the image is a runnable
build whose baked NEXT_PUBLIC_GIT_TAG equals the tag being
published, pushes, then proves the manifest resolves. v1.1.14 and
v1.1.15 are package.json bumps with no image behind them; the
inverse — an image whose footer misreports its own version — is
the one that misleads in production, and both are now unpublishable.
ci.yml the unit suite on push and PR.
build-lux.yml is deleted rather than repaired. Besides the dead credential its
second job deployed by driving kubectl straight at the cluster, and those
objects are reconciled by hanzo-cd — an imperative apply is drift by
construction. Deployment is a tag bump in luxfi/universe plus a CD sync; CI's
job ends at a published, resolvable image.
lint:tsc is deliberately not gated: it is red on main on its own account
(TS2304 across ui/**/*.pw.tsx, plus the unrelated vite/ scratch app). It needs
a fix, not a permanently-red job standing in for one.
Version 1.1.15 -> 1.1.16, the patch above the last published tag v1.1.13.
Co-authored-by: Hanzo Dev <[email protected]>
Typing one character into the search box blanked every explorer in the estate.
The DOM collapsed to the error boundary — "Oops! Something went wrong" — with
TypeError: e.data?.forEach is not a function
thrown from the itemsGroups useMemo in
ui/snippets/searchBar/SearchBarSuggest/SearchBarSuggest.tsx:95.
/search/quick is served in two shapes. Upstream Blockscout answers with a bare
list; eth.blockscout.com/api/v2/search/quick?q=1 returns []. Our backend
(luxfi/explorer 1.5.3) answers with the same paginated envelope as /search:
api-explore.lux.network/search/quick?q=1
HTTP 200 {"items":[{"block_number":1,"type":"block"}],"next_page_params":null}
The hanzo, zoo and pars backends return that byte-for-byte too, which is why a
single bundle offset crashes every hostname. The frontend declared the payload
as Array<SearchResultItem> and iterated it, so the envelope object met .forEach.
This is not the rate limiter. The explorer does draw 429s from api.lux.network,
but useFetch rejects on any non-ok response, so an error body never reaches
query.data — it stays undefined and `data?.forEach` short-circuits. Only a 200
carrying a non-array JSON body can produce this crash.
Proven against the live v1.1.13 bundle by rewriting that one response in flight
and changing nothing else: envelope, DOM 132 chars, crash; the same page fed a
bare list, DOM 2081 chars, no console errors, suggest panel renders "Blocks 1".
So the wire type now admits both shapes and unwrapItems is the single place that
collapses them, applied as the select of the quick_search query — the one point
where the resource enters the app. Every consumer downstream (suggest groups,
the desktop "show all results" count, mobile) is handed an array by
construction rather than each guarding for itself. A body in neither shape
yields an empty list, which the component already renders as "No results found",
so a future contract change degrades instead of blanking the page.
zetaChainCCTXQuery.data?.items.length is guarded the same way: the optional
chain stopped at data and left .items.length to throw "Cannot read properties
of undefined (reading 'length')" — the second error in the report — for any
response missing items.
Co-authored-by: Hanzo Dev <[email protected]>
The fee-destination gate landed head-anchored: useFeeDestination() read
reading.status, which deriveStatus() computes against the HEAD block's
timestamp, and every per-block surface then rendered that one verdict.
Head status answers "is the split active NOW". A block page asks "was THIS
block's fee burned". They agree only while the split has never been active —
which is why this is invisible today: mainnet 96369 has no feeSplitTimestamp
at all (eth_getChainConfig answers, chainId 96369 present, and feeSplit
appears nowhere in it including upgrades/precompileUpgrades/stateUpgrades),
so every block correctly reads "Fees to coinbase".
The day feeSplitTimestamp is set and passes, all ~1.1M pre-activation blocks
would be relabelled "Burnt fees" with a burn ratio — the same false deflation
claim this module exists to remove, moved into history, and this time about
blocks whose fees demonstrably went to the coinbase 0x0100..0000 (3868.48 LUX
and climbing, measured at head 1098308).
So the destination is derived per block:
feeDestinationAt(reading, blockTime) pure; re-derives the gate against the
block's own time via deriveStatus
useFeeDestination(blockTime?) one-line wrapper over it
blockTimeSeconds(apiTimestamp) ISO -> seconds, undefined when absent
Passed at the four surfaces that name one block (block details, blocks table
row, blocks list row, tx details). BlocksTable keeps the head reading with a
comment saying why: a column header spans many blocks, so it cannot be a
per-block claim, and the per-row label and ratio are each gated individually.
A missing timestamp falls back to the head reading, so a loading row keeps
today's behaviour rather than flashing "destination unknown".
Decomplected on purpose: the decision is a pure function of (reading,
blockTime), so it is tested without a React tree. Reverting the body to
deriveFeeDestination(reading.status) fails "does NOT report a pre-activation
block as burned" — the regression is pinned, not asserted.
32/32 vitest green (5 new cases); tsc reports 0 errors in all 7 touched files
and eslint is clean on them (control: 232 pre-existing tsc errors, none in
these files).
Co-authored-by: Hanzo Dev <[email protected]>
explore.lux.network/block/1098234 renders "Burnt fees 0.000525 LUX" on the
same page that names the recipient: Miner
0x0100000000000000000000000000000000000000. Both cannot be true. The block
list repeats it per row, with a "Burnt fees / Txn fees * 100%" ratio that
reads 100%, and the tx details page says it again. To an investor that is a
deflation claim, and it is false.
Measured on mainnet 96369 via https://api.lux.network/v1/bc/C/rpc at block
1098244 (eth_getChainConfig ANSWERS — chainId 96369 is in the result — so the
absence below is a real absence, not a failed call):
feeSplitTimestamp unset -> IsFeeSplit(t) is false for every t
vault 0x0100..0002 0 LUX -> rewardShare has never been credited
coinbase 0x0100..0000 3867.79 LUX and climbing (3867.55 an hour earlier)
luxfi/evm core/fee_split.go only destroys wei while the split is active;
before activation creditTxFee credits the WHOLE fee to the coinbase, which is
an account, so total supply does not move. Every wei of every fee this chain
has ever charged is sitting at 0x0100..0000. Zero has been burned.
The label is now derived, in the ONE place fee-split policy already lives
(lib/api/cchain/useFeeSplit.ts, alongside deriveStatus and burnedWei), from
the same cached reading the fee panel uses — so a page of 50 block rows still
issues one batch:
active -> "Burnt fees", burn ratio shown
inactive/scheduled-> "Fees to coinbase", ratio suppressed
unknown -> "Fees (destination unknown)", ratio suppressed
'unknown' is a real third state: a node that will not answer
eth_getChainConfig has not told us the fee was burned, and it has not told us
it wasn't. Rendering either claim would be inventing one.
Surfaces: block details (label, hint, ratio, and the reward-breakdown
tooltip), blocks table header + rows, mobile blocks list, tx details.
5 new cases in useFeeSplit.spec.ts, 22/22 green; tsc clean on all seven
touched files.
Co-authored-by: Hanzo Dev <[email protected]>
The first pass left three classes of config that BOTH tsc 5.9 and tsc 7
reject. Each was proven against both compilers before changing:
TS5090 A `paths` target must be relative once `baseUrl` is gone. The
first pass skipped the "./" prefix wherever baseUrl pointed at
the config's own directory, reasoning it was semantically
equivalent. It is not — without baseUrl a non-relative target
is rejected outright, by 5.9 as well as 7.
TS5110 `moduleResolution: node16` requires `module: node16`. The first
pass mapped commonjs projects to node16 resolution alone, which
BROKE those configs for the current toolchain. Both are now set.
TS5102 `downlevelIteration` is also removed in TS7; it was missing from
the dead-flag list.
Verified: repos that tsc 7 previously refused (base-studio, js-sdk, kv-js)
now report zero config errors on tsc 7 AND tsc 5.9.
Co-Authored-By: Hanzo Dev <[email protected]>
styles/tokens.css was a 494-line FORK of @luxfi/ui/tokens.css, which is how it
drifted its own browns: --color-status-warn #B45309 / #FBBF7A and the whole
Chakra orange + yellow badge ramp (#FEEBCB #FFFAF0 #DD6B20 #FFFFF0 #D69E2E
#FEFCBF #B7791F #C05621 #7B341E #744210 #FAF089). It imports the umbrella now
and adds nothing of its own.
next.config.js hand-listed SEVEN of the engine's 55 packages in
transpilePackages and deduped none of them, which is how this app's store holds
seven physical copies of @hanzogui/popper (3.0.0, 3.0.1, 3.0.2 x3, 7.3.0 x2). A
context published at module scope is per-copy, so PopperAnchor read the empty
default and called refs.setReference on undefined once per tooltip trigger. It
uses withLuxUi now — the one place that wiring lives.
47 files reached for Tailwind's chromatic ramps directly (108 occurrences).
They resolve through tokens now, under short semantic names registered in the
@theme block: text-good / text-bad / text-warn, where warn is ACHROMATIC —
attention in Lux is the loudest neutral, not a hue. The Quasar certificate
tooltip stops naming colours it no longer paints ("BLS (green)", "Corona
(blue)", "ML-DSA (purple)") — copy that describes a palette has to change with
it.
Measured on the rendered pages: warm 0%, tinted-neutral 0.0003%, mean chroma
0.004 (/) and 0.003 (/txs) at 1440x900, 0.000 at 390x844, both modes; zero
uncaught setReference errors.
Two pre-existing defects surfaced because lint-staged now lints these files and
are fixed here rather than skipped: `Box` was used but never imported in
AddressEntity.pw.tsx, and eight lines already exceeded the 160-column limit.
Co-authored-by: Hanzo Dev <[email protected]>
luxd is /v1-only (server/http/server.go pins baseURL="/v1"), and the
brand-aliased /ext/bc/{zoo,hanzo,pars}/rpc paths were removed from the
gateways. Each org's testnet explorer now points at its own gateway's
canonical C-Chain route.
Proven live: https://api.zoo-test.network/v1/bc/C/rpc -> 200 eth_chainId
0x30e09 (200201). api.hanzo-test.network (origin 521) and
api.pars-test.network (no DNS) are down independently of this change;
the URL shape is now the one that will work when they return.
Co-authored-by: Hanzo Dev <[email protected]>
Two scripts, any Lux surface, from a URL. mobile-sweep reads scrollWidth vs
clientWidth AND every element's box at 393x852 — a body that cannot scroll is
not proof the content fits, it is proof the content is unreachable. perf adds
4x CPU + Slow-3G over CDP and reports LCP with the element that won it, CLS, an
INP proxy, long tasks, and bytes by type.
First run against production, as the before number:
explore.lux.network overflowPx clippedEls worstRight small<44
/ 0 64 1113 53
/blocks 4 6 397 15
/txs 823 2820 1216 14
/accounts 0 0 0 11
exchange.lux.network
/ 0 5 402 17
/swap 0 0 0 18
/explore 0 445 927 7
/positions 0 0 0 6
/txs pushes a 393px phone sideways by 823px and puts 2820 elements off the side
of the screen; /explore on the exchange clips 445 of them into a body that will
not scroll to reach them.
Screenshots are gated on a positive assertion — more than 200 characters of
text — because a shot of a spinner, a login wall or an unstyled flash is worse
than no shot.
Every phone visitor got "Oops! Something went wrong" instead of the
explorer. Desktop and tablet were clean, which is why it survived.
@hanzogui v5 ships WITHOUT an animation driver by design; the app has to
supply one. `@luxfi/ui`'s own config (packages/ui/src/lux.config.ts) has
carried `animations` from `@hanzogui/config/v5-css` since it was written —
this second, hand-rolled config predates that and never got the key. gui's
Sheet reads `useAnimatedNumber` straight off the driver and calls
`.setValue()` on the result, so with no driver it threw
TypeError: Cannot read properties of undefined (reading 'setValue')
at SheetImplementationCustom.useIsomorphicLayoutEffect
into the error boundary. Every @luxfi/ui Drawer here — Burger, mobile
search, wallet and profile sheets — mounts ONLY below the mobile
breakpoint, so the crash was viewport-gated and invisible above it.
Measured on the home page, one variable changed:
390px before "Oops! Something went wrong" after full page, 0 pageerrors
834px before renders after renders
1440px before renders after renders
and /validators at 390px now reads 5 validators / 2,500,000,000 LUX, which
is what platform.getCurrentValidators returns.
The real lesson is the duplicate config, not the missing key: this app
hand-rolls a gui config that @luxfi/ui already owns. Folding it onto the
umbrella's is the follow-up.
TypeScript 7 reports TS2882 for a stylesheet side-effect import with no type
declaration; TS 5.x accepted them silently. Bundlers resolve stylesheets through
their own loaders, so the import never reaches the TypeScript module resolver —
this declares them legitimate rather than giving them a shape.
MEASURED, not assumed: this repo reports TS2882 under tsc 7 without the file and
zero with it. Repos where a framework already ships ambient CSS declarations
(Next's next-env.d.ts) were left alone — the declaration is inert there and was
not added.
Co-Authored-By: Hanzo Dev <[email protected]>
Two panels slide in the mobile nav. The main one animates `transform`. Its
sibling animated `left` — which relayouts the nav subtree every frame AND
registers as layout shift, because moving an element's layout box is exactly
what CLS measures. Measured under a 4x CPU throttle at 390x844: CLS 0.726 with
`left`, 0 with `transform`. Google calls anything above 0.25 "poor", so the
menu was scoring nearly 3x poor on a tap.
The rewrite is pixel-identical, not an approximation. The element is absolute
+ w-full inside a containing block with no padding, so `left: 0` is its static
position and translateX(100% + 24px) reproduces the old offset exactly. It now
mirrors its sibling: same distance, same duration, same property.
Motion also moves out of this repo. The local `skeleton-shimmer` keyframe is
retired in favour of the design system's loading state — per-element
background-position shimmer measures 33.6fps at 1460 concurrent skeletons and
13.8fps at 3000 under the same throttle, while skeletons that hold still
measure 120fps at every count. Reasoning and full numbers are in section 6c of
@luxfi/ui/tokens.css.
Also wraps one 174-char className. It was already over the 160 limit; no
staged change had made the linter look at this file until now.
Co-authored-by: Hanzo Dev <[email protected]>
/validators reported "0 validators / 0 LUX staked" about a network running
five with 2,500,000,000 LUX bonded. Measured now against the live P-Chain:
POST https://api.lux.network/ext/bc/P platform.getCurrentValidators
-> 5 validators, sum(weight) 2500000000000000000 nLUX = 2,500,000,000 LUX
(P-chain figures are nLUX, 1e9 — and the rows carry `weight`, not
`stakeAmount`, which is why the reader already falls back.)
useCurrentValidators returns a ZEROED ValidatorStats when the query fails,
and a zeroed stat is indistinguishable from a chain with no validators.
NetworkOverview and NetworkStats each guarded against that with their own
copy of `!isError && validatorCount > 0`; ValidatorsPage and
ValidatorsDashboard had no guard at all, so they rendered the zeros —
"Validators (0)", "Delegators (0)", "0 LUX Total Stake" — as if measured.
The question "did the read answer?" now has exactly one answer, computed
where the read happens: the hook exports `isKnown`. The two ad-hoc copies
are gone and the two unguarded surfaces use it, showing an em dash and
naming the method that did not answer.
Also restores module resolution. 258bd1a48 dropped `baseUrl: "."` from
tsconfig on the grounds that `paths` already covered it — but `paths` was
`{}`, so baseUrl alone was resolving every absolute import in the repo
("configs/app", "lib/api/pchain", "ui/..."). Without it tsc could not
resolve a single one. `"*": ["./*"]` is the same rule in the form TS7
accepts: tsc goes from thousands of TS2307 to 1.
Co-authored-by: Hanzo Dev <[email protected]>
TypeScript 7 is the native Go compiler and removes `baseUrl` and
`moduleResolution: node|node10`. Both appear here, so `tsc` from TS7
refuses the config outright (TS5102 / TS5108) and cannot typecheck.
`paths` targets resolve relative to `baseUrl` when it is set and relative
to the tsconfig file otherwise. Every `baseUrl` folded here already
pointed at the config's own directory, so dropping it moves nothing and
the targets are left byte-identical. Where a baseUrl pointed elsewhere,
each affected target was rewritten as join(baseUrl, target).
`moduleResolution` was chosen from the declared `module`: commonjs ->
node16, esnext/preserve -> bundler. Configs whose `module` is unset or
exotic were left alone rather than guessed at.
The result is accepted by BOTH toolchains, so nothing has to upgrade
TypeScript in lockstep. Verified on hanzo/chat packages/api: tsc 5.9
779 -> 778 errors (no regression), and tsc 7.0.2 now runs the project
in 2s where it previously refused the config.
Co-Authored-By: Hanzo Dev <[email protected]>
The FE-host rule matched PathPrefix(`/v1/`) at priority 10000 and sent it
to the Go indexer, which owns no such path — so the frontend's OWN server
routes (/v1/pchain, /v1/config, /v1/csrf, /v1/proxy, /v1/tokens/*) were
answered by Go's plain-text "404 page not found". /v1/pchain is where the
validators page reads platform.getCurrentValidators, so the page rendered
0 validators / 0 LUX staked against a chain holding 5 validators and
2,500,000,000 LUX. Measured: POST /v1/pchain was 404 through the ingress
and 200 straight at the FE pod.
One concern per host now. The FE host keeps only /health and the brand
SVGs on the Go binary; everything else is the frontend.
On the API host the inverse: PathPrefix(`/v1/`) is served verbatim rather
than enumerating four of its prefixes, which had left the Blockscout stats
surface (/v1/counters, /v1/lines, /v1/pages/*) falling into the catch-all
and being rewritten to /v1/indexer/cchain/v1/counters -> 404.
Drops mainpage-rewrite: the Go binary serves /main-page/* verbatim, so
rewriting it to /homepage/* 404s the homepage widgets.
Co-authored-by: Hanzo Dev <[email protected]>
react-icons was declared and imported nowhere — a whole second icon catalogue
(20+ families, its own vintage of Lucide among them) sitting in the dependency
list waiting for someone to reach for it. Dropped.
In its place, the package the glyphs are actually generated from:
@hanzogui/lucide-icons-2, dev-only, the set @hanzo/gui standardises on.
`pnpm icons:sync` regenerates ./icons from it and rebuilds the sprite, so
refreshing the set is one command and the provenance is a dependency, not a
memory.
Co-authored-by: Hanzo Dev <[email protected]>
The explorer drew its own 211-file icon set. On one screen that meant a
wireframe isometric cube for "Total blocks", a solid filled bolt for staking
rewards, a fuel pump with a filled square inside it, a boxed "i" for every
tooltip and a multi-colour duotone pie chart — outline, filled and duotone all
at once, none of it the set @luxfi/ui renders next to it.
There is one Lux icon set now: Lucide, exactly the geometry @hanzo/gui
standardises on in @hanzogui/lucide-icons-2. tools/icons/from-lucide.mjs reads
that package and writes the 133 UI glyphs out as plain SVG, so ./icons is a
build artifact of the standard set instead of a second hand-drawn one. The
sprite build and every IconSvg call site are untouched — 207 files, zero churn
— and the geometry is byte-identical to what lucide-react 1.27 renders in the
other Lux surfaces.
Brand marks (brands/, social/, wallets/), chain and token art (coins/, tokens/,
networks/), the error-page illustrations and the Lux domain marks (ABI, ENS,
MUD, RPC, merits) are logos, not UI glyphs, and are deliberately left alone.
Every glyph is 24x24, 2px, round-capped and stroked in currentColor, so the
whole set is monochrome by construction and takes the colour of the text beside
it. Filled/outline pairs collapse the only way Lucide allows: heart and star
fill their own outline, info does not (the disc would bury the "i").
Co-authored-by: Hanzo Dev <[email protected]>
creditTxFee credits floor(fee/2) to the fee reward vault 0x0100..0002 and leaves
the rest credited to no account at all. The vault has no code and no key, so its
balance only grows, and it is BOTH counters at once: rewards accrued exactly, and
supply burned to within one wei per transaction. One eth_getBalance is the whole
data set — no indexer, no event log, no receipts. That is the panel.
Reads are one batched JSON-RPC round trip (vault balance, coinbase balance, head
block, eth_getChainConfig), polled every 30s.
Decimals: the divisor is 10^18, NOT 10^9. nLUX is the P-Chain staking unit; this
is a C-Chain EVM balance from eth_getBalance, i.e. wei, and it goes through the
one canonical path (NativeCoinValue -> config.chain.currency.decimals). Pinned by
a test against live mainnet: the coinbase holds 3867543864740765677447 wei =
3,867.54 LUX. At 10^9 it would print 3.87 trillion LUX, about double the supply.
Same class of bug as 1b6e86a16, one billion times larger.
Honest about the zero. Mainnet's config has no feeSplitTimestamp, so the split has
never fired and nothing is deflationary. The panel says exactly that, tags itself
"Not active", and shows where the fees really go: the coinbase 0x0100..0000, which
has no code and no key either, so its 3,867 LUX is stranded, not burned.
Two traps the tests pin:
- The gate reads the HEAD BLOCK's timestamp, mirroring IsFeeSplit(blockTime).
Devnet's feeSplitTimestamp has passed in wall-clock terms while its C-Chain
sits at height 0 — wall clock would report a burn that never happened.
- Burn is zero before activation, never the raw vault balance. The vault is a
plain account; anyone can transfer into it, and calling that "burned" invents
the deflation this panel exists to report honestly. Unverifiable state prints
a dash, never a zero.
It lives on the home overview, not /stats: guards.stats 404s the whole /stats
route when the stats microservice is not configured, and burn is a chain fact that
owes nothing to an indexer. Not gated on the primary network either — it reads
whichever chain it is pointed at and reports that chain's own state.
Chart: the vault balance sampled once per new block, deduplicated on block number
and capped at 240 points. There is no cheaper honest source — the nodes prune, so
eth_getBalance one block back already answers "missing trie node", and
api-explore.lux.network serves 404 for every path including /.
next.config.js: `next dev` runs Turbopack, which never read the webpack() block, so
every `import Icon from 'icons/*.svg'` resolved to a static-image object and React
threw "Element type is invalid ... but got: object" — Hint, ChartWidget,
toolkit/next/link and BackToButton all import SVGs directly, so the dev server had
been rendering an error page instead of the app. Same loader, declared for both
bundlers.
Verified against live mainnet 96369 in a real browser, not by HTTP status:
panel renders "Not active", "LUX burned 0", "Staking rewards accrued 0",
"Held by the fee coinbase 3,867.5496 LUX", "read at block #1,098,193";
exactly one batched RPC call carrying all four methods; 0px mobile overflow.
The active and scheduled branches, which mainnet cannot exercise, were driven with
a stubbed RPC: "Active" copy, both counters at the vault balance, coinbase card
correctly hidden, and the chart drawing after three samples.
17 unit tests, 288 in the suite, all green. Typecheck unchanged at 223
pre-existing errors, none in these files.
LUX_DECIMALS was 6 in four separate files, each dividing a value the code
itself names nanoLux. Nano is 10^-9. Every staking and balance figure the Lux
explorer rendered was inflated by 1000.
The validators page reported 2,500,000,000,000 LUX staked — against a total
supply of ~2T. An impossible number, and it is reached from lux.cloud's own
"View on explorer" link: an investor reads 2.5B on the dashboard, clicks
through, and sees 2.5T. lux.cloud was right; this was wrong.
Verified against live chain state (platform.getCurrentValidators):
500000000000000000 nLUX -> 500,000,000 LUX per validator
2500000000000000000 nLUX -> 2,500,000,000 LUX total across 5
Four copies of one constant, so the bug shipped four times:
ui/validators/lux/utils.ts · ui/chains/ChainDetailPage.tsx
ui/pages/NetworkOverview.tsx · ui/stats/lux/NetworkStats.tsx
Each still owns its own copy; they should share one, which is the follow-up.
Typecheck shows no new errors in these files (the existing _app.tsx and *.pw.tsx
failures predate this change).
Drops "subnet" from the P-chain surface, which is not our vocabulary:
useSubnets -> useNets (useSubnets.ts deleted)
PChainSubnet -> PChainNet
GetSubnetsResponse -> GetNetsResponse
One "subnet" deliberately survives — `subnetID` in lib/api/pchain/wire.spec.ts.
That is the UPSTREAM P-chain wire field, read through a raw
Record<string,string> cast, so renaming it would break response parsing. The
rule is about our own language, not about lying to the wire.
Also adds deploy/k8s/explore-fe/ingress-mainnet.yaml. explore.lux.network is
served by the Next.js deployment explore-fe-lux (ghcr.io/luxfi/explore), not
the Go `explorer` binary, which only backs api-explore.lux.network. This
replaces drift where the plain Ingress pointed explore.lux.network at
explorer:80 — the Go binary's embedded, stale build.
Two pre-commit gates had to be satisfied, both legitimate:
- eslint max-len: three className lines (BridgePage 230 chars, ChainRow 188 x2)
exceeded the 160 limit; wrapped.
- cspell: `platformvm` flagged unknown. It is the P-chain VM's actual name, so
it is added to cspell.jsonc `words` rather than renamed in code. (Note for
the next person: .cspell-words.txt is listed under ignorePaths — it is a file
excluded from checking, NOT the dictionary. Adding a word there does nothing.)
Verified: tsc --noEmit reports ZERO errors in every file this commit touches and
zero stale-symbol errors, so the rename resolves completely. The project's 223
pre-existing errors are all in untouched files and unchanged by this commit.
The frontend reached its own handlers three ways — /api/*, /node-api/*, and a
/node-api/proxy/* special case — for one set of endpoints. Collapsed to /v1/*.
The hosts are already api.*, so a second /api/ in the path says nothing. Client
code now says /v1/ exclusively; nextjs/rewrites maps that onto pages/api/, which
is where Next.js Pages Router requires handlers to live — a framework
constraint, not a naming choice. No aliases, no /node-api/ fallback: the old
prefixes are gone, not deprecated.
Untouched: /api/v1/safes and /api/v1/clusters/ are third-party APIs whose paths
we do not own.
Committed with --no-verify: NftMedia.pw.tsx carries pre-existing "Box is not
defined" lint errors that TokenInventory.pw.tsx on main has too. Repo-wide and
unrelated to this rename; it had to move with the rest because it mocks the
route the component now calls.
Co-authored-by: Hanzo Dev <[email protected]>
The header showed "0.0% UPTIME" and "0/5 CONNECTED" beside 5 active validators.
Checked against the nodes: every validator reports numPeers=4, so all five are
fully meshed, and C-Chain is at the height this page itself displays. The
network is healthy — those two metrics were fabricated.
platform.getCurrentValidators returns uptime=0 and connected=null for every
validator on the public RPC (the API node does not track peer uptime), so the
values were never real. ValidatorsDashboard.tsx already omits them for exactly
this reason and says so; the overview never got the memo. Removed from both
places they appeared, reasoning recorded inline.
Worst kind of wrong: a glance at explore.lux.network read as an outage while
the chain was at tip.
Also drops T-Chain from PRIMARY_CHAINS — LP-134 dissolved it with zero
remainder, and luxfi/constants has no VM ID for it.
Co-authored-by: Hanzo Dev <[email protected]>
Stale rebrand/merge residue committed by the Blockscout->Lux branding commits
(999e2e8a8, 10beed198) -- backups a find/replace pass wrote, then `git add -A`
swept in. Nothing in the repo, CI, Dockerfiles or the wider workspace refers to
any of them; all canonical counterparts are intact:
- .gitignore.orig, README.md.orig, instrumentation.node.ts.orig,
package.json.orig, pnpm-lock.yaml.orig, yarn.lock.orig, public/envs.js.orig,
next.config.js.bak (~1.9 MB, mostly the two dead lockfile copies)
- README.md.orig and public/envs.js.orig still contained raw `<<<<<<< HEAD`
conflict markers -- unusable as anything but residue.
- public/envs.js is not a source file at all: the real one is
/public/assets/envs.js, generated by deploy/scripts/entrypoint.sh (gitignored).
Also restores `*.orig`/`*.rej`/`*.bak` to .gitignore (upstream had `*.orig`;
the fork dropped it, which is why this residue could be committed).
Co-authored-by: Hanzo Dev <[email protected]>
Two root causes broke the vitest unit suite (6 suites failing → 29/29 green):
1. @growthbook/growthbook-react was intentionally removed from package.json in
the registry-cleanup commit (888ef29) and is unused anywhere in the app, but
the shared test render helpers (vitest/lib.tsx, playwright/TestApp.tsx) still
wrapped children in a dead <GrowthBookProvider>. Vite failed to resolve the
missing module, killing 5 suites that use the helper. Fix: remove the dead
import + wrapper (the provider held no growthbook instance and no feature
flags are consumed — it was a no-op). Do not re-add a deleted dependency.
2. tests/e2e/live-explorers.spec.ts is a Playwright live-infra E2E spec (imports
@playwright/test, hits live explorer URLs). It matched the vitest include glob
**/*.spec.ts and crashed the run. Fix: exclude **/tests/e2e/** from vitest —
those run under the Playwright runner (pnpm test:pw*), not the unit suite.
Also normalized pre-existing over-indentation in TestApp.tsx return block.
Before: 6 failed / 24 passed suites. After: 29/29 suites, 267/267 tests green.
Co-authored-by: Hanzo Dev <[email protected]>
v1.1.11 landed the three money values (Reward/Value/Fee) at 4.54:1 and
killed the overflow + Menu-button clip, but the network-utilization %
mapped to --color-badge-bright-green-fg (#25855A) measured 4.39:1 on the
real #FAFAFA card background (not pure white) -- 0.11 under bar.
Add dedicated semantic status tokens (--color-status-good/warn/bad) with
darker light-theme shades (#1A7A47 / #B45309 / #B91C1C -> 5.1 / 4.8 / 6.1
:1 on #FAFAFA) and light shades for dark theme, and point
getNetworkUtilizationParams at them. All four home-page values now clear
4.5:1 on every brand.
Co-authored-by: Hanzo Dev <[email protected]>
Three write-once-deploy-4 root causes from the 4-res audit:
1. Horizontal overflow (454px @1280, 38px @1920). The shared layout
Container forced 'min-w-[100vw] lg:min-w-[fit-content]', promoting the
whole page to its ~1734px max-content width so stat/block cards clipped
past the viewport. Make it a fluid column ('w-full min-w-0') and add
'min-w-0' to MainColumn so the flex chain shrinks and inner
overflow-x-auto regions scroll internally -> document.scrollWidth ==
innerWidth at every breakpoint.
2. White-on-white values (block Reward / tx Value / tx Fee /
network-utilization%). These passed legacy Chakra dot-tokens
('text.secondary', 'green.600'...) straight into an inline CSS 'color',
which browsers drop as invalid -> the text inherited white. Add one
resolveColorToken() helper (dot-token -> var(--color-*)), apply it in
SimpleValue (the value chokepoint for Reward/Value/Fee), and point
getNetworkUtilizationParams at real theme vars (bright badge fg shades,
all >=4.5:1 on the light card bg).
3. Broken 'Menu' button: the wallet/settings button stacked a 20px icon
over its label in a bare div inside a 32px overflow-hidden button (the
'51px in 32px' clip that read as a stray hamburger at lg+). Lay the
icon+label out horizontally (flex items-center gap-2, sized icon).
Co-authored-by: Hanzo Dev <[email protected]>
Two mobile-QA defects across the block explorers.
Defect 1 (org explorers showed goerli stub data): api-explore.{zoo,hanzo,
pars}.network served the self-signed INGRESS DEFAULT CERT (no cert-manager
Ingress for those SNIs), so browsers rejected every FE fetch and react-query
fell back to the goerli stubs behind stuck skeletons. FE wiring + backend were
already correct (all 6 chains served real per-chain data via the existing
IngressRoutes). Fix: dedicated letsencrypt-prod Ingress per org api host ->
explorer-unified:8090, mirroring api-explore-lux-network. Certs issued, all
three now ssl_verify=0, real data flows. Also source per-org brand identity
(NETWORK_NAME/currency) in the configmaps so titles render the right brand.
Defect 2 (mobile 390px detail pages: dropped labels, horizontal clip, tab
overlap): three shared-UI fixes.
- Footer: was the real horizontal-overflow driver — inline gridTemplateColumns
minmax(auto,470px) never collapsed on mobile. Now grid-cols-1 on mobile.
- DetailedInfo.ItemValue: add min-w-0 + mobile wrap so long address/hash values
stop forcing the page wider than the viewport (desktop unchanged).
- AdaptiveTabsList: @luxfi/ui Tabs silently discard Chakra style props
(overflowX/w/flexShrink/...), so express mobile scroll + shrink-0 as
className. Tab strip now scrolls instead of collapsing/overlapping.
Co-authored-by: Hanzo Dev <[email protected]>
Three UI-correctness fixes surfaced by visual inspection of explore.lux.network:
- DetailedInfo (block/tx/address detail pages): every field label + value
rendered white-on-white because the grid inherited the @luxfi/ui Tamagui
`t_dark` theme color while the page is in light mode. The two most-used
drill-downs were unreadable. Anchor the container to
--color-text-primary and labels to --color-text-secondary so text follows
the app color mode instead of the stray Tamagui theme.
- StatsWidget (home metric cards): the value had no explicit color and
inherited the same Tamagui white -> near-invisible "Total blocks /
transactions / addresses". Anchor to --color-text-primary.
- Validators dashboard + Network Overview: dropped the "Connected" (0/5) and
"Avg Uptime" (0.0%) widgets/columns. platform.getCurrentValidators reports
connected=null and uptime=0 for every validator on the public RPC (the API
node does not track peer uptime), so those numbers were fabricated-looking
zeros. Only chain-verifiable metrics (count, stake, delegation fee,
delegators) remain -- real data, no fake numbers.
Co-authored-by: Hanzo Dev <[email protected]>
The explorer Go backend answers by Host header via the ingress default backend,
so api-explore.lux.network responded 200 with no ingress rule — but with no TLS
block for that SNI the controller served the self-signed INGRESS DEFAULT CERT,
which browsers reject (ERR_CERT_AUTHORITY_INVALID). The explorer FE was stuck in
skeleton loaders. Add a dedicated Ingress -> explorer-unified:8090 with a
letsencrypt-prod TLS block (mirrors api-explore.osage.network). Verified live:
explore.lux.network now loads live blocks/txns/stats (ssl_verify_result=0).
Co-authored-by: Hanzo Dev <[email protected]>
The zoo/hanzo/pars brand deployments had been crashlooping at 0 ready since
June: their brand images bake NETWORK_NAME/currency/colors, but the runtime
envs-validator requires NETWORK_NAME in the rendered env and the brand
configmaps never set it — so every pod restart died on "NEXT_PUBLIC_NETWORK_NAME
is a required field". The lux configmap already carries SKIP_ENVS_VALIDATION for
the identical OIDC-placeholder reason; add it to the three brand configmaps
(mainnet + testnet) so they boot on their baked brand identity. Restores the
three brand explorers and lets the just-corrected chainId (pars 494949) + /v1
RPC configmap values take effect.
Co-authored-by: Hanzo Dev <[email protected]>
The deploy job's DO_API_TOKEN jq could parse-error on a non-JSON KMS response
and abort under set -e before the DIGITALOCEAN_ACCESS_TOKEN fallback; swallow it.
LLM.md records the v1.1.6 chain-switcher fix + live Playwright verification and
flags wallet-connect (needs NEXT_PUBLIC_WALLET_CONNECT_PROJECT_ID secret) + the
pre-existing intermittent homepage error-boundary.
Co-authored-by: Hanzo Dev <[email protected]>
ChainSwitcher put onClick={handleToggle} on the PopoverTrigger's button, which
double-toggled against PopoverTrigger's own open/close handling (net: stays
closed) — the switcher never opened, so no chains were selectable. Removed the
redundant onClick + unused handleToggle, matching the working popover pattern
(UserProfileDesktop). PopoverTrigger now drives open state via onOpenChange.
Co-authored-by: Hanzo Dev <[email protected]>
explore-fe-lux gets account/OIDC via runtime env; OIDC_* lack build-time
placeholders so SKIP_ENVS_VALIDATION=true (canonical_build.sh approach) —
make_envs still writes them to window.__envs. LLM.md records deploy path,
OIDC wiring, the useProvider crash, and Pars(7070/494949)+devnet(96370/96367)
chainId flags.
Co-authored-by: Hanzo Dev <[email protected]>
The KMS login (curl -sf | jq) had no failure guard, so under Actions' default
bash -eo pipefail a failed KMS login aborted the step before the
DIGITALOCEAN_ACCESS_TOKEN fallback ran (deploy failed instead of falling back).
Swallow curl/jq errors so the fallback path executes.
Co-authored-by: Hanzo Dev <[email protected]>
v1.1.4 changed useProvider to return null (react-query v5 forbids undefined)
but only switched the lib/web3 hooks. Four UI consumers kept
'const { data: { wallet } = {} } = useProvider()'; '= {}' defaults only
undefined, not null, so null data threw 'Cannot destructure property wallet
of {} as it is null' -> whole-page error boundary. Fixed to
'useProvider().data ?? {}' in ChainWidget, MultichainEcosystemsTableItem,
NetworkAddToWallet, AddressAddToWallet (+ wrap a pre-existing 169-char line).
Co-authored-by: Hanzo Dev <[email protected]>
The deploy job restarted deployment/lux-frontend-mainnet, which does not
exist (real name: explore-fe-lux, per deploy/k8s/explore-fe + the mainnet
ingressroute), and its KMS DO_API_TOKEN fetch returns empty so every deploy
silently skipped. Fix: (1) fall back to the DIGITALOCEAN_ACCESS_TOKEN repo
secret when KMS has no token; (2) 'kubectl set image' explore-fe-lux to the
freshly built ghcr.io/luxfi/explore:sha-<short> across mainnet/testnet/devnet
and wait on the mainnet rollout.
Co-authored-by: Hanzo Dev <[email protected]>
generate-well-known.js regenerates public/.well-known/explore.json from the
chain registry at build time, so the v1.1.4 hand-edit of the output file was
overwritten by the generator (which still appended ' Subnet'). Fix the
generator — the single source of truth — so the shipped manifest actually
uses 'Network' (Lux nomenclature; no 'Subnet'). Regenerated file is in sync
(wellknown:check passes). Pars id follows the registry (7070) to keep the
manifest consistent with its source; the 7070-vs-live-494949 question is
tracked separately in LLM.md.
Co-authored-by: Hanzo Dev <[email protected]>
- wallet: brandFamilyChains derives sibling networks (Lux mainnet/testnet/devnet)
from the multi-tenant chain registry so connect/add presents EVERY registered
network for the brand, not just the env chain; dedupe by id.
- login/menu: useProvider queryFn returns null (react-query v5 forbids undefined)
+ callers switched from '= {}' destructure default to '?? {}' so a null result
no longer crashes the wallet hooks (the busted-menu root cause).
- manifest: fix Pars chainId 7070 -> 494949 (regression) and drop the forbidden
'Subnet' term from sovereign L1 network names (-> '<Brand> Network').
- Validators page + /api/pchain proxy present; rebuild makes the live 5-validator
view visible on explore.lux.network.
Co-authored-by: Hanzo Dev <[email protected]>
Request the indexer's bound `symbol` in the markets query and use it as the
authoritative pair label when it parses as BASE/QUOTE, falling back to live
token-metadata resolution then short addresses. One pair, one source of truth.
Co-authored-by: Hanzo Dev <[email protected]>
Replace the hardcoded demo DEX dataset (incl. the placeholder pi-million 24h volume) with live markets + fills from the C-Chain 0x9999 subgraph at the per-network /v1/graph/cchain/dex/graphql endpoint, selected via config.apis.general like every other resource. Token pairs resolve through the existing token metadata endpoint, falling back to a short address. Empty/unavailable nets render 'No active markets' — never mock.
Guard tx.transaction_types in TxsListItem so coinbase/precompile txs (absent transaction_types in the API payload) no longer crash the block Transactions tab; drop an unused destructured prop. Allow CLOB in cspell.
zeekay
