Stonkholders,
The public ledger is exceptionally good at answering a narrow question.
What happened?
A token moved from one account to another. The mint is visible. The sending authority is visible. The recipient, amount, slot and signature are visible. The record is exact, permanent and available to anyone sufficiently interested in opening it.
This creates an understandable temptation to proceed directly to the dashboard.
Management has reviewed the temptation.
The problem is that a transaction records movement, not meaning.
It does not necessarily say which project generated the reward. It does not say which historical holding period earned it. It does not say whether the transfer is one complete distribution or one piece of a larger cycle. It does not say whether another project using the same reward asset could explain the same recipient set.
Those are attribution questions. They require evidence the transfer does not contain.
The distinction sounds procedural until a number is placed beside a wallet.
At that point it becomes the product.
The ledger observes. The attribution layer explains.
At reward-mint level, the chain is unusually cooperative.
It can show that a wallet received a precise amount of STONK from a known payout authority. That statement is about the reward asset and the transfer. It does not become a statement about $STONKS merely because the recipient also holds $STONKS.
The missing link is the project.
Several project tokens can be paired against the same quote token. Their holders may therefore receive the same reward asset through common distribution infrastructure. The verified census contained 43 STONK-quoted reward launches, all of which had paid out.
One asset can therefore sit beneath many project-specific stories.
Timing, current ownership and aggregate market share can all provide context. None of them assigns a particular payment to a particular recipient. Each shortcut converts an observation into a conclusion by adding an assumption.
The Research Department has adopted the less efficient policy of adding evidence.
One reward asset, many candidate projects
The attribution problem begins with the candidate universe.
For any payout cycle, the relevant question is not which projects use STONK today. It is which projects used STONK, existed and were capable of paying at that point in history.
This distinction corrected an early result. STONKDEX had initially been included in cycles occurring before it launched. Filtering every candidate by launch slot removed those invalid comparisons.
Omitting a real project forces its payouts toward the remaining candidates. Including a project before it existed creates false confidence in the opposite direction. In both cases, the arithmetic can remain immaculate while the conclusion is wrong.
A candidate is not proven merely because it fits. It is proven only when the relevant alternatives fit materially worse, or when independent accounting isolates it exactly.
The holder set is historical
A reward distribution reflects ownership at some earlier point.
The current holder list is therefore evidence about the present, not the past.
Wallets consolidate token accounts. They transfer between accounts they control. They sell their full balance. Accounts close. Pool vaults appear among the largest token accounts while remaining ineligible for holder rewards. A present-day snapshot forgets much of this by design.
Historical reconstruction restores it.
The method discovers the token-account graph, walks every account history, follows newly revealed accounts and replays balances in canonical order. Closed accounts remain part of the record. The reconstruction is pinned to one target slot so that a long crawl does not combine states observed at different times.
Across the complete STONK-quoted universe, all 43 candidate projects were reconstructed to one target slot, covering 12,473 token accounts, including 3,566 closed accounts, and 131,061 holder events.
The graph had to close. Account histories had to be exhausted. Event streams had to remain continuous. The aggregate history had to anchor back to genesis, and the endpoint had to reconcile exactly where a valid comparison was available.
If the historical holder set is incomplete, the attribution is incomplete.
The transaction is sometimes the wrong unit
The first version of almost every ledger analysis begins with transactions.
The chain encourages this. Transactions have signatures. They have slots. They arrive as neat objects.
Economic events are less considerate.
Real payout cycles were split across several transactions, with each transaction carrying no more than 20 recipients in the exclusive-mint validation set. Recipient chunks within a cycle were disjoint and landed within a small number of slots.
Comparing a complete holder population with one 20-recipient transaction would make a correct project look incorrect. The cycle, not the transaction, is the relevant unit.
The shared payout ledger contained 454 real multi-recipient cycles. Ten two-recipient distributions were deliberately excluded because the sample was too small to meet the evidence standard.
The payments remain observable. Their project meaning remains unclaimed.
Management considers this a feature.
Exhibit A · From transaction to attribution
The ledger supplies stage one.
Everything beneath it is the cost of the label.
Allocation rules also have history
Historical balances are necessary, but they are not sufficient.
The distribution rule must also be correct for the period being examined.
Later cycles followed a proportional rule. Earlier cycles followed a different fingerprint with a cycle-specific slope and fixed deduction. Applying the later rule to the earlier period rejected economically large cycles whose recipients clearly belonged to the correct project.
The project was right. The model version was wrong.
A production attribution system must therefore carry the allocation model as provenance, detect when distributions stop fitting the known rule and avoid smoothing a protocol change into a convenient average.
Historical analytics often fail quietly when today's definition is applied to yesterday's data.
The numbers still calculate.
They simply calculate something that never happened.
Reconciliation is the control, not the ceremony
A classifier can always produce a winner if it is required to choose one.
The Research Department does not require this.
An attribution must clear minimum evidence requirements, separate from alternative candidates and reconcile against independent project accounting. If two candidates remain too close, the cycle is ambiguous. If history is incomplete, it is unattributed. If the sample is too small, it is refused.
Across the full 43-project universe, the final reconciliation credited zero projects beyond their own first-party accounting.
For $STONKS, the final offline attribution recovered 20,919 of 21,022 first-party payout recipients, or 99.51%. It attributed 99.05% of first-party distributed raw value.
The remainder was not distributed across the most likely wallets. It stayed in the residual: 62,265,071,425,393 raw units across 103 unattributed payout recipients.
This is what fail-closed means in practice.
It does not mean the system has failed to produce a number.
It means the system has declined to manufacture the final decimal.
The public label follows directly: Attributed STONK rewards. Not complete lifetime rewards. Not every reward ever earned. Coverage is part of the result.
The first universe is the expensive one
Reconstructing a quote-token universe requires a fixed body of work: enumerate the projects, record launch slots, crawl account histories, recover closed accounts, identify allocation models, classify payout cycles and capture independent totals for reconciliation.
That is the bootstrap.
Once the universe exists, a new project sharing the same quote token does not require the analytical institution to be invented again. It requires one additional candidate history, one launch boundary, ongoing cycle ingestion and another participant in a classifier that already knows how to refuse weak results.
The marginal cost falls because the surrounding evidence already exists.
This does not make future coverage free.
A new project can introduce an unfamiliar token program, eligibility rule or allocation fingerprint. The candidate census must continue to update, and historical completeness must continue to be tested.
The first project in a shared universe is an investigation.
The next project is an extension of the file.
What the file makes possible
The immediate output is a defensible rewards dashboard.
The more important output is a reusable analytical record.
Once project identity, pair identity, historical wallet ownership, payout cycles, allocation-model versions and coverage are carried together, the system stops being a collection of transfers and becomes a longitudinal panel.
Distribution economics
Attributed rewards by project and pair through time; payout cadence, cycle size and recipient concentration; model-era changes; and the unresolved portion of each series.
Wallet history and behaviour
Cumulative attributed rewards, repeat participation and, where histories are complete, holding-period measures such as token-days and cohorts by entry period, balance band, persistence or exit. These are descriptions of observable behaviour, not claims about wallet identity or motive.
Comparative project and pair analysis
With consistent denominators, projects sharing the same quote asset can be compared on reward intensity, cadence, concentration, breadth and stability over common windows and allocation regimes. The comparison can identify difference. It cannot establish why the difference exists.
Universe, coverage and model risk
The census can show how the eligible project universe changes, where coverage begins and ends, which additions require a new allocation model, and when unexpected payout shapes or reconciliation drift indicate that the method has stopped fitting the present.
Exhibit B · The analytical file
None of these capabilities is automatic merely because the tables exist. Each depends on the completeness of the relevant numerator, denominator and historical window. Causal claims require evidence beyond the payout ledger.
The work also belongs beside the Pairing Simulator for a specific reason. Both systems depend on the identity of the pair.
Attribution history can provide factual context for scenario design: observed distribution ranges, wallet concentration, payout cadence and the historical behaviour of comparable project–quote relationships. It can separate an illustrative assumption from an observed baseline.
The simulator remains a scenario instrument, not a forecast. Attribution remains a record of observed distributions, not proof of what caused a market outcome. No integration is asserted here.
The counterweight
There is a reasonable objection to all of this.
Most readers do not want an attribution methodology. They want a number.
Management agrees.
The methodology should operate beneath the surface, make the label precise and appear only when the reader asks why the number deserves to be believed. Complexity is not itself evidence of quality. A complicated model can be wrong with greater administrative confidence.
The case for this work is narrower. Shared reward assets create real ambiguity. Historical ownership creates a real data problem. Payout chunking creates a real classification problem. Allocation changes create a real model-risk problem. Reconciliation supplies an independent control. The residual proves the control is willing to say no.
If a supported first-party source eventually supplies complete project-and-wallet payout records with exact historical provenance, much of this burden should be retired.
Until then, removing the work would not remove the ambiguity.
It would remove the record of it.
Conclusion
A blockchain transaction is an unusually reliable fact.
The temptation is to make it carry more meaning than it contains.
The Rewards Dashboard is not difficult because transfers are hard to find. It is difficult because the useful claim sits several evidentiary steps above them: this project, this wallet, this cycle, this historical holding state, this allocation rule, this amount, within this stated coverage.
That chain of proof is the product.
The unresolved portion is not an embarrassment to conceal. It is the visible boundary between measurement and assertion.
The ledger has closed the transaction. Management has kept the file open.
Source note
- Stonks on Stonk Research Department — Project-specific reward attribution and historical holder reconstruction, research state dated 24 August 2026.
Stonks on Stonk is an editorial and meme project. This Brief describes an attribution methodology and its analytical implications. It is not financial advice.