mirror of
https://github.com/luxfi/explore.git
synced 2026-09-24 00:28:18 +00:00
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]>