Premise being tested: mining pools are the best surface for making wormhole
transfers observable, because payouts must leave a pattern in the batches.
The pattern is there. It is mostly not payouts, and a naive reading of it is
badly wrong. This issue records the measurement and what the page should show.
The naive reading, and why it fails
Grouping Wormhole::NativeTransferred by producing extrinsic gives a shape that
looks exactly like payroll:
verify_public_batch 846 batches avg 9.7 outputs max 120
verify_private_batch 1773 batches avg 1.0 outputs max 2
distinct recipients across public batches 538
recipients appearing in more than one batch 317
most batches a single recipient appears in 774
Two things break it.
Batch size is an aggregation artifact, not a payer.pallet-wormhole's own
documentation: a public-batch proof "parses into one segment per inner private
batch", and "a private batch is aggregated client-side, so a segment corresponds
to one client". A 120-output public batch is therefore many unrelated clients
bundled by an aggregator, not one entity paying 120 people. Batch size measures
aggregator throughput.
The most recurrent recipient is the aggregator. The address appearing in 774
batches appears in 91.5% of all public batches and 0% of private ones:
That is the aggregator rebate settle_exit_bundle mints to the proof's aggregator_address, not somebody's payee. Likewise QUANPOOL's mining address
appears in 501 batches for 7.54 QTC total — 0.015 each — which is the miner
fee share credited to whichever block author included the batch.
After the machinery is removed
Classifying every public-batch credit — "infrastructure" being an address
credited in more than 20% of all batches submitted by anyone:
Three addresses take 76% of everything the exits pay out. Any page that
presents batch cohorts without saying so is describing aggregator plumbing and
calling it an economy.
What is left is real, and is worth showing
Among the 515 genuine recipients, recurrence is strongly skewed:
35 addresses paid 20 or more times take 67% of the non-infrastructure value,
at twice the average credit of everyone else. That is a recurring-payment shape.
It is consistent with pool payouts and is not proof of them — the chain records
no sender, so nobody can be named, and a regular payee could equally be an
exchange deposit, a salary, or one person moving their own funds on a schedule.
Build
One table on the wormhole page, six rows: the two machinery classes, then the
four recurrence bands. Stated as what it is — the shape of who gets paid, with
the sender unknowable — and with the 76% said out loud, because that is the
number that stops the table being read as a pool ledger.
Premise being tested: mining pools are the best surface for making wormhole
transfers observable, because payouts must leave a pattern in the batches.
The pattern is there. **It is mostly not payouts**, and a naive reading of it is
badly wrong. This issue records the measurement and what the page should show.
## The naive reading, and why it fails
Grouping `Wormhole::NativeTransferred` by producing extrinsic gives a shape that
looks exactly like payroll:
```
verify_public_batch 846 batches avg 9.7 outputs max 120
verify_private_batch 1773 batches avg 1.0 outputs max 2
distinct recipients across public batches 538
recipients appearing in more than one batch 317
most batches a single recipient appears in 774
```
Two things break it.
**Batch size is an aggregation artifact, not a payer.** `pallet-wormhole`'s own
documentation: a public-batch proof "parses into one segment per inner private
batch", and "a private batch is aggregated client-side, so a segment corresponds
to one client". A 120-output public batch is therefore *many unrelated clients*
bundled by an aggregator, not one entity paying 120 people. Batch size measures
aggregator throughput.
**The most recurrent recipient is the aggregator.** The address appearing in 774
batches appears in **91.5% of all public batches and 0% of private ones**:
```
call | batches | containing_top | pct | avg_outputs | max_outputs
----------------------+---------+----------------+------+-------------+------------
verify_private_batch | 1773 | 0 | 0.0 | 1.0 | 2
verify_public_batch | 846 | 774 | 91.5 | 9.7 | 120
```
That is the aggregator rebate `settle_exit_bundle` mints to the proof's
`aggregator_address`, not somebody's payee. Likewise QUANPOOL's mining address
appears in 501 batches for **7.54 QTC total** — 0.015 each — which is the miner
fee share credited to whichever block author included the batch.
## After the machinery is removed
Classifying every public-batch credit — "infrastructure" being an address
credited in more than 20% of all batches submitted by anyone:
```
kind | addresses | credits | qtc | avg_each
-----------------+-----------+---------+--------+---------
infrastructure | 3 | 1646 | 4014.8 | 2.4391
recipient | 515 | 3167 | 1233.9 | 0.3896
miner fee share | 21 | 242 | 5.2 | 0.0215
```
**Three addresses take 76% of everything the exits pay out.** Any page that
presents batch cohorts without saying so is describing aggregator plumbing and
calling it an economy.
## What is left is real, and is worth showing
Among the 515 genuine recipients, recurrence is strongly skewed:
```
recurrence | addresses | credits | qtc | avg_each
------------+-----------+---------+-------+---------
once | 213 | 213 | 52.0 | 0.244
2-4 times | 157 | 405 | 94.0 | 0.232
5-19 times | 110 | 981 | 260.9 | 0.266
20+ times | 35 | 1568 | 827.1 | 0.527
```
35 addresses paid 20 or more times take **67% of the non-infrastructure value**,
at twice the average credit of everyone else. That is a recurring-payment shape.
It is consistent with pool payouts and is not proof of them — the chain records
no sender, so nobody can be named, and a regular payee could equally be an
exchange deposit, a salary, or one person moving their own funds on a schedule.
## Build
One table on the wormhole page, six rows: the two machinery classes, then the
four recurrence bands. Stated as what it is — the shape of who gets paid, with
the sender unknowable — and with the 76% said out loud, because that is the
number that stops the table being read as a pool ledger.
Refs #17, #19.
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.
Premise being tested: mining pools are the best surface for making wormhole
transfers observable, because payouts must leave a pattern in the batches.
The pattern is there. It is mostly not payouts, and a naive reading of it is
badly wrong. This issue records the measurement and what the page should show.
The naive reading, and why it fails
Grouping
Wormhole::NativeTransferredby producing extrinsic gives a shape thatlooks exactly like payroll:
Two things break it.
Batch size is an aggregation artifact, not a payer.
pallet-wormhole's owndocumentation: a public-batch proof "parses into one segment per inner private
batch", and "a private batch is aggregated client-side, so a segment corresponds
to one client". A 120-output public batch is therefore many unrelated clients
bundled by an aggregator, not one entity paying 120 people. Batch size measures
aggregator throughput.
The most recurrent recipient is the aggregator. The address appearing in 774
batches appears in 91.5% of all public batches and 0% of private ones:
That is the aggregator rebate
settle_exit_bundlemints to the proof'saggregator_address, not somebody's payee. Likewise QUANPOOL's mining addressappears in 501 batches for 7.54 QTC total — 0.015 each — which is the miner
fee share credited to whichever block author included the batch.
After the machinery is removed
Classifying every public-batch credit — "infrastructure" being an address
credited in more than 20% of all batches submitted by anyone:
Three addresses take 76% of everything the exits pay out. Any page that
presents batch cohorts without saying so is describing aggregator plumbing and
calling it an economy.
What is left is real, and is worth showing
Among the 515 genuine recipients, recurrence is strongly skewed:
35 addresses paid 20 or more times take 67% of the non-infrastructure value,
at twice the average credit of everyone else. That is a recurring-payment shape.
It is consistent with pool payouts and is not proof of them — the chain records
no sender, so nobody can be named, and a regular payee could equally be an
exchange deposit, a salary, or one person moving their own funds on a schedule.
Build
One table on the wormhole page, six rows: the two machinery classes, then the
four recurrence bands. Stated as what it is — the shape of who gets paid, with
the sender unknowable — and with the 76% said out loud, because that is the
number that stops the table being read as a pool ledger.
Refs #17, #19.