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

New Issue

grenade · 2026-09-14T08:46:25Z

grenade commented

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

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.

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.

grenade referenced this issue from a commit

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

feat: who the wormhole exits pay, and how much of it is the protocol itself

grenade closed this issue

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

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blackbeard/observer#20