A miner's balance is a receipt total, not a holding — the distribution table implies otherwise #19

New Issue

grenade · 2026-09-14T06:49:04Z

grenade commented

2026-09-14 06:49:04 +00:00

The distribution table on /:chain/network was built to let a reader judge whether a
large miner is paying out. Its holds column is that miner's System::Account free
balance, and retained is holds / mined.

Both are structurally meaningless, and the table's framing is unsafe as shipped.

A mining reward address has no signing key

pallets/mining-rewards pays qp_wormhole::derive_wormhole_address(preimage) — already
recorded in CLAUDE.md, and pinned offline by blackbeard-core::wormhole's test. That
address is a Poseidon2 hash output. No Dilithium keypair hashes to it, so nothing can
ever sign a transfer out of it.

The only way to move a mining reward is a wormhole exit, and
Wormhole::credit_and_record (pallets/wormhole/src/lib.rs:1348) credits the
destination with Unbalanced::increase_balance and never debits the source. The
reward address keeps its balance forever.

So a miner's balance is a cumulative ledger of every unit ever credited to it. It can
only rise. It says nothing whatsoever about what the operator still controls.

Measured

QUANPOOL (0xc680…98ec7c), every sample across the whole chain:

block  1,000   free        280.840 QTC   nonce 0
block  4,000   free      1,185.550 QTC   nonce 0   rose
block  8,000   free      2,332.500 QTC   nonce 0   rose
block 12,000   free      3,404.990 QTC   nonce 0   rose
block 16,000   free      4,824.770 QTC   nonce 0   rose
block 20,000   free      5,834.140 QTC   nonce 0   rose
block 24,000   free      6,795.530 QTC   nonce 0   rose
block 28,000   free      7,772.470 QTC   nonce 0   rose
block 32,000   free      8,618.340 QTC   nonce 0   rose
block 36,000   free      9,314.290 QTC   nonce 0   rose
block 40,000   free     10,057.090 QTC   nonce 0   rose
block 42,400   free     10,527.880 QTC   nonce 0   rose

Monotonic, nonce 0 throughout, never once falls. This is not QUANPOOL hoarding. It is
the only trajectory the runtime permits, and every miner on the leaderboard has the
same one.

Why this matters more than a wrong column

The concern that prompted the table was that QUANPOOL's balance is large and stationary.
That balance is large because it mined a lot and stationary because the runtime cannot
make it move. The observation that looked like evidence is a property of the address
type, shared by every miner on the chain, and it distinguishes nobody.

A table whose retained column reads ~100% for every miner — which it must, since
holds is a superset of mined for all of them — is not neutral. It reads as an
accusation levelled at whoever happens to be at the top, which on this chain is whoever
mined the most. That is the failure mode the table was explicitly designed to avoid and
it shipped with it anyway.

What to change

Rename holds. It is received, or credited to date. Never "holds", never
"balance" — both assert control that does not exist.
Remove retained. There is no ratio to compute: the numerator cannot decrease.
State on the page that a mining address is keyless, its balance can only rise, and
that payouts are necessarily invisible — they leave as wormhole exits crediting
unrelated accounts, with the source untouched.
The corollary for the reader: on this chain, a pool paying out perfectly and a pool
paying out nothing produce identical account balances. The balance column can
never answer the question, and the page must say so rather than implying it can.

Cross-references #17 (the same increase_balance behaviour breaks the supply figures
there) and the wormhole page, which is the only surface where payouts are observable at
all.

The distribution table on `/:chain/network` was built to let a reader judge whether a large miner is paying out. Its `holds` column is that miner's `System::Account` free balance, and `retained` is `holds / mined`. **Both are structurally meaningless, and the table's framing is unsafe as shipped.** ## A mining reward address has no signing key `pallets/mining-rewards` pays `qp_wormhole::derive_wormhole_address(preimage)` — already recorded in `CLAUDE.md`, and pinned offline by `blackbeard-core::wormhole`'s test. That address is a Poseidon2 hash output. **No Dilithium keypair hashes to it**, so nothing can ever sign a transfer out of it. The only way to move a mining reward is a wormhole exit, and `Wormhole::credit_and_record` (`pallets/wormhole/src/lib.rs:1348`) credits the *destination* with `Unbalanced::increase_balance` and **never debits the source**. The reward address keeps its balance forever. So a miner's balance is a cumulative ledger of every unit ever credited to it. It can only rise. It says nothing whatsoever about what the operator still controls. ## Measured QUANPOOL (`0xc680…98ec7c`), every sample across the whole chain: ``` block 1,000 free 280.840 QTC nonce 0 block 4,000 free 1,185.550 QTC nonce 0 rose block 8,000 free 2,332.500 QTC nonce 0 rose block 12,000 free 3,404.990 QTC nonce 0 rose block 16,000 free 4,824.770 QTC nonce 0 rose block 20,000 free 5,834.140 QTC nonce 0 rose block 24,000 free 6,795.530 QTC nonce 0 rose block 28,000 free 7,772.470 QTC nonce 0 rose block 32,000 free 8,618.340 QTC nonce 0 rose block 36,000 free 9,314.290 QTC nonce 0 rose block 40,000 free 10,057.090 QTC nonce 0 rose block 42,400 free 10,527.880 QTC nonce 0 rose ``` Monotonic, nonce 0 throughout, never once falls. This is not QUANPOOL hoarding. It is the only trajectory the runtime permits, and **every miner on the leaderboard has the same one.** ## Why this matters more than a wrong column The concern that prompted the table was that QUANPOOL's balance is large and stationary. That balance is large *because it mined a lot* and stationary *because the runtime cannot make it move*. The observation that looked like evidence is a property of the address type, shared by every miner on the chain, and it distinguishes nobody. A table whose `retained` column reads ~100% for every miner — which it must, since `holds` is a superset of `mined` for all of them — is not neutral. It reads as an accusation levelled at whoever happens to be at the top, which on this chain is whoever mined the most. That is the failure mode the table was explicitly designed to avoid and it shipped with it anyway. ## What to change - Rename `holds`. It is **received**, or **credited to date**. Never "holds", never "balance" — both assert control that does not exist. - Remove `retained`. There is no ratio to compute: the numerator cannot decrease. - State on the page that a mining address is keyless, its balance can only rise, and that **payouts are necessarily invisible** — they leave as wormhole exits crediting unrelated accounts, with the source untouched. - The corollary for the reader: on this chain, a pool paying out perfectly and a pool paying out nothing produce **identical** account balances. The balance column can never answer the question, and the page must say so rather than implying it can. Cross-references #17 (the same `increase_balance` behaviour breaks the supply figures there) and the wormhole page, which is the only surface where payouts are observable at all.

grenade referenced this issue

2026-09-14 08:46:25 +00:00

Who the wormhole exits actually pay — most of it is the protocol's own plumbing #20

grenade referenced this issue from a commit

2026-09-14 08:54:31 +00:00

fix: a miner's balance is a receipt total, and the supply figures were wrong

grenade closed this issue

2026-09-14 08:54:31 +00:00

grenade referenced this issue

2026-09-14 12:27:39 +00:00

A network page: the figures an analyst needs to judge ecosystem health #17

Sign in to join this conversation.