Methodology

What counts as a primary source

A holdings figure is considered verified only when it traces to one of:

• SEC filings — 10-K, 10-Q, and 8-K filings read from EDGAR, linked by their canonical EDGAR archive URL.
• Home-exchange or home-regulator disclosures — for non-US issuers, the filing venue where the company actually reports (for example TDnet in Japan or HKEX in Hong Kong).
• Issuer investor-relations publications — the company's own IR dashboard, press releases, or published holdings files.

Third-party aggregators are not primary sources and are never cited or named as a source anywhere in the public dataset — a build gate scans every public row field to enforce this. As of the 2026-08-29 snapshot, 23 of the 195 table rows carry a per-row citation with the source link and its as-of date; rows that predate the citation program are being backfilled and are not presented as verified.

Refresh cadence

• Daily (about 13:00 UTC): stock prices and share counts refresh, and every derived metric is recomputed. Market cap is always calculated as shares outstanding times stock price on a single share-count basis — a vendor-reported market cap is never used directly, so market cap, BTC per share, mNAV, and BTC/MCap % always agree.
• Filing-driven holdings updates: holdings change when a filing or issuer disclosure is verified. Strive's weekly holdings 8-K, for example, is polled hourly through its Monday filing window on EDGAR, parsed, run through an automated guard suite, and applied only if every guard passes — a guard trip halts the update and raises an alert for human review instead.
• Editorial corrections apply immediately: the tracker page merges the latest verified overrides when it loads, so a correction reaches readers before the next daily rebuild.

The exact timestamp of the data behind the page is shown beneath the table, and it is the data's own refresh stamp — not the page's render time — so a rebuild of unchanged data never masquerades as fresh holdings.

Corrections and manual overrides

When a tracker value is found to differ from what the issuer actually filed, an editor pins the corrected value as an override in a change-logged database. Override-pinned values take precedence over any automated feed, for one reason: each one is individually attested against a primary source, with the citation and its as-of date stored on the row. An automated feed value, however fresh, carries no such attestation.

The build enforces this: an override-pinned holdings value without its primary-source citation fails the build and cannot ship. Every applied correction is published in the public corrections log with before/after values, the reason, and the filing link — 10 value corrections and 2 removals to date.

Removed issuers (terminated SPACs, companies merged into another tracked issuer) are recorded in a permanent exclusion registry checked both when data is fetched and when the site builds, so a removed issuer cannot silently re-enter the dataset.

Accuracy gates

Five automated gates run against the committed data on every build and every refresh; any failure stops publication rather than shipping a suspect table:

• Row-sum invariant — the individual rows must sum to the published category total (within 1 BTC), and the row count must match the published company count exactly.
• Provenance — every editor-pinned holdings value must carry its primary-source citation and as-of date.
• No aggregator naming — no third-party aggregator may appear as a source in any public field.
• Percentage sanity — the published percentage of the 21 million supply must equal the recomputed value from the row data.
• Exclusion registry — no removed issuer may reappear.

The same discipline applies to the page copy: every count, total, and percentage rendered on the tracker (including the summary paragraph and FAQ answers) is derived from the data at build time. There are no hand-typed figures to go stale.

Issuers report differently — we follow the filing

"BTC held" is not a standardized disclosure. Issuers genuinely differ in what their reported figure includes, and this tracker follows each issuer's own balance-sheet presentation rather than forcing a uniform definition:

• Some totals include Bitcoin pledged as collateral or held as restricted assets, because that is how the issuer reports its position.
• Consolidation conventions differ: where a subsidiary is separately listed, its holdings appear on its own row and are excluded from the parent's row to avoid double-counting — the affected rows carry a footnote (marked with an asterisk in the table).
• Some issuers disclose composition details such as wrapped Bitcoin or lent balances; where a figure's basis is ambiguous across the issuer's own documents, the filed financial statements outrank presentations and decks.

Where a known holder discloses no unit count at all — only fiat carrying values — we do not infer one from carrying values or third-party estimates.

Inclusion criteria

The main table lists publicly traded companies with a positive, disclosed Bitcoin position on their own balance sheet. Private companies, governments, ETFs and funds, and DeFi protocols are tracked as category aggregates (shown in the chart above the table) but do not get table rows. A row whose remaining value cannot be substantiated against issuer disclosure is excluded from the table.

Announced-but-unclosed vehicles are not counted: Bitcoin that never reached a public company's balance sheet (for example, a terminated SPAC combination) is carried nowhere on this tracker.

What this tracker does not include yet

Capital-structure metrics — debt outstanding and preferred equity — are not shown on the tracker today. They are part of a planned expansion; when they ship, preferred equity will be reported as its own line, separate from debt, because the two carry different obligations and conflating them misstates leverage. Until those columns exist on the page, we make no capital-structure claims here.

Cost basis appears for issuers that disclose it and is otherwise blank — it is never estimated.

Staleness monitoring

Freshness is watched from two independent directions: the refresh pipeline alarms when the holdings source delivers zero changed rows for seven consecutive days (a "flatline" — the failure mode that looks green from every other angle), and an external monitor checks the live page's data date and raises an alert when it lags more than two days. If the data behind this page exceeds that threshold, the tracker shows a notice that holdings are being verified against the latest filings rather than presenting a silently stale table.

The tracker is currently migrating from a legacy third-party holdings feed to direct primary-source ingestion. During this transition, holdings movement comes from the filing-driven paths described above — the weekly 8-K ingest, verified corrections, and editor-pinned overrides — while prices and share counts continue to refresh daily.

Questions or discrepancies

If a figure here disagrees with an issuer's own filing, use the "suggest an update" form on the tracker page. Corrections that survive verification against the primary source are applied and published in the corrections log.