2d80325c3bbffe4a673ebba32f7d122f90a1a10c
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
4d9d41888a
|
fix: a miner's balance is a receipt total, and the supply figures were wrong
Two claims this repository shipped, both disproved by measuring mainnet. **A mining address is keyless, so its balance can only rise.** `retained` was documented here as "the one measure privacy cannot hide", reasoning that a payment debits the account whichever route it takes. It does not. `mining-rewards` pays `derive_wormhole_address(preimage)`, which no Dilithium keypair signs for, and `Wormhole::credit_and_record` credits an exit's destination with `Unbalanced::increase_balance` while never debiting the note's source. QUANPOOL's balance rose at all twelve samples between blocks 1,000 and 42,400 and fell at none, nonce 0 throughout — as every miner's must. So `retained` read ~100% for everyone because it had to, and a number identical for all reads as an accusation aimed at whoever mined most. The column is gone, `balance` is `received`, and the table says plainly that a pool paying out in full and one paying nothing produce the same row. **Four empty lock maps are not "nothing is withheld".** Locks, Holds, Freezes and Reserves are all empty — counted, not assumed — and the network page concluded circulating equals total issuance. Wrong by a factor of 436: this runtime vests from a *pot*, not with locks, and `modlqvesting` holds 5,669,940 QTC, 99.54% of every unit of balance on the chain. The page now reports the pot and issuance-minus-pot, and still declines the word "circulating" because the release schedule is not read here. The pot address is derived from `Vesting::PalletId` in metadata rather than a hard-coded `qvesting`: it is a consequence of a runtime constant, and a runtime that changed it would leave the site reporting an empty pot while looking perfectly healthy. Both steps are pinned against the real mainnet metadata fixture. Also recorded: never sum account balances and call it supply. They exceed `TotalIssuance` by 13,427 QTC at block 42,400 and by exactly zero at genesis, bisecting to block 4,800 and a `verify_public_batch` — private value is counted twice by any such total. Single blocks reconcile exactly, so a spot check says everything is fine. Refs #17 Closes #19 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
365cd7a803
|
fix(ui): "sent nothing" was a claim this chain cannot support
The distribution table shipped with a `sent on` column reading zero for every
miner, which implies nothing left those addresses. On this chain that is not
what a zero means, and the correction came from the observation that payouts are
themselves wormhole transactions.
`Wormhole::NativeTransferred` records `to` and `amount` and does not record who
sent it. Splitting the events by the extrinsic that produced them shows what
that costs:
(no extrinsic — initialisation) hidden 23,876 events 72 recipients
Utility::batch_all visible 15,303 2,145
Wormhole::verify_public_batch hidden 8,136 538
Balances::transfer_allow_death visible 6,941 651
Wormhole::verify_private_batch hidden 1,758 116
Hidden-sender transfers in block initialisation are mining rewards. The 9,894
produced by `verify_public_batch` and `verify_private_batch`, reaching 654
recipients, are real payments with no origin recorded — the chain's privacy
working as designed. So the column was blind to exactly the mechanism a
wormhole-held balance would use to pay out, while reading as proof it had not.
It is `sent visibly` now, the note leads with the limit rather than burying it,
and a `retained` column carries the one measure privacy cannot hide: balance
over what the chain paid in. A payment debits the account whichever route it
takes, so a balance that has never fallen is a balance nothing has left.
A second correction, from running the table over the full index rather than a
dev slice: *every* one of the top 25 miners shows zero visible outflow and holds
almost exactly what it mined, including another address calling itself
`quantus-mainnet-pool`. Zero outflow is universal among mining addresses and
distinguishes nobody. The accounts distributing to hundreds of recipients have
never mined a block — they are funded from the genesis endowment — so setting a
miner beside them is a category error, and one this repository made before the
numbers came in.
Refs #17
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
|
df2306660a
|
feat(ui): show where the mining rewards went
A table on the network page: each miner's share of blocks, what the chain paid it, what it holds, what it has sent on, and to how many distinct addresses. Built to answer a concern without ever being the thing that makes the accusation. There is no badge, no flag and no word like "delinquent" anywhere in it. What earns it its place is comparison — one miner's recipient count says almost nothing, and beside its neighbours' it says a great deal — so the reader draws the conclusion and the site lays out the evidence and names its limits. Three limits are on the page, not in a footnote: - an operator may hold several addresses, settle off-chain, or be a solo miner keeping what it earned, which is the ordinary case and unremarkable - `sent on` counts only transfers out of the address the chain pays, so an operator distributing from a different wallet shows nothing - the name column is the weakest and comes from telemetry rather than the chain. There is no such thing as a "pool" here: the word appears only inside a name an operator chose for its own node `holds` is chain state and `mined`/`sent on`/`recipients` are over the indexed range, which the note spells out — on a partially indexed chain a miner appears to hold far more than it ever mined, and that discrepancy looks exactly like the thing the table is for. The window is fixed at 100,800 blocks rather than carried from the route: the window selector is hidden on this page, so the route's value would mean the shares silently reflect whatever span the reader last chose on the standings, invisibly and differently for two people reading the same page. The longest window is also the right one for the question — what a miner did with its rewards is about the chain's history, not its last hour. Refs #17 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jp6a8EDar9ueEhAxzep4V5 |