mirror of
https://github.com/luxfi/explore.git
synced 2026-09-24 00:28:18 +00:00
main
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  zeekayandHanzo Dev
|
56c0e129b2 |
fix(explore): a block's fee label must follow the policy at THAT block
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]>
|
||
|
zeekayandHanzo Dev
|
d556673dff |
fix(explore): nothing has been burned — stop labelling the fee a burn
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]> |
||
|
zeekay
|
2abb742d55 |
feat(explore): fee burn + staking rewards panel, from one balance
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.
|