# Comparable residual-series research pack: documentation sample Status: exploratory specification v1. This is **not an observed data sample**. There are no measurement rows and no synthetic numerical holdings in this download. The accompanying CSV is a header only, for inspecting the proposed schema. An observed numeric sample is gated on source-by-source rights review and provenance checks. No redistribution rights to third-party source data are granted by this document. ## Research question and scope How does the residual Bitcoin supply change between editions with a consistent fund-coverage definition, loss assumption and institutional classification? The proposed output is an edition-level research table, not a census of people, addresses, beneficial owners, or trades. The current offer is documentation-only: this specification, data dictionary and schema header, with methodology at https://btcregister.com/method. No provider-data export or measurement rows are included; a numeric sample requires source-by-source rights review. ## Calculation residual_btc = circulating_btc - corporate_btc - included_funds_btc - government_btc - lost_assumption_btc residual_share_of_circulating = residual_btc / circulating_btc The denominator is circulating supply, not the maximum supply or a post-loss adjusted supply. The result is a residual, not directly measured retail holdings. Missing institutional coverage can make it too large. ETF/fund holdings can represent individual investors, so the holder vehicle does not establish the beneficial owner's identity. A loss assumption is not an observation. ## Data dictionary Empty cells mean unknown/not established, never zero. A future released record must document source availability and rights; all field names below are proposed. Decimal BTC values must not gain precision beyond the underlying inputs. Dates are ISO 8601; timestamps are UTC with a Z suffix. CSV uses UTF-8 and RFC 4180 quoting; free-text cells need spreadsheet-formula escaping on export. | Field | Type / unit | Definition and required handling | | --- | --- | --- | | edition_at | UTC timestamp | Register publication/edition time. Not a trade or purchase date. | | observation_date | date or empty | Shared observation date only if established for the whole record. Otherwise empty; retain component dates. | | supply_source_date | date or empty | Observation date stated by supply source, not silently replaced by retrieval date. | | corporate_source_date | date or empty | Common corporate observation date only if supported; mixed dates belong in notes and source references. | | funds_source_date | date or empty | Observation date of included fund input. Mixed dates must be disclosed. | | government_source_date | date or empty | Source date for government estimates; older assumptions do not become current on a new edition. | | circulating_btc | decimal BTC | Circulating supply used as denominator. Must be positive. | | corporate_btc | decimal BTC | Sum of covered corporate holdings under the stated method. Listed treasury vehicles remain corporate, not ETFs. | | included_funds_btc | decimal BTC | Only non-overlapping funds within funds_basis. Do not add an individual fund to an aggregate that already includes it. | | government_btc | decimal BTC | Covered government estimates; disclose incomplete coverage and stale inputs. | | lost_assumption_btc | decimal BTC | Explicit assumed lost/inaccessible supply, not measured losses. | | residual_btc | decimal BTC | Unrounded result of the subtraction above. Validate before display rounding; never silently clamp invalid values. | | residual_share_of_circulating | decimal fraction | Residual divided by circulating supply. Display as percent only when explicitly labelled. | | funds_basis | text | Precise included-fund universe. The current site's method uses an IBIT-only basis; it is not the whole ETF market. | | method_version | text | Stable identifier for calculation/classification rules; change when the rules change. | | comparability_group | text | Consecutive segment with matching coverage, loss assumption and method. A switch away and back still starts a new segment. | | quality | enum | observed-inputs, mixed-estimates, reconstructed, or scenario. A derived residual is never a direct ownership observation. | | source_references | JSON array as quoted CSV text | Component-level source URL, observation date (if known), retrieval timestamp, provenance note and permission basis. References alone are not redistribution permission. | | rights_status | enum | pending, cleared-for-stated-use, or excluded. Release no numeric record unless its included inputs/derivation are cleared for the specified use. | | notes | text | Gaps, estimates, stale dates, reclassifications, revisions and interpretation limits. | ## Comparable-series rules - Use the same funds_basis, loss assumption and method within each consecutive comparability group. Never join incompatible points into a continuous trend. - Keep reconstructed historical points and scenarios separate from observed inputs. No interpolation can be labelled an observed monthly series. - Use one consistent set of inputs for the overview, current series point and scenario starting point. Explain revisions without overwriting their origin. - Separate source observation dates from retrieval and publication dates. A snapshot difference does not establish when BTC was bought or sold. - Retain source references and uncertainty alongside calculations; do not imply complete institutional coverage or identify the residual with households. - Test arithmetic and non-overlap. Reject incomplete/invalid inputs rather than filling gaps with invented values. Preserve full internal precision and state public rounding conventions in any agreed pilot. ## Release and licensing gate The site currently cites CoinGecko for supply/corporate inputs, an issuer file for IBIT and separately dated government estimates. Citation and public access are not a commercial redistribution licence. Source terms, extraction limits, derivative-data permissions, required attribution and intended use must be checked for each component before any numeric sample or bulk pack is supplied. Where permission is missing, omit the affected data or agree a permitted alternative; do not imply that documentation-only delivery includes data rights. No availability, commercial terms, delivery schedule or API service is promised. ## Scoping a pilot Request the research question, date range, required fields, acceptable coverage limits, intended internal/public use and output format via: https://btcregister.com/data-product#request No checkout, automatic data delivery or mailing-list signup is attached to the request. The submission is saved for private manual review, and a reply is not guaranteed. Documentation is available without registration. ## Public methodology references - https://btcregister.com/method - https://btcregister.com/split - https://btcregister.com/majority These explain the current site's method; they do not constitute a rights grant.