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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The distribution table on
/:chain/networkwas built to let a reader judge whether alarge miner is paying out. Its
holdscolumn is that miner'sSystem::Accountfreebalance, and
retainedisholds / mined.Both are structurally meaningless, and the table's framing is unsafe as shipped.
A mining reward address has no signing key
pallets/mining-rewardspaysqp_wormhole::derive_wormhole_address(preimage)— alreadyrecorded in
CLAUDE.md, and pinned offline byblackbeard-core::wormhole's test. Thataddress 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 thedestination with
Unbalanced::increase_balanceand never debits the source. Thereward 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: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
retainedcolumn reads ~100% for every miner — which it must, sinceholdsis a superset ofminedfor all of them — is not neutral. It reads as anaccusation 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
holds. It is received, or credited to date. Never "holds", never"balance" — both assert control that does not exist.
retained. There is no ratio to compute: the numerator cannot decrease.that payouts are necessarily invisible — they leave as wormhole exits crediting
unrelated accounts, with the source untouched.
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_balancebehaviour breaks the supply figuresthere) and the wormhole page, which is the only surface where payouts are observable at
all.