Accrue: claim, number and historical-data audit

Audit date: 10 September 2026 (UTC). Baseline snapshot: 19:29:18 UTC. Prepared for Mo’s public buyback and burn dashboard.

Finding and scope

The dashboard’s arithmetic was internally consistent, but its underlying evidence was not strong enough to describe every claim as verified. This review found unit errors, a Foundation-versus-chain identity collision, historical events presented alongside current programs, and cumulative totals without a sufficiently specific reporting date or supporting ledger. These are material problems for valuation: an accurately calculated ratio can still be misleading when its numerator measures a different token, period, activity or funding source.

The baseline contained 2,254 raw project rows and 181 rows classified as buyback or burn projects. An independent Python calculation checked six core metric relationships for every raw row: annual revenue, annual fees, annual holder revenue, market-cap/revenue, FDV/revenue and FDV/market-cap. All 13,524 checks matched within numerical tolerance. That result establishes computational consistency with the stored inputs; it does not independently establish the truth of those inputs.

Historical-source discovery covered every one of the 181 eligible baseline rows. Revenue summary routes resolved for 154; 27 remained unavailable through the tested candidates. A successful HTTP response was not treated as identity verification. Some routes returned a different financial entity, and others returned a leaf identifier for a legitimate singleton parent. Those situations are separated in the history ledger. Revenue, fee and holder series were then checked individually, rather than treating failure of the holder-revenue endpoint as failure of every data type.

The post-review registry contains 557 entries. The claim ledger records all of them, including excluded, historical and provisional records. Nine entries have a narrowly scoped primary-source review summary from this pass, including the excluded Sui storage-fund entry. Other mechanism classifications remain explicitly provisional. This is a bounded data-quality audit, not a certification of every project’s claims, proof of all on-chain transactions, or a guarantee that the universe contains every eligible token.

How to read the evidence

Four kinds of information must remain separate. Provider-reported financial data means a number was obtained from a named financial feed. Arithmetic checked means the calculation can be reproduced from its inputs. Primary source reviewed means the relevant organization’s documentation, governance record or execution announcement supports the stated description. Transaction reconciliation would require checking the actual complete set of transactions, token contracts, prices and reporting cutoffs; that standard has not been met for the dashboard’s cumulative totals.

An organization’s official documentation is useful evidence about a program, but it is not an independent audit of execution. A governance proposal establishes proposed terms, not necessarily an enacted or currently operating program. An execution announcement can establish that purchases occurred, while still being insufficient to establish the latest cumulative total. These distinctions are reflected in the new profile evidence language and machine-readable records.

The numerical ledger preserves the baseline inputs and labels them provider-reported. The registry ledger preserves legacy claims so a reviewer can investigate them without those claims continuing to appear as verified profile prose. Undated cumulative totals are suppressed from the public metric model. A field-completeness score is now explicitly described as completeness, not a verification score. A high legacy confidence label does not override the new evidence status.

Corrections to specific claims

ApeX: percentages, historical burns and locked purchases

The registry stored 50 in a field measured in APEX tokens, while its description referred to approximately half of original supply. ApeX’s final quarterly-burn announcement identifies the completed 2024 supply reduction to 500 million APEX, and its later buyback policy describes purchases held for three years. The October 2025 execution update documents initial purchases and their lockup. These are different events and mechanisms.[1][2][3]

The erroneous 50-token total was removed. Current repurchases are classified as treasury-held purchases rather than ongoing burns. The historical supply reduction remains described with its historical context; it is not inserted as a newly verified cumulative burn total. The previous 70% allocation was also removed: the official policy starts at 50% and permits increases, which does not establish a current point estimate of 70%. Matching that policy to the provider’s measured revenue denominator remains necessary before valuation use.

Sui: Foundation revenue is not chain gas revenue

The official Sui buyback page says stablecoin yield funds open-market SUI purchases that are distributed to ecosystem participants. It expressly distinguishes these purchases from burns. Separately, the storage-fund documentation describes permanently retained non-refundable storage fees.[4][5]

The baseline Foundation row had the chain’s history slug and a burn classification. Its snapshot 30-day revenue was $225,124, while the incorrectly selected chain summary reported $41,295. The corrected Foundation route identifies provider record 3181 and returns $225,124, matching that baseline snapshot. Foundation buybacks remain eligible, with redistribution as their destination. The separate storage-fund row is excluded from the actual buyback/burn scope. Neither gas-fee revenue nor permanently locked storage balances are substituted for the Foundation’s buyback spending.

The official buyback page contains rounded figures and estimates. Those page values were not imported as a complete transaction ledger or a current cumulative total. The source establishes the mechanism; stronger evidence is still needed for a precisely dated spending history.

Hyperliquid: dollar fees cannot become token counts

Hyperliquid L1’s registry contained 14,820,000 in a token-count field while the associated note referred to approximately $14.82 million of all-time fees. The token figure was removed. The L1 row’s fee and deployment-auction scope is kept separate from application trading-fee repurchases.

The old assertion that Assistance Fund HYPE was not burned was also outdated. Current Hyperliquid documentation describes automatic trading-fee conversion into HYPE and the Assistance Fund’s HYPE as permanently removed from circulating and total supply. The main Hyperliquid description now follows that documentation, without assigning a universal fee percentage or claiming a currently reconciled cumulative total.[6]

Jito: buybacks exist, but funding and activation matter

Jito’s official CSD report documents executed purchases. Its subsequent JIP-37 distinguishes Q3 2026 treasury-funded matching purchases from protocol revenue allocated to BAM subsidies. JIP-38 concerns the DAO’s share of JTX fees and ties its buyback/burn commitment to that product’s launch.[7][8][9]

The dashboard retains the documented buyback classification. It no longer treats the JTX commitment as a fixed allocation of all Jito revenue, and the unsupported 13.48 million-token burn total is removed. The updated summary distinguishes the established purchases, later governance mandates and unreconciled execution of the newer program. A current cumulative burn figure is not inferred from a proposal or a news report.

Lighter, edgeX and Unichain

Lighter’s own documentation supports trading-fee-funded LIT buybacks through TWAP execution. It does not, by itself, reconcile the exact cumulative burn figure previously entered in the registry. That figure and the unsubstantiated burn certainty are withheld. The project’s category is corrected from payments/cards to perpetuals and derivatives.[10]

edgeX had 4.8 in a token-count field without enough evidence to establish the intended unit or scale. The audit does not guess whether it meant tokens, millions of tokens, or a percentage. The field is cleared, and other undated cumulative spending claims are held behind the same evidence requirement.

Unichain’s copied UNI burn total is removed from the chain row. A token-wide cumulative burn cannot be assigned to every revenue-producing product using that token. Uniswap’s current developer documentation supports fee-driven UNI burns after the December 2025 governance change, but fee activation varies across pools and versions. Its historical treasury burn must remain separate from recurring fee-funded activity.[11]

Exclusions and retained ether.fi coverage

Four.meme’s own legacy research already admitted that the FORM-level mechanism was unverified. A launchpad feature that buys back a newly launched token is not sufficient proof of FORM purchases. The record is now explicitly unverified and excluded from the current eligible list. This does not prove that FORM never has buybacks; it states that this dashboard cannot substantiate that inclusion.

Vertex’s official transition announcement describes the VRTX token sunset. The old record also described a one-time wind-down event while leaving its current burn flag active. It is now historical and excluded from current comparables.[12]

ether.fi remains included. Current official documentation describes withdrawal-fee-funded weekly ETHFI purchases and broader protocol-revenue purchases, with redistribution to sETHFI holders. A percentage of withdrawal revenue cannot be multiplied by all parent revenue. An eETH redemption burn is not an ETHFI burn.[13]

Ethereum remains a fee-burn project under the base-fee destruction specified by EIP-1559. Priority fees are separate, and the existence of a burn does not establish net deflation after issuance.[14]

Historical-data reconciliation

Three broken parent routes were repaired: Venus Finance resolves to venus, Marinade Finance to marinade, and Origin DeFi to origin-protocol. The source identifiers match the intended parent records. The Sui Foundation mapping was corrected separately. THORChain’s chain record now selects the native chain route, instead of the DEX’s summary.

The history handler now checks the returned provider identifier against the requested project. Two reviewed singleton-parent exceptions are explicit: Superchain for Optimism Foundation and the Ekubo leaf for its parent. There is no broad rule that the same token or a similar name makes two source records interchangeable. A scope mismatch yields unavailable history with an explanatory message rather than a plausible but incorrect chart. Missing expected identifiers on legacy standalone records remain a limitation recorded in the ledger.

The baseline sweep found 154 available revenue series and 154 fee series; 145 in each group contained all 30 complete UTC days. Holder series were available for 138 candidates, with 130 covering every complete day. These are source-route coverage counts before exclusions and identity corrections, not counts of independently verified projects. The ledger includes the first and last source timestamps in the archived JSON and the 30/90-day coverage in the public CSV.

No duplicate raw timestamps were detected in the successfully fetched series. Negative historical observations were present for several projects, including Azuro, Polygon, Spark and BONK.fun. Those observations are not automatically errors: provider definitions can include net profit, adjustments or refunds. They are retained and flagged for interpretation rather than converted to positive values. Counts in the ledger cover the complete returned history, not only the plotted 90-day window.

Twenty project/dimension comparisons exceeded the review threshold of both $100 and 1% of the snapshot value. Some were confirmed identity mistakes. Others involved matching identifiers but different overview and summary totals, including PONs, Pump, Sushi, Kinetiq and WOOFi. Different refresh times, adapter revisions or aggregation scopes can explain differences, but this audit has not proven a single cause for all of them. The runtime now displays a reconciliation warning when its summary total materially differs from the snapshot. It does not silently force one provider view to equal another.

Charts use complete UTC days and preserve missing buckets as null. A missing day is not a zero. Partial histories may show the sum of reported observations, but they cannot support the same annualized comparison as a complete window. Historical market-cap and FDV charts use observations actually collected by the dashboard; current prices are not retroactively painted onto earlier dates.

Numerical controls and valuation limits

The largest numerical control change is the separation of address balances from burned supply. An ERC-20 balanceOf result or a Solana token-account balance establishes inventory at an address. Without evidence about the account, token, mechanism and transaction history, it does not establish permanent destruction. The enrichment adapter now stores a typed address-balance observation and leaves cumulative burned tokens unchanged. Regression tests cover preservation of the existing total and correct token-decimal conversion.

A cumulative number can enter the curated public model only with evidence attached to that specific field: a non-future reporting date, a linked source, a cumulative scope and the correct unit. The numeric value must be finite and non-negative. These checks do not automate substantive source verification; a reviewer must still establish the evidence. At baseline, 65 eligible rows had legacy burn totals and 52 had legacy USD buyback totals without adequate field-level support. Those inputs are preserved in the audit inventory and withheld from current public metrics. Their removal means unavailable, not zero.

Market capitalization and price are refreshed separately from supply. The market pipeline derives circulating supply from market cap divided by price where possible, while maximum and total supply come from the CoinGecko cache. The profile now exposes the cache’s own timestamp. A newly generated snapshot no longer implies that every supply input was fetched at that time. FDV remains a model using current price and the available supply basis; its existing fallback and clamp labels remain relevant.

The annual-revenue default is the most recent 30-day total multiplied by 365/30. It is a run-rate estimate, not a forecast, audited annual revenue or net profit. When the 30-day input is unavailable, the model’s annual-source fallback is disclosed. A correctly computed market-cap/revenue multiple does not resolve provider methodology differences, token rights, operating costs, dilution or the funding source of purchases.

Likewise, holder revenue is not universally burn spending. It may represent distributions, staking rewards, purchases, or another provider-defined destination. The earlier denominator gate remains in place: a curated percentage is not multiplied by protocol revenue unless that denominator was explicitly reviewed. Six priced baseline projects had eligible allocation estimates under that rule; all other unsupported ratios remain unavailable. Cumulative USD amounts and unspecified USD observations cannot be annualized as if they were periodic spending.

Reproducibility, maintenance and residual uncertainty

The machine-readable outputs are part of the result, not optional supporting material. claim-ledger.csv contains the full registry and its review statuses. claim-numbers.csv contains the eligible baseline financial inputs and legacy cumulative claims. claim-history.csv contains one row per project and financial dimension, with source identity, coverage, totals, discrepancies and errors. The local data/claim-audit directory preserves the baseline, successful source responses, supply cache, analysis and corrected snapshot.

scripts/claim-audit.ts reproduces baseline capture and source discovery; scripts/claim-ledger.py independently recalculates the six metric relationships and builds the public CSVs. Network results are time-dependent. Archived baseline values should not be presented as the latest dashboard values after a refresh. Historical source responses may also be revised by their provider.

The fixes are covered by unit and integration checks for evidence gating, token units, future dates, source identity, historical aliases, program exclusions, address balances and wire-format metadata. Browser verification covers navigation, eligible project scope, profile popups, comparisons and logo decoding. Deployment and post-refresh outcomes are recorded separately in the validation note so that intended changes are not confused with observed production behavior.

This review does not establish that every legacy mechanism is valid or that every eligible project has been found. It also does not reconcile every provider total to every underlying transaction, establish the latest status of all governance decisions, or guarantee that historical revisions will never occur. The appropriate public claim is narrower: known errors were corrected, calculations were reproduced, uncertain claims are visibly identified or withheld, and the remaining work is traceable to specific records and sources.

For ongoing maintenance, the highest-value next step is a dated transaction ledger for the most economically significant programs, with separate purchase amount, token amount, destination, funding stream and block range. That would allow measured period spending and actual supply retirement to replace many unavailable or implied figures. Until then, the dashboard should be used as a transparent screening and research tool with explicit evidence boundaries.

Sources

[1] ApeX final quarterly supply reduction.

[2] ApeX buyback program terms, September 2025.

[3] ApeX execution milestone, October 2025.

[4] Sui Foundation revenue and buybacks.

[5] Sui storage-fund mechanism.

[6] Hyperliquid fee routing and Assistance Fund.

[7] Jito CSD executed buyback report.

[8] Jito JIP-37: Q3 funding and buyback mandate.

[9] Jito JIP-38: JTX revenue commitment.

[10] Lighter LIT utility and buybacks.

[11] Uniswap current fee architecture.

[12] Vertex transition and token sunset.

[13] ether.fi current ETHFI buyback program.

[14] Ethereum base-fee burn specification.

[15] DefiLlama financial-data definitions. Individual tested API URLs are included in the history ledger.