{ "version": 1, "categories": [ { "id": "price-models", "label": "Price models", "stack": "overlay", "unit": "EUR", "question": "What is one bitcoin worth, measured by what people paid rather than what it trades for?", "members": [ "price", "realized-price", "true-market-mean", "cointime-price", "transferred-price", "balanced-price", "delta-price", "cvdd" ] }, { "id": "market-value", "label": "Market value and cost basis", "stack": "overlay", "unit": "EUR", "question": "How much money is in bitcoin, and how much did it cost to get there?", "members": [ "market-cap", "realized-cap", "investor-cap", "thermocap", "thermocap-subsidy", "active-cap", "cointime-cap", "average-cap", "delta-cap" ] }, { "id": "am-i-in-profit", "label": "Am I in profit", "stack": "overlay", "unit": "ratio", "question": "Is the market above or below what holders paid for their coins?", "members": [ "mvrv", "mvrv-z-score", "nupl", "market-cap-to-thermocap", "supply-in-profit-share", "utxos-in-profit-share" ] }, { "id": "taking-profit", "label": "Are holders selling at a profit", "stack": "overlay", "unit": "ratio", "question": "Are the coins moving right now being sold at a gain or a loss?", "members": [ "sopr", "adjusted-sopr", "short-term-holder-sopr", "long-term-holder-sopr", "realized-profit-loss-ratio" ] }, { "id": "profit-and-loss-in-money", "label": "Profit and loss, in money", "stack": "overlay", "unit": "EUR", "question": "How much profit and loss is actually being taken, in euro?", "members": [ "realized-profit-loss-ratio", "realized-profit", "realized-loss", "net-realized-profit-loss", "unrealized-profit", "unrealized-loss" ] }, { "id": "coins-in-profit", "label": "What is above water", "stack": "panels", "unit": "mixed", "question": "How much of the supply, how many outputs and how many addresses are worth more than they cost?", "members": [ "supply-in-profit-share", "utxos-in-profit-share", "supply-in-profit", "supply-in-loss", "utxos-in-profit", "utxos-in-loss", "addresses-in-profit", "addresses-in-loss", "addresses-in-profit-share" ] }, { "id": "cycle-position", "label": "Cycle position", "stack": "panels", "unit": "mixed", "question": "Where in the cycle are we, on the fifteen indicators the dashboard ranks?", "members": [ "mvrv", "mvrv-z-score", "aviv", "cointime-mvrv", "supply-in-profit-share", "sopr", "long-term-holder-sopr", "realized-profit-loss-ratio", "price-vs-ath", "mayer-multiple", "puell-multiple", "coin-days-destroyed", "dormancy", "dormancy-flow", "supply-untouched-1y" ] }, { "id": "cycle-timing", "label": "Cycle timing", "stack": "panels", "unit": "mixed", "question": "Is this cycle early or late on the clock, rather than on valuation?", "members": [ "pi-ma111", "pi-ma350x2", "price-vs-ath", "mayer-multiple", "pi-cycle-ratio", "rhodl-ratio", "reserve-risk", "puell-multiple", "blocks-since-halving" ] }, { "id": "are-old-coins-moving", "label": "Are old coins moving", "stack": "panels", "unit": "mixed", "question": "Are coins that sat still for years waking up and changing hands?", "members": [ "reserve-risk", "coin-days-destroyed", "coin-days-destroyed-per-coin", "dormancy", "dormancy-flow", "liveliness", "slrv", "long-term-holder-spent-volume" ] }, { "id": "supply-by-age", "label": "Supply by age", "stack": "overlay", "unit": "BTC", "question": "How long has each bitcoin been sitting still? (HODL waves)", "members": [ "supply-aged-under-1d", "supply-aged-1d-1w", "supply-aged-1w-1m", "supply-aged-1m-3m", "supply-aged-3m-6m", "supply-aged-6m-1y", "supply-aged-1y-2y", "supply-aged-2y-3y", "supply-aged-3y-5y", "supply-aged-5y-7y", "supply-aged-7y-10y", "supply-aged-over-10y" ] }, { "id": "holder-cohorts", "label": "Long-term and short-term holders", "stack": "panels", "unit": "mixed", "question": "What are the patient holders doing, against the recent buyers?", "members": [ "short-term-holder-sopr", "long-term-holder-sopr", "long-term-holder-spent-volume", "long-term-holder-supply", "short-term-holder-supply", "long-term-holder-share", "realized-cap-155d", "realized-cap-1y", "lth-realized-cap-share", "supply-untouched-1y" ] }, { "id": "old-coins-spent-by-age", "label": "Coin-days destroyed by age", "stack": "overlay", "unit": "BTC-days", "question": "When old coins move, how old were they?", "members": [ "coin-days-destroyed-under-1d", "coin-days-destroyed-1d-1w", "coin-days-destroyed-1w-1m", "coin-days-destroyed-1m-3m", "coin-days-destroyed-3m-6m", "coin-days-destroyed-6m-1y", "coin-days-destroyed-1y-2y", "coin-days-destroyed-2y-3y", "coin-days-destroyed-3y-5y", "coin-days-destroyed-5y-7y", "coin-days-destroyed-7y-10y", "coin-days-destroyed-over-10y" ] }, { "id": "spent-volume-by-age", "label": "Spent volume by age", "stack": "overlay", "unit": "BTC", "question": "How many bitcoin moved today, split by how long they had been sitting?", "members": [ "spent-volume-aged-under-1d", "spent-volume-aged-1d-1w", "spent-volume-aged-1w-1m", "spent-volume-aged-1m-3m", "spent-volume-aged-3m-6m", "spent-volume-aged-6m-1y", "spent-volume-aged-1y-2y", "spent-volume-aged-2y-3y", "spent-volume-aged-3y-5y", "spent-volume-aged-5y-7y", "spent-volume-aged-7y-10y", "spent-volume-aged-over-10y" ] }, { "id": "cointime", "label": "Cointime", "stack": "panels", "unit": "mixed", "question": "How much of bitcoin is economically awake, and how much is vaulted?", "members": [ "liveliness", "vaultedness", "activity-to-vaulting-ratio", "active-supply", "vaulted-supply", "vaulting-rate", "cointime-adjusted-inflation", "cointime-adjusted-s2f", "cointime-adjusted-inflation-ark", "cointime-adjusted-s2f-ark" ] }, { "id": "cointime-prices", "label": "Cointime price models", "stack": "panels", "unit": "mixed", "question": "What is bitcoin worth once you weight coins by how long they sat still?", "members": [ "price", "true-market-mean", "active-realized-price", "vaulted-realized-price", "cointime-price", "cointime-price-coinblocks", "investor-cap", "active-cap", "cointime-cap", "cointime-nvt" ] }, { "id": "cointime-valuation", "label": "Cointime valuation ratios", "stack": "overlay", "unit": "ratio", "question": "How far is the price above the cointime cost bases? (peaks, lows and the centred one)", "members": [ "aviv", "active-mvrv", "vaulted-mvrv", "cointime-mvrv" ] }, { "id": "cointime-accounting", "label": "Cointime accounting", "stack": "panels", "unit": "mixed", "question": "The raw coin-time ledger: how much time is created, destroyed and stored each block?", "members": [ "coin-days-destroyed", "coin-days-destroyed-per-coin", "coin-days-created", "cumulative-coin-days-created", "cumulative-coin-days-destroyed" ] }, { "id": "supply-and-issuance", "label": "Supply and issuance", "stack": "panels", "unit": "mixed", "question": "How many coins exist, and how fast are new ones being minted?", "members": [ "blocks-since-halving", "circulating-supply", "supply-ex-burn", "burned-supply", "issuance", "subsidy-schedule", "inflation-rate", "inflation-rate-instantaneous", "stock-to-flow" ] }, { "id": "what-blockspace-cost", "label": "What blockspace cost", "stack": "overlay", "unit": "sat/vB", "question": "What did it cost to get a transaction into a block?", "members": [ "marginal-clearing-price", "median-feerate", "mean-feerate", "minimum-feerate", "maximum-feerate", "block-fees" ] }, { "id": "mining", "label": "Mining and miner revenue", "stack": "panels", "unit": "mixed", "question": "What are miners paid, and how hard is it to earn it?", "members": [ "thermocap", "thermocap-subsidy", "market-cap-to-thermocap", "puell-multiple", "issuance", "miner-revenue", "block-fees", "cumulative-fees", "fee-share-of-revenue", "difficulty" ] }, { "id": "how-full-are-blocks", "label": "How full are blocks", "stack": "panels", "unit": "mixed", "question": "How much blockspace is being used, and what shape is it?", "members": [ "block-size", "block-weight", "block-fill", "witness-bytes", "witness-share-of-weight", "witness-share-of-size", "weight-discount", "segwit-tx-share", "segwit-weight-share", "transactions-per-block" ] }, { "id": "what-blockspace-was-used-for", "label": "What blockspace was used for", "stack": "overlay", "unit": "share", "question": "Which kinds of transaction bought the blockspace, and paid for it?", "members": [ "inscription-weight-share", "inscription-fee-share", "runestone-weight-share", "runestone-fee-share", "consolidation-weight-share", "consolidation-fee-share", "batch-payout-weight-share", "batch-payout-fee-share", "coinjoin-shaped-weight-share", "coinjoin-shaped-fee-share" ] }, { "id": "data-on-the-chain", "label": "Data on the chain", "stack": "panels", "unit": "mixed", "question": "How much of the chain is data rather than money?", "members": [ "burned-supply", "op-return-outputs", "op-return-transactions", "op-return-payload-bytes", "inscription-count", "inscription-transactions", "inscription-body-bytes", "runestone-transactions", "burned-outputs" ] }, { "id": "network-activity", "label": "Network activity", "stack": "panels", "unit": "mixed", "question": "How much is the network actually being used?", "members": [ "transactions-per-block", "spent-outputs", "created-outputs", "utxo-count", "unspent-outputs-incl-unspendable", "utxo-set-change", "spent-volume", "non-coinbase-output-value", "raw-output-value", "active-addresses" ] }, { "id": "how-many-holders", "label": "How many holders", "stack": "panels", "unit": "count", "question": "How many addresses hold bitcoin, and how many are doing something today?", "members": [ "addresses-with-a-balance", "addresses-with-a-balance-addressable", "new-addresses", "addresses-ever-seen", "active-addresses", "sending-addresses", "receiving-addresses" ] }, { "id": "supply-by-wallet-size", "label": "Supply by wallet size", "stack": "overlay", "unit": "BTC", "question": "How is the supply spread between small holders and large ones?", "members": [ "supply-in-addresses-under-0p001", "supply-in-addresses-0p001-0p01", "supply-in-addresses-0p01-0p1", "supply-in-addresses-0p1-1", "supply-in-addresses-1-10", "supply-in-addresses-10-100", "supply-in-addresses-100-1k", "supply-in-addresses-1k-10k", "supply-in-addresses-10k-100k", "supply-in-addresses-100k-plus" ] }, { "id": "addresses-by-balance", "label": "Addresses by balance", "stack": "overlay", "unit": "count", "question": "How many addresses hold at least a whole coin, or a hundred, or a thousand?", "members": [ "addresses-holding-0p01-btc", "addresses-holding-0p1-btc", "addresses-holding-1-btc", "addresses-holding-10-btc", "addresses-holding-100-btc", "addresses-holding-1k-btc", "addresses-holding-10k-btc", "addresses-holding-100k-btc" ] }, { "id": "addresses-by-value", "label": "Addresses by value", "stack": "overlay", "unit": "count", "question": "How many addresses hold at least 100 euro of bitcoin, or a million?", "members": [ "addresses-holding-1-eur", "addresses-holding-10-eur", "addresses-holding-100-eur", "addresses-holding-1k-eur", "addresses-holding-10k-eur", "addresses-holding-100k-eur", "addresses-holding-1m-eur" ] }, { "id": "accumulation", "label": "Accumulation", "stack": "panels", "unit": "mixed", "question": "How much bitcoin sits in addresses that only ever receive?", "members": [ "accumulation-addresses", "accumulation-supply", "accumulation-addresses-ex-coinbase", "accumulation-supply-ex-coinbase" ] }, { "id": "data-quality", "label": "Data quality", "stack": "panels", "unit": "mixed", "question": "How trustworthy is the number you are looking at?", "members": [ "subsidy-schedule", "unspent-outputs-incl-unspendable", "price-quality", "eur-basis", "realized-cap-degraded-share", "supply-no-costbasis", "supply-no-costbasis-share", "live-output-value", "addresses-with-a-balance-addressable", "addresses-with-no-cost-basis" ] }, { "id": "coinjoin-rounds", "label": "CoinJoin rounds", "stack": "overlay", "unit": "count", "question": "How many people are mixing coins for privacy, and with which software?", "members": [ "coinjoin-transactions", "whirlpool-rounds", "wasabi-rounds", "joinmarket-rounds", "wide-mix-transactions" ] }, { "id": "coinjoin-footprint", "label": "What CoinJoin costs the chain", "stack": "panels", "unit": "mixed", "question": "How much money and how much blockspace do privacy joins actually account for?", "members": [ "coinjoin-volume", "coinjoin-inputs", "coinjoin-outputs", "coinjoin-transaction-share", "coinjoin-volume-share", "coinjoin-blockspace-share" ] }, { "id": "transfer-volume", "label": "What really changed hands", "stack": "overlay", "unit": "BTC", "question": "How much bitcoin actually moved between owners, rather than between one owner's own addresses?", "members": [ "transfer-volume", "transfer-volume-change-adjusted", "transfer-volume-entity-adjusted", "self-transfer-volume" ] }, { "id": "real-transactions", "label": "Transactions that went somewhere", "stack": "overlay", "unit": "count", "question": "How many transactions and outputs paid somebody else rather than the sender?", "members": [ "transactions-non-coinbase", "transactions-entity-adjusted", "self-transfer-transactions", "outputs-non-coinbase", "outputs-to-another-entity" ] }, { "id": "size-of-the-correction", "label": "Size of the self-transfer correction", "stack": "overlay", "unit": "share", "question": "How much of the raw volume and transaction count is just people shuffling their own coins?", "members": [ "entity-adjusted-share-of-volume", "change-adjusted-share-of-volume", "entity-adjusted-share-of-transactions" ] }, { "id": "how-many-owners", "label": "How many owners", "stack": "panels", "unit": "mixed", "question": "How many owners are there, once addresses spent together are folded into one?", "members": [ "active-entities", "sending-entities", "receiving-entities", "new-entities", "entities-ever-seen", "entities-with-a-balance", "supply-held-by-entities" ] }, { "id": "supply-by-owner-size", "label": "Supply by owner size", "stack": "overlay", "unit": "BTC", "question": "How is the supply spread between small owners and large ones, counting owners rather than addresses?", "members": [ "supply-in-entities-under-0p001", "supply-in-entities-0p001-0p01", "supply-in-entities-0p01-0p1", "supply-in-entities-0p1-1", "supply-in-entities-1-10", "supply-in-entities-10-100", "supply-in-entities-100-1k", "supply-in-entities-1k-10k", "supply-in-entities-10k-100k", "supply-in-entities-100k-plus" ] }, { "id": "owners-by-balance", "label": "Owners by balance", "stack": "overlay", "unit": "count", "question": "How many owners hold a whole coin, or a hundred, or a hundred thousand?", "members": [ "entities-holding-under-0p001", "entities-holding-0p001-0p01", "entities-holding-0p01-0p1", "entities-holding-0p1-1", "entities-holding-1-10", "entities-holding-10-100", "entities-holding-100-1k", "entities-holding-1k-10k", "entities-holding-10k-100k", "entities-holding-100k-plus" ] }, { "id": "supply-off-the-market", "label": "Supply off the market", "stack": "panels", "unit": "mixed", "question": "How much bitcoin sits with owners who have never sold, or barely sell?", "members": [ "illiquid-supply", "liquid-supply", "highly-liquid-supply", "illiquid-entities", "liquid-entities", "highly-liquid-entities", "never-spent-supply", "never-spent-entities", "never-spent-share" ] } ], "metrics": [ { "slug": "price", "series": "price_usd", "label": "Bitcoin price", "subtitle": "what one bitcoin trades for", "categories": [ "price-models", "cointime-prices" ], "canonical": "price-models", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "What one bitcoin costs right now on the open market. Every other line on this page exists to be compared against it.", "technical": "The spot price at each block, carried on a price clock of price_time = cummax(block nTime), taken from the price series and never re-derived. NULL below height 68,774, where no market existed, and never zero-filled.", "limit": "There is no bitcoin price at all before 17 July 2010, so the line simply starts there. The euro line is a real BTC-EUR order book from September 2013 onward and the dollar price converted at the ECB rate before that; which one a block used is recorded in the EUR basis diagnostic.", "keywords": [ "price", "btc price", "bitcoin price", "what is bitcoin worth", "spot", "koers" ], "seriesEur": "price_eur", "shape": "osc", "kind": "stock" }, { "slug": "realized-price", "series": "realized_price", "label": "Realized price", "subtitle": "the average price coins last moved at", "categories": [ "price-models" ], "canonical": "price-models", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "The average price every bitcoin last changed hands at. When the market price is above this line the average holder is up; when it falls below, the average holder is under water, which is historically where bottoms have formed.", "technical": "Realized cap divided by circulating supply. It divides by the FULL supply, including the pre-market coins that contributed nothing to the numerator; that is the standard definition and it is exactly the bias that active realized price removes.", "limit": "The 1.46M BTC mined before a market price existed (17 July 2010) carry a cost basis of zero rather than being dropped, so they flatter every profit measure built on this. Supply with no cost basis charts how much that is. In euro this is the global market's cost basis expressed in euro, not what European holders paid; before 2013 the euro price is the dollar price converted at the ECB rate.", "keywords": [ "cost basis", "what holders paid", "realized price", "bottom", "average buy price", "break even" ], "seriesEur": "realized_price_eur", "shape": "osc", "kind": "stock" }, { "slug": "true-market-mean", "series": "true_market_mean", "label": "True market mean", "subtitle": "what coins that actually trade cost their owners", "categories": [ "price-models", "cointime-prices" ], "canonical": "price-models", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "The best single estimate of what people actually paid for the bitcoin that genuinely circulates, ignoring both coins that came straight from mining and coins that never move. Price above it means active holders are in profit; price below it has marked deep bottoms.", "technical": "Investor cap / active supply, where investor cap = realized cap - thermocap and active supply = circulating supply x liveliness. From the ARK cointime paper, which also calls it the active-investor price.", "limit": "It inherits the unresolved thermocap question: the two source papers disagree on whether thermocap is the block subsidy alone or the subsidy plus fees, and we use the full coinbase output. The gap between the two readings has recently been 1-15% of miner revenue. In euro this is the global market's cost basis expressed in euro, not what European holders paid; before 2013 the euro price is the dollar price converted at the ECB rate.", "keywords": [ "true market mean", "what the market paid", "cost basis", "fair value", "active investor price" ], "seriesEur": "true_market_mean_eur", "shape": "osc", "kind": "stock" }, { "slug": "active-realized-price", "series": "active_realized_price", "label": "Active realized price", "subtitle": "cost basis with dormant and lost coins stripped out", "categories": [ "cointime-prices" ], "canonical": "cointime-prices", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "The same idea as realized price, but it only counts the coins that are economically awake, so coins that are lost or have sat in cold storage for a decade stop dragging the number down. It sits well above plain realized price.", "technical": "Realized cap / active supply. Active supply is circulating supply x liveliness, an equivalent volume rather than a set of particular coins, so it discounts dormant and lost coins without anyone having to decide which ones are lost.", "limit": "Liveliness is cumulative since genesis, so this line reacts slowly. In euro this is the global market's cost basis expressed in euro, not what European holders paid; before 2013 the euro price is the dollar price converted at the ECB rate.", "keywords": [ "active price", "cost basis without lost coins", "lost coins", "free float cost basis" ], "shape": "osc", "kind": "stock" }, { "slug": "vaulted-realized-price", "series": "vaulted_realized_price", "label": "Vaulted realized price", "subtitle": "cost basis measured against the hoard", "categories": [ "cointime-prices" ], "canonical": "cointime-prices", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "The cost basis measured against the coins that are NOT moving. It falls as more bitcoin is hoarded, which looks backwards until you see why: the more that is locked away, the less we know about how much of it is merely held and how much is lost forever.", "technical": "Realized cap / vaulted supply, where vaulted supply = circulating supply x (1 - liveliness).", "limit": "The counter-intuitive direction is the point, not a bug, but it makes this a poor line to read on its own. It is reliable near cycle lows and poor near peaks, which is the mirror of active MVRV. In euro this is the global market's cost basis expressed in euro, not what European holders paid; before 2013 the euro price is the dollar price converted at the ECB rate.", "keywords": [ "vaulted price", "hoarded coins", "cold storage", "bottom" ], "shape": "osc", "kind": "stock" }, { "slug": "cointime-price", "series": "cointime_price", "label": "Cointime price", "subtitle": "a floor built from how long coins sat still", "categories": [ "price-models", "cointime-prices" ], "canonical": "price-models", "unit": "EUR", "provisional": true, "quality": "reconstruction", "plain": "A floor-like estimate of what bitcoin is worth, built from how long coins had been sitting still before they moved and at what price they moved. Price touching it has coincided with the bottom of every cycle so far; price far above it means the market is stretched.", "technical": "Sum over all history of (price x coin-days destroyed), divided by cumulative coin-days stored. Also called the Blummer price. The ARK paper states the formula in coinblocks; this is the coin-days basis, which is what every public implementation publishes.", "limit": "Provisional, and it says so because it is not settled: our two source papers disagree with each other about cointime cap by 4.8% over a single day, in a measure that barely moves. The shape is usable, the exact level is not. In euro this is the global market's cost basis expressed in euro, not what European holders paid; before 2013 the euro price is the dollar price converted at the ECB rate.", "keywords": [ "floor", "bottom", "cointime price", "blummer price", "coinblocks", "is bitcoin cheap" ], "seriesEur": "cointime_price_eur", "sameAs": [ { "slug": "cointime-price-coinblocks", "relation": "basis-variant", "note": "The same formula on the coinblocks basis. The two agree to a correlation of 0.9999; they differ by about 1.3% in level." } ], "shape": "osc", "kind": "stock" }, { "slug": "cointime-price-coinblocks", "series": "cointime_price_coinblocks", "label": "Cointime price (coinblocks basis)", "subtitle": "the paper's verbatim version of the same floor", "categories": [ "cointime-prices" ], "canonical": "cointime-prices", "unit": "EUR", "provisional": true, "quality": "reconstruction", "plain": "The same floor estimate as cointime price, computed the way the original paper wrote it. It is published beside ours so the choice between the two ways of counting time is something you can see rather than something we assert.", "technical": "The ARK paper's verbatim formula: sum(price x coinblocks destroyed) / cumulative coinblocks stored. Coinblocks count one block of holding; coin-days count one day. Rob's 2026-08-05 call made coin-days the published basis.", "limit": "Provisional, and near-duplicate: it tracks the published cointime price at a correlation of 0.9999 and a typical level gap of 1.3%. Do not read it as a second opinion, only as a check on the basis.", "keywords": [ "coinblocks", "cointime price", "ark paper", "basis check" ], "sameAs": [ { "slug": "cointime-price", "relation": "basis-variant", "note": "Same formula, coin-days instead of coinblocks. r = 0.9999." } ], "shape": "osc", "kind": "stock" }, { "slug": "transferred-price", "series": "transferred_price", "label": "Transferred price", "subtitle": "the time-weighted average price coins moved at", "categories": [ "price-models" ], "canonical": "price-models", "unit": "EUR", "provisional": true, "quality": "reconstruction", "plain": "The average price bitcoin has changed hands at over all of history, with each move weighted by how long the coins had been sitting still first. It is one of the two ingredients of balanced price.", "technical": "Cumulative sum of (price x coin-days destroyed) divided by cumulative coin-days destroyed over priced blocks: a coin-day-weighted mean price.", "limit": "Reconstructed. No source publishes a closed form for this, so the shape is right but the level cannot be compared against anyone else's chart.", "keywords": [ "transferred price", "average price paid", "floor model" ], "shape": "osc", "kind": "stock" }, { "slug": "balanced-price", "series": "balanced_price", "label": "Balanced price", "subtitle": "a floor that has caught every cycle bottom", "categories": [ "price-models" ], "canonical": "price-models", "unit": "EUR", "provisional": true, "quality": "reconstruction", "plain": "A floor model: the gap between what holders paid and what the market has historically transferred coins at. Price falling to this line has marked the deepest part of past bear markets.", "technical": "Realized price minus transferred price.", "limit": "Reconstructed, because transferred price is: no source publishes a closed form, so the shape is usable and the exact level is not comparable to another provider's balanced price.", "keywords": [ "floor", "bottom", "balanced price", "is bitcoin cheap", "capitulation" ], "shape": "osc", "kind": "stock" }, { "slug": "delta-price", "series": "delta_price", "label": "Delta price", "subtitle": "another long-run floor model", "categories": [ "price-models" ], "canonical": "price-models", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "A slow-moving floor built from the difference between what holders paid and the long-run average market value. Historically the price has almost never closed below it.", "technical": "Delta cap / circulating supply, where delta cap = realized cap - average cap and average cap is the cumulative mean of market cap over priced blocks.", "limit": null, "keywords": [ "delta price", "floor", "bottom", "cycle low" ], "shape": "osc", "kind": "stock" }, { "slug": "cvdd", "series": "cvdd", "label": "CVDD", "subtitle": "Willy Woo's cumulative value-days-destroyed floor", "categories": [ "price-models" ], "canonical": "price-models", "unit": "EUR", "provisional": true, "quality": "reconstruction", "plain": "An old and widely quoted floor model built by spreading all the value that has ever moved across the age of the market. Price has touched it at cycle bottoms.", "technical": "Cumulative value-days destroyed divided by (days since genesis x 6,000,000).", "limit": "Provisional. The 6,000,000 constant is a scalar Willy Woo fitted by hand, not a quantity derived from anything, and it was fitted on data ending years ago. Treat the shape as informative and the exact level as a historical artefact.", "keywords": [ "cvdd", "floor", "bottom", "willy woo", "cycle low" ], "shape": "osc", "kind": "stock" }, { "slug": "pi-ma111", "series": "pi_ma111", "label": "111-day mean price", "subtitle": "the fast half of the Pi Cycle top signal", "categories": [ "cycle-timing" ], "canonical": "cycle-timing", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "The average price over the last 111 days. On its own it is just a smoothed price line; it matters because of where it crosses the slower line beside it.", "technical": "111-day moving mean of price, over priced blocks.", "limit": null, "keywords": [ "pi cycle", "moving average", "111 day", "top signal" ], "shape": "osc", "kind": "stock" }, { "slug": "pi-ma350x2", "series": "pi_ma350x2", "label": "2 x 350-day mean price", "subtitle": "the slow half of the Pi Cycle top signal", "categories": [ "cycle-timing" ], "canonical": "cycle-timing", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "Twice the average price over the last 350 days. When the faster 111-day line crosses above it, that is the Pi Cycle top signal, which has fired within days of the last three cycle highs.", "technical": "350-day moving mean of price multiplied by 2, over priced blocks.", "limit": null, "keywords": [ "pi cycle", "moving average", "350 day", "top signal", "tops" ], "shape": "osc", "kind": "stock" }, { "slug": "market-cap", "series": "market_cap", "label": "Market cap", "subtitle": "every coin valued at today's price", "categories": [ "market-value" ], "canonical": "market-value", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "What all the bitcoin in existence would be worth if every coin were valued at today's price. It is the headline size of the asset, and it is the numerator of most valuation ratios here.", "technical": "Circulating supply x price.", "limit": "It assumes every coin could be sold at the current price, which is untrue of any asset, and it counts coins that are provably lost.", "keywords": [ "market cap", "how big is bitcoin", "total value", "marktkapitalisatie" ], "seriesEur": "market_cap_eur", "shape": "osc", "kind": "stock" }, { "slug": "realized-cap", "series": "realized_cap", "label": "Realized cap", "subtitle": "what the market actually paid, in total", "categories": [ "market-value" ], "canonical": "market-value", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "The total amount of money that has actually gone into bitcoin, counting every coin at the price it last moved at rather than at today's price. Rising means real money is flowing in; flat or falling means coins are moving at a loss.", "technical": "Sum over unspent outputs of value x the price at the block that created them, carried incrementally: RC(h) = RC(h-1) + created_value(h) x price(h) - the cost basis destroyed at h.", "limit": "The 1.46M BTC mined before a market price existed (17 July 2010) carry a cost basis of zero rather than being dropped, so they flatter every profit measure built on this. Supply with no cost basis charts how much that is. In euro this is the global market's cost basis expressed in euro, not what European holders paid; before 2013 the euro price is the dollar price converted at the ECB rate.", "keywords": [ "realized cap", "money into bitcoin", "capital inflow", "cost basis", "aggregate cost basis" ], "seriesEur": "realized_cap_eur", "shape": "osc", "kind": "stock" }, { "slug": "investor-cap", "series": "investor_cap", "label": "Investor cap", "subtitle": "cost basis excluding coins bought from miners", "categories": [ "market-value", "cointime-prices" ], "canonical": "market-value", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "The part of the total cost basis that came from investors buying from other investors, rather than from miners selling new coins. Unlike the mining half, this can fall, which is what makes it react to people capitulating.", "technical": "Realized cap - thermocap. Verbatim from the ARK cointime paper.", "limit": "It inherits the unresolved thermocap question, and thermocap is flagged provisional while this is not, which is an inconsistency in the source catalogue rather than a statement of confidence. In euro this is the global market's cost basis expressed in euro, not what European holders paid; before 2013 the euro price is the dollar price converted at the ECB rate.", "keywords": [ "investor cap", "secondary market", "cost basis", "capitulation" ], "seriesEur": "investor_cap_eur", "shape": "osc", "kind": "stock" }, { "slug": "thermocap", "series": "thermocap", "label": "Thermocap", "subtitle": "everything miners have ever been paid, at the price of the day", "categories": [ "market-value", "mining" ], "canonical": "market-value", "unit": "EUR", "provisional": true, "quality": "reconstruction", "plain": "The total amount of money miners have ever earned, each coin counted at the price on the day it was mined. It can only go up, so it acts as a slow, hard floor under the cost of producing bitcoin.", "technical": "Cumulative FULL coinbase output (block subsidy plus fees) valued at the price of the block that mined it. The full coinbase reading is used because it makes realized cap = thermocap + investor cap an exact accounting identity.", "limit": "Provisional. The two source papers disagree on whether thermocap includes fees; ARK reads as the full coinbase, Glassnode as the minted coins only. We publish both, and the gap has recently been 1-15% of miner revenue. In euro this is the global market's cost basis expressed in euro, not what European holders paid; before 2013 the euro price is the dollar price converted at the ECB rate.", "keywords": [ "thermocap", "miner revenue", "security spend", "cost of production" ], "seriesEur": "thermocap_eur", "sameAs": [ { "slug": "thermocap-subsidy", "relation": "definition-variant", "note": "The subsidy-only reading of the same measure. They track at a correlation of 0.9999 and differ by about 4% in level." } ], "shape": "trend", "kind": "stock" }, { "slug": "thermocap-subsidy", "series": "thermocap_subsidy", "label": "Thermocap, subsidy only", "subtitle": "the other reading of thermocap, without fees", "categories": [ "market-value", "mining" ], "canonical": "mining", "unit": "EUR", "provisional": true, "quality": "reconstruction", "plain": "The same running total of miner earnings, but counting only the newly minted coins and leaving out transaction fees. It is published beside the main version so the disagreement between the two source papers is visible rather than quietly resolved.", "technical": "Cumulative block subsidy valued at the price of the mining block, fees excluded. The reading METRIC-IDEAS s1.7 attributes to the Glassnode paper.", "limit": "Provisional, and a near-duplicate: it tracks the full-coinbase thermocap at a correlation of 0.9999. Recently the two differ by 1-15% of miner revenue. Read the pair as one number with an error bar.", "keywords": [ "thermocap", "subsidy", "miner revenue", "definition check" ], "sameAs": [ { "slug": "thermocap", "relation": "definition-variant", "note": "The full-coinbase reading. r = 0.9999." } ], "shape": "trend", "kind": "stock" }, { "slug": "active-cap", "series": "active_cap", "label": "Active cap", "subtitle": "market cap of the coins that are economically awake", "categories": [ "market-value", "cointime-prices" ], "canonical": "market-value", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "Market cap weighted down to just the portion of bitcoin that is economically active, leaving out the share that has been sitting still. It is the numerator of AVIV.", "technical": "Market cap x liveliness.", "limit": "The euro line is a real BTC-EUR order book from September 2013 onward and the dollar price converted at the ECB rate before that; which one a block used is in the EUR basis diagnostic.", "keywords": [ "active cap", "free float", "cointime", "aviv" ], "shape": "osc", "kind": "stock" }, { "slug": "cointime-cap", "series": "cointime_cap", "label": "Cointime cap", "subtitle": "cointime price applied to the whole supply", "categories": [ "market-value", "cointime-prices" ], "canonical": "market-value", "unit": "EUR", "provisional": true, "quality": "reconstruction", "plain": "The cointime floor price applied to every coin in existence, so it can be compared directly with market cap.", "technical": "Cointime price x circulating supply.", "limit": "Provisional. METRIC-IDEAS s1.6 could not reconcile the two source papers here: they publish values 4.8% apart over a single day, in a measure that moves very slowly. Neither is treated as truth. The euro line is a real BTC-EUR order book from September 2013 onward and the dollar price converted at the ECB rate before that; which one a block used is in the EUR basis diagnostic.", "keywords": [ "cointime cap", "floor", "valuation" ], "shape": "osc", "kind": "stock" }, { "slug": "average-cap", "series": "average_cap", "label": "Average cap", "subtitle": "the long-run mean of market cap", "categories": [ "market-value" ], "canonical": "market-value", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "The average market cap over the whole of bitcoin's history to date. It is a very slow line, useful mostly as the other half of delta cap.", "technical": "Cumulative mean of market cap over priced blocks.", "limit": null, "keywords": [ "average cap", "long run average", "delta cap" ], "shape": "trend", "kind": "stock" }, { "slug": "delta-cap", "series": "delta_cap", "label": "Delta cap", "subtitle": "cost basis minus the long-run average value", "categories": [ "market-value" ], "canonical": "market-value", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "The gap between what the market paid and what it has been worth on average across its whole life. It is the raw form of the delta price floor model.", "technical": "Realized cap - average cap.", "limit": null, "keywords": [ "delta cap", "floor", "bottom" ], "shape": "osc", "kind": "stock" }, { "slug": "mvrv", "series": "mvrv", "label": "MVRV", "subtitle": "price against what holders paid", "categories": [ "am-i-in-profit", "cycle-position" ], "canonical": "am-i-in-profit", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "A high value means the price is far above what the average coin last changed hands for, which is where past cycle tops have clustered; a low value means the market is priced near or below what holders paid.", "technical": "Market cap / realized cap, where realized cap values every unspent coin at the price when it last moved.", "limit": "NUPL is this same number rearranged, exactly 1 - 1/MVRV to a measured maximum error of 4.44e-16, so NUPL was removed from the cycle dashboard rather than cast a second vote for the same fact. It still has its own chart. This also moves closely with MVRV Z-score and AVIV, which are related but not identical measurements. The euro version is not the dollar ratio converted: the euro realized cap is a running sum of past euro prices, so the two genuinely differ by the path of EURUSD, not just its level.", "keywords": [ "mvrv", "tops", "am i in profit", "is bitcoin overvalued", "cost basis", "cycle top" ], "seriesEur": "mvrv_eur", "sameAs": [ { "slug": "nupl", "relation": "algebraic-identity", "note": "NUPL = 1 - 1/MVRV, exact to 9.25e-14 across 4,462 sampled blocks." } ], "validFrom": 149994, "shape": "osc", "kind": "stock" }, { "slug": "mvrv-z-score", "series": "mvrv_z", "label": "MVRV Z-score", "subtitle": "how unusual today's gap is by the market's own standards", "categories": [ "am-i-in-profit", "cycle-position" ], "canonical": "am-i-in-profit", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "The same comparison as MVRV, but asking how unusual today's gap is by the market's own past standards: a high value is unusually stretched, a low value unusually cheap.", "technical": "(market cap - realized cap) / the expanding standard deviation of market cap, over priced blocks only.", "limit": "The standard deviation is measured over an expanding window, so each later cycle is scored against a longer history and peaks lower than the one before. Levels are not comparable across cycles; only the rank drawn on the cycle dashboard is.", "keywords": [ "mvrv z score", "tops", "bottoms", "is bitcoin expensive", "overvalued", "z score" ], "validFrom": 230733, "shape": "osc", "kind": "stock" }, { "slug": "nupl", "series": "nupl", "label": "NUPL", "subtitle": "how much of the market value is unrealised profit", "categories": [ "am-i-in-profit" ], "canonical": "am-i-in-profit", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "A high value means almost everyone holding bitcoin is sitting on a paper profit, so there is a lot of unrealised gain that could be sold; a low value means much of the supply is under water.", "technical": "(market cap - realized cap) / market cap. Exact by construction, not estimated.", "limit": "This is exactly 1 - 1/MVRV on our data, to a measured maximum error of 4.44e-16, so this and MVRV are one measurement shown twice. That is why NUPL was taken off the cycle dashboard on 2026-08-05 rather than cast a second vote for the same fact. It keeps its own chart.", "keywords": [ "nupl", "unrealised profit", "am i in profit", "paper gains", "euphoria", "capitulation" ], "seriesEur": "nupl_eur", "sameAs": [ { "slug": "mvrv", "relation": "algebraic-identity", "note": "NUPL = 1 - 1/MVRV, exact to 9.25e-14 across 4,462 sampled blocks." } ], "validFrom": 155164, "shape": "osc", "kind": "stock" }, { "slug": "aviv", "series": "aviv", "label": "AVIV", "subtitle": "the cointime-adjusted MVRV, centred on 1", "categories": [ "cointime-valuation", "cycle-position" ], "canonical": "cointime-valuation", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "The best-centred of this family: a high value means the coins that actually move are worth far more than they cost, a low value means they are worth less than was paid for them.", "technical": "Active cap / investor cap = (market cap x liveliness) / (realized cap - thermocap). Verbatim from the ARK cointime paper.", "limit": "Provisional in substance: thermocap can mean the block subsidy alone or the subsidy plus fees, and neither paper says which. We use the full coinbase output. Price / true market mean is the same quantity by another route, because the supply cancels: price / (investor cap / active supply) reduces to active cap / investor cap. That row was removed from the cycle dashboard rather than counted twice, and it has no chart of its own either, because it would be this one drawn again. The paper puts AVIV's median at 1.038 against MVRV's 1.601, so AVIV = 1 really is neutral where MVRV = 1 is deeply oversold.", "keywords": [ "aviv", "price to true market mean", "true market mean", "am i in profit", "overvalued", "cointime mvrv", "tops", "bottoms" ], "sameAs": [ { "slug": "active-mvrv", "relation": "near-duplicate", "note": "r = 0.995 since 2020." } ], "validFrom": 153968, "shape": "osc", "kind": "stock" }, { "slug": "active-mvrv", "series": "active_mvrv", "label": "Active MVRV", "subtitle": "profit multiple on the coins that trade", "categories": [ "cointime-valuation" ], "canonical": "cointime-valuation", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "How far the price sits above the cost basis of the coins that actually circulate. It is the most reliable of this family near cycle peaks and the least reliable near lows.", "technical": "Price / active realized price, where active realized price = realized cap / active supply.", "limit": "Reliable near cycle peaks, poor at lows; its mirror, vaulted MVRV, is the other way round. It also tracks AVIV closely (r = 0.995 since 2020), so the two are close to one vote. ", "keywords": [ "active mvrv", "tops", "overvalued", "cointime", "am i in profit" ], "sameAs": [ { "slug": "aviv", "relation": "near-duplicate", "note": "r = 0.995 since 2020." } ], "validFrom": 150101, "shape": "osc", "kind": "stock" }, { "slug": "vaulted-mvrv", "series": "vaulted_mvrv", "label": "Vaulted MVRV", "subtitle": "profit multiple against the hoard", "categories": [ "cointime-valuation" ], "canonical": "cointime-valuation", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "How far the price sits above the cost basis measured against the coins that are NOT moving. It is the mirror of active MVRV: reliable near cycle lows and poor near peaks.", "technical": "Price / vaulted realized price, where vaulted realized price = realized cap / vaulted supply.", "limit": "Reliable near lows, poor at peaks. It also tracks plain MVRV very closely (r = 0.993 over all history), so it adds less than the pairing suggests. ", "keywords": [ "vaulted mvrv", "bottoms", "undervalued", "cointime", "hoarding" ], "sameAs": [ { "slug": "mvrv", "relation": "near-duplicate", "note": "r = 0.993 over all history, 0.996 since 2020." } ], "validFrom": 71519, "shape": "osc", "kind": "stock" }, { "slug": "cointime-mvrv", "series": "cointime_mvrv", "label": "Cointime MVRV", "subtitle": "how far price is above the cointime floor", "categories": [ "cointime-valuation", "cycle-position" ], "canonical": "cointime-valuation", "unit": "ratio", "provisional": true, "quality": "reconstruction", "plain": "Cointime price is a floor-like estimate of what bitcoin is worth, built from how long coins sat still before they moved: a high value means the price is far above that floor, a low value means it is sitting on it.", "technical": "Price / cointime price, where cointime price = the sum of (price x coin-days destroyed) divided by coin-days stored.", "limit": "Provisional, and it says so because it is not settled: our two source papers disagree with each other about cointime cap by 4.8% over a single day, and the published formula is in coinblocks while this is the coin-days version everyone else publishes. The shape is usable, the exact level is not. It also tracks reserve risk almost exactly (r = 0.999), so those two are one signal.", "keywords": [ "cointime mvrv", "floor", "tops", "bottoms", "is bitcoin cheap" ], "aliasSeries": [ "cyc_cointime_ratio" ], "sameAs": [ { "slug": "reserve-risk", "relation": "near-duplicate", "note": "r = 0.9986 over all history, 0.995 since 2023. Both are price over a cumulative destruction-weighted denominator." } ], "validFrom": 70598, "shape": "osc", "kind": "stock" }, { "slug": "market-cap-to-thermocap", "series": "mcap_to_thermocap", "label": "Market cap to thermocap", "subtitle": "market value against everything miners were ever paid", "categories": [ "am-i-in-profit", "mining" ], "canonical": "mining", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "How much the market values bitcoin against the total amount ever paid to the miners who secured it. High readings have coincided with tops.", "technical": "Market cap / thermocap.", "limit": "It inherits thermocap's unresolved subsidy-or-full-coinbase question. It also tracks the MVRV Z-score fairly closely (r = 0.96 over all history), so it is not an independent vote.", "keywords": [ "thermocap multiple", "tops", "overvalued", "miner revenue" ], "sameAs": [ { "slug": "mvrv-z-score", "relation": "correlated", "note": "r = 0.96 over all history, 0.88 since 2020." } ], "validFrom": 69488, "shape": "osc", "kind": "stock" }, { "slug": "supply-in-profit-share", "series": "supply_in_profit_share", "label": "Supply in profit", "subtitle": "the share of all coins worth more than they cost", "categories": [ "am-i-in-profit", "coins-in-profit", "cycle-position" ], "canonical": "coins-in-profit", "unit": "share", "provisional": false, "quality": "price-dependent", "plain": "A high value means nearly every coin in existence is worth more than it last cost someone; a low value means a large share of all coins are held at a loss.", "technical": "Share of circulating supply whose cost basis is below the current price, from a 1,024-bin cost-basis histogram folded block by block.", "limit": "Coins mined before a market price existed (before 17 July 2010) carry a cost basis of zero, so they count as in profit forever. The measure also crowds against its own ceiling near tops, where it can only move between about 95% and 100%.", "keywords": [ "supply in profit", "am i in profit", "how many holders are up", "underwater", "tops" ], "seriesEur": "supply_in_profit_share_eur", "shape": "osc", "kind": "stock" }, { "slug": "utxos-in-profit-share", "series": "utxos_in_profit_share", "label": "Outputs in profit", "subtitle": "the share of unspent outputs worth more than they cost", "categories": [ "am-i-in-profit", "coins-in-profit" ], "canonical": "coins-in-profit", "unit": "share", "provisional": false, "quality": "price-dependent", "plain": "The same question as supply in profit, but counting outputs instead of coins, so a one-satoshi output weighs the same as a thousand-bitcoin one. It is closer to \"how many holders are up\" than \"how much money is up\".", "technical": "UTXOs in profit / UTXO set size, both on the UTXO-set basis, that is excluding provably unspendable data-carrier outputs, matching Core's gettxoutsetinfo.", "limit": "Outputs are not people. One wallet can hold thousands of outputs and one output can be a custodian holding for thousands of people. It tracks supply in profit at r = 0.85 over all history, so it does carry some independent information.", "keywords": [ "utxos in profit", "how many holders are up", "am i in profit", "outputs" ], "shape": "osc", "kind": "stock" }, { "slug": "sopr", "series": "sopr", "label": "SOPR", "subtitle": "are spent coins moving at a gain or a loss", "categories": [ "taking-profit", "cycle-position" ], "canonical": "taking-profit", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "A high value means the coins being spent are being sold at a profit, and have been for a while, which is what people cashing out looks like; a low value means sellers are taking losses.", "technical": "Realized value / value at creation for every coin spent. Above 1 = coins moving at a profit. The cycle ribbon ranks ln(SOPR), so the average taken before ranking is geometric.", "limit": "A single block's SOPR is whatever happened to move in that block, and the series spends most of its life very close to 1, so only a multi-day average carries a signal.", "keywords": [ "sopr", "are holders selling", "profit taking", "selling at a loss", "capitulation" ], "seriesEur": "sopr_eur", "validFrom": 231627, "shape": "osc", "kind": "flow" }, { "slug": "adjusted-sopr", "series": "asopr", "label": "Adjusted SOPR", "subtitle": "SOPR with same-day shuffling removed", "categories": [ "taking-profit" ], "canonical": "taking-profit", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "SOPR with very short-lived coins thrown out, so that wallets moving money between their own addresses do not look like people selling. It is the cleaner read of the two.", "technical": "SOPR excluding outputs younger than one hour, which is Glassnode's adjustment and removes same-block change and internal shuffling. The exact 3,600-second edge is available because ages come off the block clock, not off day buckets.", "limit": "One hour is a convention, not a natural boundary. Exchange internal transfers older than an hour are still counted as economic spends here, because we do not use address labels.", "keywords": [ "adjusted sopr", "are holders selling", "profit taking", "change outputs" ], "shape": "osc", "kind": "flow" }, { "slug": "short-term-holder-sopr", "series": "sth_sopr", "label": "Short-term holder SOPR", "subtitle": "are recent buyers selling at a gain or a loss", "categories": [ "taking-profit", "holder-cohorts" ], "canonical": "taking-profit", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "Whether the people who bought in the last five months are selling at a profit or at a loss. It swings hard, because recent buyers are the ones who panic.", "technical": "SOPR restricted to coins younger than 155 days.", "limit": "155 days is a convention borrowed from the industry, not a boundary that exists in the data.", "keywords": [ "short term holder sopr", "are new buyers selling", "panic", "capitulation", "sth" ], "validFrom": 231679, "shape": "osc", "kind": "flow" }, { "slug": "long-term-holder-sopr", "series": "lth_sopr", "label": "Long-term holder SOPR", "subtitle": "are patient holders selling at a large multiple", "categories": [ "taking-profit", "holder-cohorts", "cycle-position" ], "canonical": "taking-profit", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "A high value means the holders who have sat still for more than five months are selling at a large multiple of what they paid, which is the clearest distribution signal there is; a low value means even they are selling at a loss.", "technical": "SOPR restricted to coins 155 days or older, ranked on ln(). It read 4.27 at the 2017 top, 3.56 in 2021 and 0.80 in the 2022 capitulation.", "limit": "155 days is a convention borrowed from the industry, not a natural boundary in the data, and this carries fewer spends behind it than plain SOPR.", "keywords": [ "long term holder sopr", "are holders selling", "distribution", "tops", "lth" ], "shape": "osc", "kind": "flow" }, { "slug": "realized-profit-loss-ratio", "series": "realized_pl_ratio", "label": "Realized profit / loss ratio", "subtitle": "how much profit is taken for every euro of loss", "categories": [ "taking-profit", "profit-and-loss-in-money", "cycle-position" ], "canonical": "taking-profit", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "A high value means far more money is being taken off the table in profit than in loss; a low value means losses dominate, which is what capitulation looks like.", "technical": "Realized profit / realized loss, summed over the trailing 144 blocks. The ratio, not the net, and ranked on ln(ratio).", "limit": "It has to be a trailing daily sum: at per-block resolution the denominator is zero in most blocks and the raw ratio would be infinite about half the time.", "keywords": [ "profit loss ratio", "capitulation", "are holders selling", "profit taking" ], "validFrom": 269396, "shape": "osc", "kind": "stock" }, { "slug": "realized-profit", "series": "realized_profit", "label": "Realized profit", "subtitle": "money actually taken off the table in gains", "categories": [ "profit-and-loss-in-money" ], "canonical": "profit-and-loss-in-money", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "How much money holders actually locked in as profit by spending coins for more than they paid. Big spikes cluster around cycle tops, when everyone is selling into strength.", "technical": "Per block, summed over spent outputs where the spend price exceeds the creation price: value x (price at spend - price at creation).", "limit": "Coins with no cost basis realize their full value as profit, which is what a zero cost basis means. The 1.46M BTC mined before a market price existed (17 July 2010) carry a cost basis of zero rather than being dropped, so they flatter every profit measure built on this. Supply with no cost basis charts how much that is. In euro this is the global market's cost basis expressed in euro, not what European holders paid; before 2013 the euro price is the dollar price converted at the ECB rate.", "keywords": [ "realized profit", "profit taking", "are holders selling", "cashing out" ], "seriesEur": "realized_profit_eur", "shape": "osc", "kind": "flow" }, { "slug": "realized-loss", "series": "realized_loss", "label": "Realized loss", "subtitle": "money actually crystallised as losses", "categories": [ "profit-and-loss-in-money" ], "canonical": "profit-and-loss-in-money", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "How much money holders actually lost by spending coins for less than they paid. Large sustained readings are what capitulation looks like in euro.", "technical": "The mirror of realized profit: per block, summed over spent outputs where the spend price is below the creation price.", "limit": "The 1.46M BTC mined before a market price existed (17 July 2010) carry a cost basis of zero rather than being dropped, so they flatter every profit measure built on this. Supply with no cost basis charts how much that is. In euro this is the global market's cost basis expressed in euro, not what European holders paid; before 2013 the euro price is the dollar price converted at the ECB rate.", "keywords": [ "realized loss", "capitulation", "selling at a loss", "panic selling" ], "seriesEur": "realized_loss_eur", "shape": "osc", "kind": "flow" }, { "slug": "net-realized-profit-loss", "series": "realized_pl_net", "label": "Net realized profit/loss", "subtitle": "profit minus loss, in money", "categories": [ "profit-and-loss-in-money" ], "canonical": "profit-and-loss-in-money", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "Profit taken minus losses taken. Above zero the market is net cashing out; below zero it is net crystallising losses.", "technical": "Realized profit - realized loss.", "limit": "The 1.46M BTC mined before a market price existed (17 July 2010) carry a cost basis of zero rather than being dropped, so they flatter every profit measure built on this. Supply with no cost basis charts how much that is.", "keywords": [ "net realized profit", "profit taking", "capitulation", "money out of bitcoin" ], "shape": "osc", "kind": "flow" }, { "slug": "unrealized-profit", "series": "unrealized_profit", "label": "Unrealized profit", "subtitle": "paper gains not yet sold", "categories": [ "profit-and-loss-in-money" ], "canonical": "profit-and-loss-in-money", "unit": "EUR", "provisional": true, "quality": "reconstruction", "plain": "How much money holders are up on paper but have not sold. It is the fuel that a sell-off burns.", "technical": "Price x supply in profit, minus the cost basis sitting below the live price.", "limit": "Provisional. The split between the profit and loss sides is approximate: it comes from 1,024 logarithmic price bins, each 2.04% wide. The loss side is taken as the exact remainder, so unrealized profit minus unrealized loss still equals market cap minus realized cap exactly. It is the split, not the total, that is binned.", "keywords": [ "unrealized profit", "paper gains", "am i in profit", "how much profit is sitting there" ], "shape": "osc", "kind": "stock" }, { "slug": "unrealized-loss", "series": "unrealized_loss", "label": "Unrealized loss", "subtitle": "paper losses not yet crystallised", "categories": [ "profit-and-loss-in-money" ], "canonical": "profit-and-loss-in-money", "unit": "EUR", "provisional": true, "quality": "reconstruction", "plain": "How much money holders are down on paper but have not sold. It swells in bear markets and is what has to be absorbed before a recovery.", "technical": "The remainder of market cap minus realized cap after unrealized profit, so that unrealized profit minus unrealized loss equals market cap minus realized cap exactly.", "limit": "Provisional, for the same reason as unrealized profit: the split between the two sides comes from 1,024 logarithmic price bins 2.04% wide, and this side is taken as the exact remainder.", "keywords": [ "unrealized loss", "underwater", "paper losses", "bear market" ], "shape": "osc", "kind": "stock" }, { "slug": "supply-in-profit", "series": "supply_in_profit", "label": "Supply in profit", "subtitle": "bitcoin worth more than it cost", "categories": [ "coins-in-profit" ], "canonical": "coins-in-profit", "unit": "BTC", "provisional": false, "quality": "price-dependent", "plain": "How many bitcoin are currently worth more than they last cost someone.", "technical": "Live BTC whose cost basis is below the live price, from a 1,024-bin cost-basis histogram folded block by block. The threshold bin is split linearly in log price rather than counted wholly in or out, and supply in profit plus supply in loss equals circulating supply exactly.", "limit": "Pre-market coins carry a zero cost basis and are therefore always counted in profit. The euro answer is not the dollar answer relabelled: a coin can be in profit in one currency and not the other.", "keywords": [ "supply in profit", "am i in profit", "coins in profit", "how many coins are up" ], "seriesEur": "supply_in_profit_eur", "shape": "osc", "kind": "stock" }, { "slug": "supply-in-loss", "series": "supply_in_loss", "label": "Supply in loss", "subtitle": "bitcoin worth less than it cost", "categories": [ "coins-in-profit" ], "canonical": "coins-in-profit", "unit": "BTC", "provisional": false, "quality": "price-dependent", "plain": "How many bitcoin are currently worth less than they last cost someone.", "technical": "Circulating supply minus supply in profit, so the two sum to supply exactly.", "limit": "Pre-market coins carry a zero cost basis and can therefore never appear here.", "keywords": [ "supply in loss", "underwater", "coins at a loss", "bear market" ], "seriesEur": "supply_in_loss_eur", "validFrom": 272033, "shape": "osc", "kind": "stock" }, { "slug": "utxos-in-profit", "series": "utxos_in_profit", "label": "Outputs in profit", "subtitle": "unspent outputs worth more than they cost", "categories": [ "coins-in-profit" ], "canonical": "coins-in-profit", "unit": "count", "provisional": false, "quality": "price-dependent", "plain": "How many individual unspent chunks of bitcoin are worth more than they cost. Counting outputs rather than coins gives small holders the same weight as large ones.", "technical": "Counted on the UTXO-set basis, that is excluding provably unspendable data-carrier outputs, matching Core's gettxoutsetinfo. At the tip, runestone burns outnumber real UTXOs about three to one, so including them would make this number meaningless.", "limit": "Outputs are not people or wallets.", "keywords": [ "utxos in profit", "outputs in profit", "how many holders are up" ], "shape": "osc", "kind": "stock" }, { "slug": "utxos-in-loss", "series": "utxos_in_loss", "label": "Outputs in loss", "subtitle": "unspent outputs worth less than they cost", "categories": [ "coins-in-profit" ], "canonical": "coins-in-profit", "unit": "count", "provisional": false, "quality": "price-dependent", "plain": "How many individual unspent chunks of bitcoin are worth less than they cost.", "technical": "UTXO set size minus UTXOs in profit, on the same UTXO-set basis.", "limit": "Outputs are not people or wallets.", "keywords": [ "utxos in loss", "outputs underwater", "bear market" ], "validFrom": 90076, "shape": "osc", "kind": "stock" }, { "slug": "price-vs-ath", "series": "price_drawdown", "label": "Price vs all-time high", "subtitle": "how close the price is to its record", "categories": [ "cycle-timing", "cycle-position" ], "canonical": "cycle-timing", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "A high value means the price is at or near its record high; a low value means it is deep below it. It is stored as price divided by the record so that high keeps meaning the same thing here as on every other chart.", "technical": "Price / the running maximum price, so 1.0 is exactly at the all-time high.", "limit": "There is no chain data in this at all, only price. It marks every top on time by definition, which means it confirms a high after the fact and is never evidence for one.", "keywords": [ "drawdown", "all time high", "ath", "how far from the top", "bear market depth" ], "seriesEur": "price_drawdown_eur", "validFrom": 154338, "shape": "osc", "kind": "stock" }, { "slug": "mayer-multiple", "series": "mayer", "label": "Mayer multiple", "subtitle": "price against its 200-day average", "categories": [ "cycle-timing", "cycle-position" ], "canonical": "cycle-timing", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "A high value means the price is stretched far above its own average of the last two hundred days; a low value means it has fallen well below it. It is the simplest thing on the cycle dashboard and it has marked every top and bottom in the window.", "technical": "Price / the 200-day mean price, over priced blocks only. Admitted to the cycle ribbon 2026-08-05; its highest correlation with any other row is 0.88, against SOPR.", "limit": "There is no chain data in this, only price against its own past, so it agrees with a top after the fact and never explains one. A 200-day mean also has no theory behind it; it is a convention that happens to have worked.", "keywords": [ "mayer multiple", "moving average", "overbought", "tops", "is bitcoin expensive" ], "validFrom": 129714, "shape": "osc", "kind": "stock" }, { "slug": "pi-cycle-ratio", "series": "pi_cycle_ratio", "label": "Pi Cycle ratio", "subtitle": "distance to the Pi Cycle top signal", "categories": [ "cycle-timing" ], "canonical": "cycle-timing", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "The Pi Cycle top signal fires when the 111-day average price crosses above twice the 350-day average. Charting the ratio instead of the crossing means you can see how close the signal is, not just whether it has fired.", "technical": "111-day mean price / (2 x 350-day mean price). Crossing above 1 is the Pi Cycle top signal.", "limit": "Three fires in fifteen years is three data points. It is pure price with no chain data in it, and the 111 / 350 / x2 constants were chosen after the fact to fit the tops they now claim to predict.", "keywords": [ "pi cycle", "top signal", "tops", "when is the top", "cycle top" ], "shape": "osc", "kind": "stock" }, { "slug": "rhodl-ratio", "series": "rhodl", "label": "RHODL ratio", "subtitle": "young money against year-old money", "categories": [ "cycle-timing" ], "canonical": "cycle-timing", "unit": "ratio", "provisional": true, "quality": "reconstruction", "plain": "Compares how much was paid for coins bought in the last week against coins bought one to two years ago. When new money massively outweighs old money, the market has historically been near a top.", "technical": "(realized cap of coins under 1 week / realized cap of coins 1-2 years) x market age in days.", "limit": "Provisional. The market-age scalar is Glassnode's stated adjustment for growing supply, but they never published its exact form, so ours is a reconstruction and the level is not comparable to theirs. Unlike every other series here this one is computed daily, not per block, and held flat within the day: the live cost basis by coin age needs a matrix of creation height against observation height, which is 961k x 961k per block and only 6,674 x 6,674 per day. It never looks forward.", "keywords": [ "rhodl", "tops", "new money", "cycle top", "hodl waves" ], "validFrom": 138167, "shape": "osc", "kind": "stock" }, { "slug": "reserve-risk", "series": "reserve_risk", "label": "Reserve risk", "subtitle": "price against the conviction of long-term holders", "categories": [ "cycle-timing", "are-old-coins-moving" ], "canonical": "cycle-timing", "unit": "ratio", "provisional": true, "quality": "reconstruction", "plain": "Compares the price to how strongly long-term holders are refusing to sell. Low means holders are sitting tight while the price is cheap, which has been the best risk-reward; high means they are letting go into strength.", "technical": "Price / HODL bank, with the HODL bank reconstructed as the cumulative supply-adjusted value of coin-days destroyed.", "limit": "Provisional and reconstructed: the original never published a closed form and no two public implementations agree. The shape is right (low at bottoms, high at tops); the level is not comparable to anyone else's chart. It also tracks cointime MVRV at a correlation of 0.999, so the two are one signal.", "keywords": [ "reserve risk", "bottoms", "accumulation", "conviction", "when to buy" ], "sameAs": [ { "slug": "cointime-mvrv", "relation": "near-duplicate", "note": "r = 0.9986 over all history, 0.995 since 2023." } ], "validFrom": 70041, "shape": "osc", "kind": "stock" }, { "slug": "puell-multiple", "series": "puell", "label": "Puell multiple", "subtitle": "miner income against its own yearly average", "categories": [ "cycle-timing", "mining", "cycle-position" ], "canonical": "cycle-timing", "unit": "ratio", "provisional": false, "quality": "price-dependent", "plain": "A high value means miners are earning far more than they normally do, which happens when the price has run ahead of itself; a low value means mining revenue is unusually poor, which has marked bottoms.", "technical": "Value of new issuance now / the mean value of issuance over the trailing year, block subsidy only, over priced blocks.", "limit": "The subsidy halves overnight every four years while the trailing-year average still contains the old, larger subsidy, so the multiple drops mechanically for a year after each halving whatever the price does.", "keywords": [ "puell multiple", "miner revenue", "tops", "bottoms", "halving" ], "validFrom": 130599, "shape": "osc", "kind": "stock" }, { "slug": "blocks-since-halving", "series": "blocks_since_halving", "label": "Blocks since the halving", "subtitle": "where we are in the four-year issuance clock", "categories": [ "cycle-timing", "supply-and-issuance" ], "canonical": "cycle-timing", "unit": "count", "provisional": false, "quality": "exact", "plain": "How far through the current four-year issuance era the network is. It is pure calendar, but the four-year rhythm is the frame most people hang the cycle on.", "technical": "Pure chain geometry: blocks elapsed since the most recent halving. Carried as a series so the cycle dashboard reads its timing from the same place as everything else.", "limit": "It is a clock, not a signal. It was rejected from the cycle ribbon because it only ever counts upward and so carries no information about whether the market is hot or cold.", "keywords": [ "halving", "four year cycle", "where are we in the cycle", "blocks since halving" ], "shape": "clock", "kind": "stock" }, { "slug": "coin-days-destroyed", "series": "cdd", "label": "Coin-days destroyed", "subtitle": "how much dormant time was spent", "categories": [ "are-old-coins-moving", "cointime-accounting", "cycle-position" ], "canonical": "are-old-coins-moving", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "A high value means a lot of long-held coins moved at once. That happens near tops, but it also happens when frightened holders finally give up, so this alone never tells you which.", "technical": "Coin-days destroyed as a per-block flow: for each coin spent, its size times the days it sat still. The cumulative total is monotone and was rejected outright. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144.", "limit": "The weakest row on the cycle dashboard, and our own admission audit fails it: it averages the 68th percentile rather than the 50th, sits pinned near an extreme 24% of the time, and drifts with time at a correlation of -0.44. It missed three of the four cycle bottoms because a capitulation and a top look the same to it. The ARK paper writes this quantity in COINBLOCKS rather than coin-days; the two agree at a correlation of 0.999 and only the coin-days form is published here.", "keywords": [ "coin days destroyed", "cdd", "coinblocks", "are old coins moving", "old coins", "distribution" ], "shape": "osc", "kind": "flow" }, { "slug": "coin-days-destroyed-per-coin", "series": "cdd_supply_adjusted", "label": "Coin-days destroyed per coin", "subtitle": "dormant time spent, scaled to the size of the supply", "categories": [ "are-old-coins-moving", "cointime-accounting" ], "canonical": "are-old-coins-moving", "unit": "days", "provisional": false, "quality": "exact", "plain": "The same measure as coin-days destroyed, divided by how many bitcoin exist, so that a spike in 2013 and a spike today can be compared without the growth of the supply getting in the way.", "technical": "Coin-days destroyed / circulating supply. Exact.", "limit": "The coinblocks form of this, which the ARK paper calls concurrent liveliness, is the same series (r = 0.999) and is not published separately.", "keywords": [ "cdd adjusted", "coin days destroyed", "old coins", "normalised cdd" ], "shape": "osc", "kind": "flow" }, { "slug": "dormancy", "series": "dormancy", "label": "Dormancy", "subtitle": "the average age of the coins being spent", "categories": [ "are-old-coins-moving", "cycle-position" ], "canonical": "are-old-coins-moving", "unit": "days", "provisional": false, "quality": "exact", "plain": "A high value means the coins being moved are old ones, so people who held for years are handing them to someone else; a low value means only recently bought coins are changing hands.", "technical": "Value-weighted mean age, in days, of the coins spent in a block. An intensity, not a running total, and empty in blocks where nothing was spent. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144.", "limit": "One very old coin moving can dominate a whole block, and old coins also move in panics, so this reads hot at capitulations as well as at tops.", "keywords": [ "dormancy", "are old coins moving", "average coin age", "distribution", "old coins" ], "shape": "osc", "kind": "flow" }, { "slug": "dormancy-flow", "series": "dormancy_flow", "label": "Dormancy flow", "subtitle": "market value against the value of dormant time spent", "categories": [ "are-old-coins-moving", "cycle-position" ], "canonical": "are-old-coins-moving", "unit": "ratio", "provisional": true, "quality": "reconstruction", "plain": "A high value means the price has run far ahead of the past year of holder behaviour: a lot of market value against not much old coin actually moving. Its lows are where the last cycle bottoms were.", "technical": "Market cap / (365 x the trailing-year mean of price x coin-days destroyed). Admitted to the cycle ribbon 2026-08-05; its highest correlation with any other row is 0.79.", "limit": "Provisional: our normalisation is reconstructed and the units do not reduce to a pure ratio, so only the shape is charted, never the level. Nobody publishes an exact form for this, so it cannot be checked against anyone else's chart.", "keywords": [ "dormancy flow", "bottoms", "bear market end", "old coins" ], "shape": "osc", "kind": "stock" }, { "slug": "liveliness", "series": "liveliness", "label": "Liveliness", "subtitle": "the share of bitcoin's holding time that has been spent", "categories": [ "are-old-coins-moving", "cointime" ], "canonical": "cointime", "unit": "ratio", "provisional": false, "quality": "exact", "plain": "Of all the time bitcoin has ever spent sitting in wallets, what fraction has been given up by coins moving. Rising means long-dormant coins are being spent, which is a distribution regime; falling means accumulation is outpacing spending.", "technical": "Cumulative coin-days destroyed / cumulative coin-days created. The ARK and Glassnode papers define the framework in coinblocks, but every public series (Open Bitcoin Metrics, checkonchain, ChainExposed) uses coin-days, and this one matches Open Bitcoin Metrics to a median of 0.00013. Coin-days is the only basis published here.", "limit": "Cointime measures are cumulative since genesis, so they move very slowly and stay anchored to early history. They describe a regime, not a trade. Liveliness moved from roughly 0.47 to roughly 0.60 over a decade, so it is a macro-regime instrument and anyone presenting it as a trading signal is misusing it. It was rejected from the cycle ribbon for exactly that reason.", "keywords": [ "liveliness", "coinblocks", "are old coins moving", "hoarding", "distribution", "cointime" ], "sameAs": [ { "slug": "vaultedness", "relation": "algebraic-identity", "note": "Vaultedness = 1 - liveliness, exact." } ], "shape": "osc", "kind": "stock" }, { "slug": "slrv", "series": "slrv", "label": "SLRV", "subtitle": "young coins moving against year-old coins moving", "categories": [ "are-old-coins-moving" ], "canonical": "are-old-coins-moving", "unit": "ratio", "provisional": true, "quality": "reconstruction", "plain": "Compares how much recently bought bitcoin is moving against how much year-old bitcoin is moving. It is used as a fast regime flag: young coins dominating is a hot market.", "technical": "30-day sums of spent volume in the 1-day-to-1-week age band over the 6-month-to-1-year band. Realized value would give the same answer, because the spend price cancels in the ratio.", "limit": "Provisional. Published definitions of SLRV disagree about which age bands to use; these are the two most commonly cited, but another provider's SLRV is a different number.", "keywords": [ "slrv", "short to long ribbon", "young coins", "regime" ], "validFrom": 67905, "shape": "osc", "kind": "stock" }, { "slug": "long-term-holder-spent-volume", "series": "spent_volume_lth", "label": "Long-term holder spent volume", "subtitle": "bitcoin moved after sitting more than five months", "categories": [ "are-old-coins-moving", "holder-cohorts" ], "canonical": "holder-cohorts", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "How many bitcoin that had been sitting still for more than 155 days moved in this block. Sustained high readings mean patient holders are handing coins to someone else.", "technical": "Spent output volume restricted to coins aged 155 days or more. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144.", "limit": "155 days is a convention borrowed from the industry, not a boundary that exists in the data. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "lth spent volume", "are old coins moving", "distribution", "long term holders selling" ], "shape": "osc", "kind": "flow" }, { "slug": "long-term-holder-supply", "series": "lth_supply", "label": "Long-term holder supply", "subtitle": "bitcoin untouched for over five months", "categories": [ "holder-cohorts" ], "canonical": "holder-cohorts", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "How many bitcoin have not moved in more than 155 days. It grows through bear markets as coins go quiet, and drains during rallies as patient holders sell into strength.", "technical": "Circulating supply held in outputs aged 155 days or more. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. Identical, bit for bit, to \"supply last active over 155 days\".", "limit": "155 days is a convention borrowed from the industry, not a boundary in the data. It is also a running total of the age bands rather than an independent measurement, but it is kept because it is the name every onchain reader already knows this quantity by. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "long term holder supply", "lth", "hodlers", "are holders selling", "accumulation", "supply last active 155 days" ], "aliasSeries": [ "supply_ge_155d" ], "shape": "osc", "kind": "stock" }, { "slug": "short-term-holder-supply", "series": "sth_supply", "label": "Short-term holder supply", "subtitle": "bitcoin that has moved recently", "categories": [ "holder-cohorts" ], "canonical": "holder-cohorts", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "How many bitcoin have moved in the last 155 days. This is the part of the supply most likely to move again, and it swells during rallies.", "technical": "Circulating supply minus long-term holder supply, so the two sum to supply exactly.", "limit": "155 days is a convention borrowed from the industry, not a boundary in the data. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "short term holder supply", "sth", "new buyers", "recent coins" ], "validFrom": 4906, "shape": "osc", "kind": "stock" }, { "slug": "long-term-holder-share", "series": "lth_share", "label": "Long-term holder share of supply", "subtitle": "the share of all bitcoin held over five months", "categories": [ "holder-cohorts" ], "canonical": "holder-cohorts", "unit": "share", "provisional": false, "quality": "exact", "plain": "What fraction of all bitcoin has been sitting still for more than 155 days. It peaks near the bottom of bear markets and troughs near tops.", "technical": "Long-term holder supply / circulating supply.", "limit": "155 days is a convention borrowed from the industry, not a boundary in the data. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "lth share", "hodler share", "are holders selling", "accumulation", "bottoms" ], "shape": "osc", "kind": "stock" }, { "slug": "realized-cap-155d", "series": "realized_cap_ge_155d", "label": "Long-term holder cost basis", "subtitle": "what coins held over five months cost their owners", "categories": [ "holder-cohorts" ], "canonical": "holder-cohorts", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "The total amount paid for the bitcoin that has been sitting still for more than 155 days. When the price falls below the average implied here, patient holders are collectively under water.", "technical": "Realized cap restricted to coins aged 155 days or more.", "limit": "Unlike every other series here this one is computed daily, not per block, and held flat within the day: the live cost basis by coin age needs a matrix of creation height against observation height, which is 961k x 961k per block and only 6,674 x 6,674 per day. It never looks forward. The 1.46M BTC mined before a market price existed (17 July 2010) carry a cost basis of zero rather than being dropped, so they flatter every profit measure built on this. Supply with no cost basis charts how much that is.", "keywords": [ "lth cost basis", "long term holder cost basis", "what hodlers paid", "realized cap" ], "seriesEur": "realized_cap_eur_ge_155d", "shape": "osc", "kind": "stock" }, { "slug": "realized-cap-1y", "series": "realized_cap_ge_1y", "label": "Cost basis of coins older than a year", "subtitle": "what year-old coins cost their owners", "categories": [ "holder-cohorts" ], "canonical": "holder-cohorts", "unit": "EUR", "provisional": false, "quality": "price-dependent", "plain": "The total amount paid for the bitcoin that has not moved in over a year. It is the deepest, slowest-moving layer of the market's cost basis.", "technical": "Realized cap restricted to coins aged one year or more.", "limit": "Unlike every other series here this one is computed daily, not per block, and held flat within the day: the live cost basis by coin age needs a matrix of creation height against observation height, which is 961k x 961k per block and only 6,674 x 6,674 per day. It never looks forward. The 1.46M BTC mined before a market price existed (17 July 2010) carry a cost basis of zero rather than being dropped, so they flatter every profit measure built on this. Supply with no cost basis charts how much that is.", "keywords": [ "one year cost basis", "old coins cost basis", "realized cap", "hodlers" ], "shape": "osc", "kind": "stock" }, { "slug": "lth-realized-cap-share", "series": "lth_realized_cap_share", "label": "Long-term holders' share of cost basis", "subtitle": "how much of the money in bitcoin belongs to patient holders", "categories": [ "holder-cohorts" ], "canonical": "holder-cohorts", "unit": "share", "provisional": false, "quality": "price-dependent", "plain": "What share of all the money ever paid for bitcoin sits with holders who have not moved their coins in over five months. High means the market is owned by people who are not trading it.", "technical": "Long-term holder realized cap / total realized cap.", "limit": "Unlike every other series here this one is computed daily, not per block, and held flat within the day: the live cost basis by coin age needs a matrix of creation height against observation height, which is 961k x 961k per block and only 6,674 x 6,674 per day. It never looks forward.", "keywords": [ "lth realized cap share", "who owns bitcoin", "hodlers", "cost basis" ], "shape": "osc", "kind": "stock" }, { "slug": "vaultedness", "series": "vaultedness", "label": "Vaultedness", "subtitle": "the share of holding time still stored in unmoved coins", "categories": [ "cointime" ], "canonical": "cointime", "unit": "ratio", "provisional": false, "quality": "exact", "plain": "The mirror of liveliness: of all the time bitcoin has spent sitting in wallets, what fraction is still stored in coins that have not moved. It is the potential energy of the network.", "technical": "1 - liveliness, on the coin-days basis. Equivalently, cumulative coin-days stored / cumulative coin-days created.", "limit": "It is exactly one minus liveliness, so it is the same measurement shown the other way up. Do not count both. Cointime measures are cumulative since genesis, so they move very slowly and stay anchored to early history. They describe a regime, not a trade.", "keywords": [ "vaultedness", "hoarding", "cold storage", "cointime", "stored coins" ], "sameAs": [ { "slug": "liveliness", "relation": "algebraic-identity", "note": "Vaultedness = 1 - liveliness, exact to machine precision." } ], "shape": "osc", "kind": "stock" }, { "slug": "activity-to-vaulting-ratio", "series": "a2vr", "label": "Activity-to-vaulting ratio", "subtitle": "spent holding time against stored", "categories": [ "cointime" ], "canonical": "cointime", "unit": "ratio", "provisional": false, "quality": "exact", "plain": "How much of bitcoin's holding time has been spent for every unit still stored. It says the same thing as liveliness, stretched onto an unbounded scale so that changes near the top of the range are easier to see.", "technical": "Liveliness / (1 - liveliness).", "limit": "It is a monotone transform of liveliness, not an independent measurement (r = 0.999 since 2020), so it tells you nothing liveliness does not. It is worth charting only because liveliness is squashed near the top of its range and this is not.", "keywords": [ "a2vr", "activity to vaulting", "liveliness", "cointime" ], "sameAs": [ { "slug": "liveliness", "relation": "monotone-transform", "note": "A2VR = liveliness / (1 - liveliness), exact on the coin-days basis." } ], "shape": "osc", "kind": "stock" }, { "slug": "active-supply", "series": "active_supply", "label": "Active supply", "subtitle": "the bitcoin that is economically awake", "categories": [ "cointime" ], "canonical": "cointime", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The equivalent number of bitcoin that are economically active, rather than sitting still. It is not a list of particular coins, it is a volume, which is exactly how it sidesteps having to decide which coins are lost.", "technical": "Circulating supply x liveliness. Active supply plus vaulted supply equals circulating supply exactly.", "limit": "It is an equivalent volume, not a set of coins. No individual coin is \"in\" it. Cointime measures are cumulative since genesis, so they move very slowly and stay anchored to early history. They describe a regime, not a trade.", "keywords": [ "active supply", "free float", "circulating float", "cointime", "lost coins" ], "shape": "osc", "kind": "stock" }, { "slug": "vaulted-supply", "series": "vaulted_supply", "label": "Vaulted supply", "subtitle": "the bitcoin that is not participating", "categories": [ "cointime" ], "canonical": "cointime", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The equivalent number of bitcoin that are not participating: cold storage, long-term holders and coins lost forever, all bundled into one figure. It is an upper bound on how many coins are lost.", "technical": "Circulating supply x (1 - liveliness). Active supply plus vaulted supply equals circulating supply exactly.", "limit": "It bundles deliberate hoarding with permanent loss and cannot tell them apart. The paper puts it at 7.674M BTC in May 2023 against age-band \"lost coin\" estimates of 3.9M to 5.5M, which is the size of the ambiguity. ", "keywords": [ "vaulted supply", "lost coins", "cold storage", "hoarding", "how many bitcoin are lost" ], "sameAs": [ { "slug": "active-supply", "relation": "algebraic-identity", "note": "Vaulted supply = circulating supply - active supply, exact." } ], "validFrom": 4815, "shape": "osc", "kind": "stock" }, { "slug": "vaulting-rate", "series": "vaulting_rate", "label": "Vaulting rate", "subtitle": "how fast coins are being locked away", "categories": [ "cointime" ], "canonical": "cointime", "unit": "ratio", "provisional": true, "quality": "reconstruction", "plain": "How quickly bitcoin is moving into the not-participating pile, as an annual rate. It is charted against the inflation rate: when more is being vaulted than is being mined, the tradeable float is shrinking.", "technical": "Annualised change in vaulted supply over total supply, annualised over 52,560 blocks.", "limit": "Provisional because the source papers never state the annualisation. They describe \"the daily rate of change\" but chart it against an annual inflation rate, so we annualise; that is inference, not a quoted definition. ", "keywords": [ "vaulting rate", "hoarding rate", "coins locked away", "supply squeeze" ], "shape": "osc", "kind": "stock" }, { "slug": "cointime-adjusted-inflation", "series": "cointime_adj_inflation", "label": "Cointime-adjusted inflation", "subtitle": "how much new supply really dilutes the tradeable float", "categories": [ "cointime" ], "canonical": "cointime", "unit": "ratio", "provisional": true, "quality": "reconstruction", "plain": "Ordinary inflation asks what share of all bitcoin is new. This asks what share of the bitcoin that actually trades is new, which is the number that matters if most coins never move.", "technical": "Annualised issuance divided by the ACTIVE float: nominal inflation x (supply / active supply). This is our bounded variant and the default line; ARK's published formula is charted beside it as a separate series.", "limit": "Provisional. It inherits the trailing-year issuance window, which no source specifies. Rob chose this variant over ARK's because it stays on the same scale as nominal inflation, which is what \"dilutes the tradeable supply\" means in words. ", "keywords": [ "cointime inflation", "real inflation", "dilution", "supply growth", "float" ], "shape": "osc", "kind": "stock" }, { "slug": "cointime-adjusted-s2f", "series": "cointime_adj_s2f", "label": "Cointime-adjusted stock-to-flow", "subtitle": "stock-to-flow measured against the tradeable float", "categories": [ "cointime" ], "canonical": "cointime", "unit": "ratio", "provisional": true, "quality": "reconstruction", "plain": "Stock-to-flow rebuilt so the \"stock\" is only the bitcoin that actually circulates, rather than every coin including the ones nobody can move.", "technical": "1 / cointime-adjusted inflation, so it follows the bare name to our bounded variant.", "limit": "Provisional, and it inherits the trailing-year issuance window from cointime-adjusted inflation. It also tracks ordinary stock-to-flow at a correlation of 0.9996, so the cointime adjustment changes the shape far less than the name suggests. ", "keywords": [ "cointime stock to flow", "s2f", "scarcity", "dilution" ], "sameAs": [ { "slug": "cointime-adjusted-inflation", "relation": "algebraic-identity", "note": "Exactly its reciprocal, verified." }, { "slug": "stock-to-flow", "relation": "near-duplicate", "note": "r = 0.9996 over all history." } ], "shape": "osc", "kind": "stock" }, { "slug": "cointime-adjusted-inflation-ark", "series": "cointime_adj_inflation_ark", "label": "Cointime-adjusted inflation (ARK version)", "subtitle": "the published formula, kept for comparison", "categories": [ "cointime" ], "canonical": "cointime", "unit": "ratio", "provisional": true, "quality": "reconstruction", "plain": "The version of cointime-adjusted inflation exactly as the ARK paper published it. It is shown beside ours because the two behave differently as more coins are locked away, and we would rather you see that than take our word for the choice.", "technical": "ARK's verbatim formula: nominal inflation x (active supply / vaulted supply).", "limit": "Provisional. It divides two quantities that sum to one, so it runs away as the vault empties rather than staying on the same scale as nominal inflation. That is why it is not the default line. ", "keywords": [ "ark cointime inflation", "cointime inflation", "comparison", "dilution" ], "shape": "osc", "kind": "stock" }, { "slug": "cointime-adjusted-s2f-ark", "series": "cointime_adj_s2f_ark", "label": "Cointime-adjusted stock-to-flow (ARK version)", "subtitle": "the reciprocal of the published inflation formula", "categories": [ "cointime" ], "canonical": "cointime", "unit": "ratio", "provisional": true, "quality": "reconstruction", "plain": "Stock-to-flow built from the ARK paper's published cointime inflation formula, shown beside ours for comparison.", "technical": "1 / cointime-adjusted inflation (ARK published).", "limit": "Provisional, and it inherits the runaway behaviour of the ARK inflation formula as vaulted supply shrinks. ", "keywords": [ "ark s2f", "cointime stock to flow", "comparison" ], "sameAs": [ { "slug": "cointime-adjusted-inflation-ark", "relation": "algebraic-identity", "note": "Exactly its reciprocal, verified." } ], "shape": "osc", "kind": "stock" }, { "slug": "cointime-nvt", "series": "cointime_nvt", "label": "Cointime NVT", "subtitle": "market value against the value of holding time spent", "categories": [ "cointime-prices" ], "canonical": "cointime-prices", "unit": "ratio", "provisional": true, "quality": "reconstruction", "plain": "A price-to-earnings style ratio for bitcoin, where the \"earnings\" are the value of the dormant holding time being cashed in. High means the market is expensive against how much economic work the chain is doing.", "technical": "Active cap / the 90-day mean of (price x coin-days destroyed).", "limit": "Provisional. The source paper's definition was truncated mid-sentence in METRIC-IDEAS s1.7, so the 90-day window is our choice, not theirs.", "keywords": [ "cointime nvt", "nvt", "is bitcoin expensive", "valuation", "network value" ], "validFrom": 140718, "shape": "osc", "kind": "stock" }, { "slug": "coin-days-created", "series": "cdc", "label": "Coin-days created", "subtitle": "holding time earned by the whole supply", "categories": [ "cointime-accounting" ], "canonical": "cointime-accounting", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "Every bitcoin in existence earns holding time simply by existing. This is how much was earned in this block: the clock ticking for the whole network.", "technical": "Circulating supply at the previous block x the elapsed wall-clock time. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The ARK and Glassnode papers write this in COINBLOCKS, one block of holding rather than one day; that is the same ledger in a different time unit and is not published separately.", "limit": null, "keywords": [ "coin days created", "coinblocks", "cointime", "holding time" ], "shape": "osc", "kind": "flow" }, { "slug": "cumulative-coin-days-created", "series": "cum_cdc", "label": "Cumulative coin-days created", "subtitle": "all holding time ever earned", "categories": [ "cointime-accounting" ], "canonical": "cointime-accounting", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "All the holding time bitcoin has ever accumulated, added up since genesis. It is the denominator of liveliness.", "technical": "Running sum of coin-days created.", "limit": "It only ever goes up, so it carries no cycle information on its own.", "keywords": [ "cumulative coin days", "coinblocks", "cointime", "liveliness denominator" ], "shape": "trend", "kind": "stock" }, { "slug": "cumulative-coin-days-destroyed", "series": "cum_cdd", "label": "Cumulative coin-days destroyed", "subtitle": "all holding time ever given up", "categories": [ "cointime-accounting" ], "canonical": "cointime-accounting", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "All the holding time that has ever been given up by coins moving, added up since genesis. It is the numerator of liveliness.", "technical": "Running sum of coin-days destroyed.", "limit": "It only ever goes up, so it carries no cycle information on its own. It was rejected from the cycle ribbon for that reason.", "keywords": [ "cumulative cdd", "coin days destroyed", "coinblocks", "cointime", "liveliness" ], "shape": "trend", "kind": "stock" }, { "slug": "circulating-supply", "series": "supply", "label": "Circulating supply", "subtitle": "how many bitcoin exist", "categories": [ "supply-and-issuance" ], "canonical": "supply-and-issuance", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "How many bitcoin have ever been mined and therefore exist. It rises in steps that halve roughly every four years and will stop just under 21 million.", "technical": "The sum of REALISED issuance, that is the coinbase output minus fees actually claimed, not the halving schedule. At least 1,030 blocks claimed less than they were allowed, so summing the schedule gives the wrong answer.", "limit": "It counts coins that are provably lost, and it counts coins burned to data outputs, which have left the UTXO set. Keeping burns in is a deliberate choice: it makes supply = created - spent an exact identity that every cointime measure leans on. The 51.16 BTC involved are charted separately.", "keywords": [ "supply", "how many bitcoin exist", "circulating supply", "21 million", "coins mined" ], "validFrom": 3851, "shape": "trend", "kind": "stock" }, { "slug": "supply-ex-burn", "series": "supply_ex_burn", "label": "Circulating supply excluding provable burns", "subtitle": "supply with unspendable coins removed", "categories": [ "supply-and-issuance" ], "canonical": "supply-and-issuance", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Circulating supply with the bitcoin that has been provably destroyed taken out. The difference is tiny, about 51 coins, but it is the only part of \"lost bitcoin\" anyone can actually prove.", "technical": "Circulating supply minus the value sent to data-carrier outputs, which leave the UTXO set.", "limit": "It does not include coins lost to forgotten keys, which are unobservable. The gap to plain circulating supply is about 2.6 parts per million, so on a chart the two lines are one line.", "keywords": [ "burned bitcoin", "supply ex burn", "destroyed coins", "op_return" ], "sameAs": [ { "slug": "circulating-supply", "relation": "near-duplicate", "note": "Differs by 51.16 BTC, a relative gap of 2.6e-6. Indistinguishable on any chart." } ], "validFrom": 3851, "shape": "trend", "kind": "stock" }, { "slug": "burned-supply", "series": "burned_supply", "label": "Provably burned supply", "subtitle": "bitcoin sent somewhere it can never leave", "categories": [ "supply-and-issuance", "data-on-the-chain" ], "canonical": "data-on-the-chain", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "How much bitcoin has been sent to outputs that can never be spent, so it is destroyed with certainty rather than merely lost.", "technical": "Cumulative value carried in OP_RETURN outputs.", "limit": "This is only the provable part. Coins lost to forgotten or destroyed keys are far more numerous and are unobservable.", "keywords": [ "burned bitcoin", "destroyed coins", "op_return", "how many bitcoin are lost" ], "shape": "trend", "kind": "stock" }, { "slug": "issuance", "series": "issuance", "label": "Issuance", "subtitle": "new bitcoin minted in this block", "categories": [ "supply-and-issuance", "mining" ], "canonical": "supply-and-issuance", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "How many brand new bitcoin were created in this block. It halves every 210,000 blocks and is the only way coins ever come into existence.", "technical": "The realised block subsidy actually claimed by the miner, which is not always the full subsidy the rules allowed.", "limit": "At least 1,030 blocks claimed less than allowed, including one that claimed nothing at all, so this sits slightly below the halving schedule. That gap is the point of charting both.", "keywords": [ "issuance", "new bitcoin", "block reward", "subsidy", "coins mined" ], "sameAs": [ { "slug": "subsidy-schedule", "relation": "near-duplicate", "note": "The schedule is what was allowed; issuance is what was taken. They differ on about 1,030 blocks out of 961,000." } ], "shape": "trend", "kind": "flow" }, { "slug": "subsidy-schedule", "series": "subsidy_schedule", "label": "Subsidy per the halving schedule", "subtitle": "what the rules allowed the miner to claim", "categories": [ "supply-and-issuance", "data-quality" ], "canonical": "data-quality", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "What the protocol allowed the miner to take in this block, as opposed to what they actually took. The two are almost always the same, and the exceptions are the interesting part.", "technical": "The theoretical block subsidy from the halving schedule.", "limit": "This is a reference line, not a measurement. Real supply must be summed from what was claimed, not from this.", "keywords": [ "block subsidy", "halving schedule", "block reward", "lost subsidy" ], "diagnostic": true, "shape": "trend", "kind": "flow" }, { "slug": "inflation-rate", "series": "inflation_rate", "label": "Inflation rate", "subtitle": "how fast the supply is growing", "categories": [ "supply-and-issuance" ], "canonical": "supply-and-issuance", "unit": "ratio", "provisional": false, "quality": "exact", "plain": "How much the supply of bitcoin grew over the last year, as a percentage. It halves at every halving and is now below the rate central banks target for consumer prices.", "technical": "Trailing 52,560 blocks of realised issuance over circulating supply. NULL for the first year, because there is no trailing year yet.", "limit": "Because it looks back a full year, it glides down over the twelve months after each halving instead of stepping down on the day.", "keywords": [ "inflation", "supply growth", "how fast are new bitcoin made", "dilution", "monetary policy" ], "sameAs": [ { "slug": "stock-to-flow", "relation": "algebraic-identity", "note": "Stock-to-flow is exactly its reciprocal." } ], "shape": "trend", "kind": "stock" }, { "slug": "inflation-rate-instantaneous", "series": "inflation_rate_inst", "label": "Inflation rate (instantaneous)", "subtitle": "this block's issuance, annualised", "categories": [ "supply-and-issuance" ], "canonical": "supply-and-issuance", "unit": "ratio", "provisional": false, "quality": "exact", "plain": "The same idea as the inflation rate, but based only on what is being minted right now. It steps straight down at each halving instead of gliding.", "technical": "This block's issuance annualised by 52,560 blocks.", "limit": "It is noisy block to block, and it tracks the trailing-year version at r = 0.995 over all history, so the difference is mostly the twelve months after each halving.", "keywords": [ "instant inflation", "supply growth", "halving step", "dilution" ], "sameAs": [ { "slug": "inflation-rate", "relation": "near-duplicate", "note": "r = 0.995 over all history; they diverge after halvings." } ], "validFrom": 7759, "shape": "trend", "kind": "stock" }, { "slug": "stock-to-flow", "series": "stock_to_flow", "label": "Stock-to-flow", "subtitle": "years of current issuance to reproduce the supply", "categories": [ "supply-and-issuance" ], "canonical": "supply-and-issuance", "unit": "ratio", "provisional": false, "quality": "exact", "plain": "How many years of mining at the current rate it would take to produce all the bitcoin that already exists. It doubles at every halving and is the number behind the scarcity argument.", "technical": "Circulating supply / annual issuance. Exactly the reciprocal of the inflation rate.", "limit": "It is arithmetic about issuance and says nothing about demand. The famous stock-to-flow price model built on it has been falsified since 2021, which is why we chart the ratio and not the model.", "keywords": [ "stock to flow", "s2f", "scarcity", "halving", "is bitcoin scarce" ], "sameAs": [ { "slug": "inflation-rate", "relation": "algebraic-identity", "note": "Exactly 1 / inflation rate, verified to 2e-16." } ], "shape": "trend", "kind": "stock" }, { "slug": "marginal-clearing-price", "series": "clearing_price", "label": "Marginal clearing price", "subtitle": "what the cheapest, middle and dearest blockspace in a block cost", "categories": [ "what-blockspace-cost" ], "canonical": "what-blockspace-cost", "unit": "sat/vB", "provisional": false, "quality": "exact", "plain": "Blockspace is an auction with one round every ten minutes. The headline line is the cheapest thing the miner actually took, which is what the last seat in the block sold for. The band around it shows the cheapest, middle and dearest space in the same block, so you see the whole auction rather than an average.", "technical": "PER BLOCK, sat/vB. `value` is the MINIMUM fee rate of an included non-coinbase transaction, corrected to this definition on 2026-08-05; it used to hold the weight-weighted median. `lo`/`mid`/`hi` are the weight-weighted p5/p50/p95, the fee rates at which the block's cumulative vbyte count crosses 5%, 50% and 95%, on the per-byte convention Core, mempool.space and every block explorer use. Coinbase excluded, as Core does.", "limit": null, "keywords": [ "fees", "what does a transaction cost", "sat/vb", "blockspace price", "fee auction" ], "sameAs": [ { "slug": "median-feerate", "relation": "algebraic-identity", "note": "The mid band of this series IS the median feerate, bit for bit." }, { "slug": "minimum-feerate", "relation": "algebraic-identity", "note": "The value line of this series IS the minimum feerate, bit for bit, since the 2026-08-05 correction." } ], "validFrom": 114710, "shape": "osc", "kind": "flow" }, { "slug": "median-feerate", "series": "feerate_median", "label": "Median feerate", "subtitle": "the middle price of blockspace in a block", "categories": [ "what-blockspace-cost" ], "canonical": "what-blockspace-cost", "unit": "sat/vB", "provisional": false, "quality": "exact", "plain": "The price of the middle byte of blockspace in the block. Roughly, what you had to pay to be sure of getting in.", "technical": "PER WEIGHT UNIT: the feerate at which the block's cumulative vbyte count crosses 50%, not the median transaction's feerate. This is what Core's getblockstats, mempool.space and the block explorers all mean, and our replica of Core's algorithm matches getblockstats exactly. Identical, bit for bit, to the mid band of the marginal clearing price.", "limit": "It is identical to the mid band of the marginal clearing price. Do not count them twice.", "keywords": [ "median fee", "what does a transaction cost", "sat/vb", "fees" ], "sameAs": [ { "slug": "marginal-clearing-price", "relation": "algebraic-identity", "note": "Identical to the mid band, bit for bit." } ], "validFrom": 114710, "shape": "osc", "kind": "flow" }, { "slug": "mean-feerate", "series": "feerate_mean", "label": "Mean feerate", "subtitle": "total fee divided by total size", "categories": [ "what-blockspace-cost" ], "canonical": "what-blockspace-cost", "unit": "sat/vB", "provisional": false, "quality": "exact", "plain": "The average price paid per byte across the whole block. It runs above the median whenever a few people paid a lot to jump the queue.", "technical": "PER WEIGHT UNIT: total non-coinbase fee divided by total non-coinbase vsize.", "limit": "One very urgent transaction can pull the average well above what almost everyone actually paid.", "keywords": [ "average fee", "mean feerate", "what does a transaction cost", "fees" ], "validFrom": 118329, "shape": "osc", "kind": "flow" }, { "slug": "minimum-feerate", "series": "feerate_min", "label": "Minimum feerate in block", "subtitle": "the cheapest thing that got in", "categories": [ "what-blockspace-cost" ], "canonical": "what-blockspace-cost", "unit": "sat/vB", "provisional": false, "quality": "exact", "plain": "The lowest price anything in the block paid. When blocks are not full this sits at the network's relay minimum; when they are full it rises, and that rise is the real congestion signal.", "technical": "Minimum fee divided by vsize over the non-coinbase transactions in the block. Identical, bit for bit, to the `value` line of the marginal clearing price since the 2026-08-05 correction.", "limit": "A single miner including their own low-fee transaction sets this floor for the whole block.", "keywords": [ "minimum fee", "cheapest fee", "clearing price", "congestion", "fees", "is the mempool full" ], "sameAs": [ { "slug": "marginal-clearing-price", "relation": "algebraic-identity", "note": "Identical to that series' value line, bit for bit, since the 2026-08-05 correction." } ], "shape": "osc", "kind": "flow" }, { "slug": "maximum-feerate", "series": "feerate_max", "label": "Maximum feerate in block", "subtitle": "the dearest thing that got in", "categories": [ "what-blockspace-cost" ], "canonical": "what-blockspace-cost", "unit": "sat/vB", "provisional": false, "quality": "exact", "plain": "The highest price anything in the block paid. It is dominated by people in a hurry and by mistakes.", "technical": "The highest non-coinbase feerate included in the block, per weight unit.", "limit": "It is an outlier by construction: one fat-fingered fee sets it for the whole block.", "keywords": [ "maximum fee", "highest fee", "fee mistake", "fees" ], "shape": "osc", "kind": "flow" }, { "slug": "miner-revenue", "series": "miner_revenue", "label": "Miner revenue", "subtitle": "everything the miner earned in this block", "categories": [ "mining" ], "canonical": "mining", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Everything the miner took home from this block: the newly minted coins plus every fee paid by the transactions inside it.", "technical": "The total coinbase output: subsidy claimed plus fees.", "limit": null, "keywords": [ "miner revenue", "block reward", "what do miners earn", "mining income" ], "shape": "osc", "kind": "flow" }, { "slug": "block-fees", "series": "block_fees", "label": "Fees paid in block", "subtitle": "what users paid to get into this block", "categories": [ "mining", "what-blockspace-cost" ], "canonical": "mining", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The total amount users paid in fees for this block. As the block subsidy halves toward nothing, this is what has to pay for the network's security.", "technical": "Sum of transaction fees in the block.", "limit": null, "keywords": [ "fees", "block fees", "what does a transaction cost", "security budget" ], "shape": "osc", "kind": "flow" }, { "slug": "cumulative-fees", "series": "cum_fees", "label": "Cumulative fees ever paid", "subtitle": "every fee ever paid, added up", "categories": [ "mining" ], "canonical": "mining", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Every transaction fee ever paid on the bitcoin network, added up.", "technical": "Running sum of block fees.", "limit": "It only ever goes up, so it carries no cycle information.", "keywords": [ "total fees", "cumulative fees", "fees ever paid" ], "shape": "trend", "kind": "stock" }, { "slug": "fee-share-of-revenue", "series": "fee_share_of_revenue", "label": "Fee share of miner revenue", "subtitle": "how much of mining income comes from users rather than issuance", "categories": [ "mining" ], "canonical": "mining", "unit": "share", "provisional": false, "quality": "exact", "plain": "What fraction of a miner's income comes from users paying fees rather than from newly minted coins. This is the single number that decides whether bitcoin can pay for its own security once issuance runs out.", "technical": "Block fees / total miner revenue.", "limit": "It is extremely spiky per block. It jumps at every halving purely because the other half of the ratio just halved, with no change in user behaviour.", "keywords": [ "fee share", "security budget", "will fees pay for security", "miner revenue", "halving" ], "shape": "osc", "kind": "flow" }, { "slug": "difficulty", "series": "difficulty", "label": "Difficulty", "subtitle": "how hard it is to find a block", "categories": [ "mining" ], "canonical": "mining", "unit": "raw", "provisional": false, "quality": "exact", "plain": "How hard the network is currently making it to mine a block. It adjusts every two weeks so that blocks keep arriving about every ten minutes no matter how much mining power shows up.", "technical": "The block's difficulty target as reported by the chain.", "limit": "It is a two-week lagging step function, so it tells you about hash power in the recent past, not right now.", "keywords": [ "difficulty", "mining difficulty", "hashrate", "how hard is mining" ], "shape": "trend", "kind": "stock" }, { "slug": "block-size", "series": "block_size", "label": "Block size", "subtitle": "how many bytes the block took up", "categories": [ "how-full-are-blocks" ], "canonical": "how-full-are-blocks", "unit": "bytes", "provisional": false, "quality": "exact", "plain": "How big the block is in bytes on disk. Since SegWit this can exceed the old one-megabyte limit, because witness data is counted at a discount.", "technical": "Serialised block size in bytes.", "limit": "Size is not the binding limit; weight is. A block can be small in bytes and completely full.", "keywords": [ "block size", "megabyte", "how big are blocks", "chain growth" ], "shape": "osc", "kind": "flow" }, { "slug": "block-weight", "series": "block_weight", "label": "Block weight", "subtitle": "the measure blocks are actually limited by", "categories": [ "how-full-are-blocks" ], "canonical": "how-full-are-blocks", "unit": "weight", "provisional": false, "quality": "exact", "plain": "The number blocks are actually limited by. The cap is 4,000,000, and witness data counts a quarter as much as everything else, which is the SegWit discount.", "technical": "Block weight in weight units, capped at 4,000,000 by consensus.", "limit": null, "keywords": [ "block weight", "weight units", "block limit", "segwit discount" ], "shape": "osc", "kind": "flow" }, { "slug": "block-fill", "series": "block_utilisation", "label": "Block fill", "subtitle": "how much of the block limit was used", "categories": [ "how-full-are-blocks" ], "canonical": "how-full-are-blocks", "unit": "share", "provisional": false, "quality": "exact", "plain": "How full the block is, as a percentage of the maximum. Blocks have been essentially full continuously since early 2023.", "technical": "Block weight / 4,000,000.", "limit": "It has been pinned near 100% since early 2023, so it is now a history chart rather than a live signal. It is a linear rescaling of block weight, not an independent measurement.", "keywords": [ "block fill", "how full are blocks", "congestion", "block space" ], "sameAs": [ { "slug": "block-weight", "relation": "algebraic-identity", "note": "Exactly block weight / 4,000,000." } ], "shape": "osc", "kind": "flow" }, { "slug": "witness-bytes", "series": "witness_bytes", "label": "Witness bytes", "subtitle": "bytes spent on signatures and scripts", "categories": [ "how-full-are-blocks" ], "canonical": "how-full-are-blocks", "unit": "bytes", "provisional": false, "quality": "exact", "plain": "How many bytes in the block are signature and script data rather than transaction structure. Inscriptions live here, which is why this exploded in 2023.", "technical": "Total witness bytes in the block. NULL before SegWit activated at height 481,824.", "limit": null, "keywords": [ "witness", "segwit", "signature data", "inscriptions", "block space" ], "shape": "osc", "kind": "flow" }, { "slug": "witness-share-of-weight", "series": "witness_share", "label": "Witness share of block weight", "subtitle": "how much of the weight budget went on witnesses", "categories": [ "how-full-are-blocks" ], "canonical": "how-full-are-blocks", "unit": "share", "provisional": false, "quality": "exact", "plain": "What fraction of the block's capacity was spent on signature and script data. Witness bytes cost one weight unit each, so this is literally the share of the budget they took.", "technical": "Witness bytes / block weight. NULL before SegWit at height 481,824.", "limit": "It is a different number from the witness share of block SIZE, and both are published. Do not mix them up.", "keywords": [ "witness share", "segwit", "block space", "inscriptions" ], "shape": "osc", "kind": "flow" }, { "slug": "witness-share-of-size", "series": "witness_share_of_size", "label": "Witness share of block size", "subtitle": "how much of the block's bytes were witnesses", "categories": [ "how-full-are-blocks" ], "canonical": "how-full-are-blocks", "unit": "share", "provisional": false, "quality": "exact", "plain": "What fraction of the block's raw bytes are signature and script data. It is a different question from the share of the weight budget, because witness bytes are discounted.", "technical": "Witness bytes / block size in bytes. This is the ratio written out in METRIC-IDEAS s3.14; it is a different number from the witness share of weight and both are published.", "limit": "It is a linear mirror of the weight discount (r = -1.000), so those two are one measurement.", "keywords": [ "witness share", "segwit", "block size", "signature data" ], "sameAs": [ { "slug": "weight-discount", "relation": "monotone-transform", "note": "weight/(4 x size) is 1 - 0.75 x this, to within 0.25%. r = -1.0000." } ], "shape": "osc", "kind": "flow" }, { "slug": "weight-discount", "series": "weight_discount", "label": "Weight discount", "subtitle": "how much cheaper the block got from SegWit", "categories": [ "how-full-are-blocks" ], "canonical": "how-full-are-blocks", "unit": "ratio", "provisional": false, "quality": "exact", "plain": "How much cheaper the SegWit discount made this block. It is 1.0 before SegWit existed and falls as more of the block is witness data, which is discounted to a quarter price.", "technical": "Block weight / (4 x block size).", "limit": "It is a linear mirror of the witness share of block size (r = -1.000). Do not read the pair as two facts.", "keywords": [ "weight discount", "segwit discount", "block space", "cheaper fees" ], "sameAs": [ { "slug": "witness-share-of-size", "relation": "monotone-transform", "note": "r = -1.0000." } ], "shape": "osc", "kind": "flow" }, { "slug": "segwit-tx-share", "series": "segwit_tx_share", "label": "SegWit share of transactions", "subtitle": "how many transactions use SegWit", "categories": [ "how-full-are-blocks" ], "canonical": "how-full-are-blocks", "unit": "share", "provisional": false, "quality": "exact", "plain": "What fraction of transactions in the block use SegWit, the 2017 upgrade that made transactions cheaper. It is a clean measure of how fast the ecosystem actually adopts an improvement.", "technical": "Non-coinbase only. Core's getblockstats swtxs excludes the coinbase, and every post-SegWit coinbase carries a witness, so including it would read about 100% forever.", "limit": null, "keywords": [ "segwit adoption", "segwit", "upgrade adoption", "cheaper fees" ], "shape": "osc", "kind": "flow" }, { "slug": "segwit-weight-share", "series": "segwit_weight_share", "label": "SegWit share of block weight", "subtitle": "how much of the block SegWit transactions took", "categories": [ "how-full-are-blocks" ], "canonical": "how-full-are-blocks", "unit": "share", "provisional": false, "quality": "exact", "plain": "What fraction of the block's capacity was used by SegWit transactions, as opposed to what fraction of the transaction count they were.", "technical": "Weight of SegWit transactions / total block weight, non-coinbase only.", "limit": null, "keywords": [ "segwit adoption", "segwit", "block space" ], "validFrom": 484433, "shape": "osc", "kind": "flow" }, { "slug": "transactions-per-block", "series": "tx_count", "label": "Transactions in block", "subtitle": "how many transactions the block carried", "categories": [ "network-activity", "how-full-are-blocks" ], "canonical": "network-activity", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many transactions fit into this block. It depends as much on how big each transaction is as on how busy the network is.", "technical": "Transaction count in the block, coinbase included.", "limit": "It is not a usage figure. Batching puts thousands of payments in one transaction and consolidation puts one payment in a transaction with hundreds of inputs.", "keywords": [ "transactions per block", "transaction count", "how busy is bitcoin", "network usage" ], "sameAs": [ { "slug": "transactions-non-coinbase", "relation": "definition-variant", "note": "The same count with the coinbase transaction removed, which is exactly one per block." } ], "shape": "osc", "kind": "flow" }, { "slug": "inscription-weight-share", "series": "inscription_weight_share", "label": "Inscription share of block weight", "subtitle": "images and text written into witness data", "categories": [ "what-blockspace-was-used-for" ], "canonical": "what-blockspace-was-used-for", "unit": "share", "provisional": false, "quality": "exact", "plain": "How much of the block's capacity was taken up by inscriptions, the images, text and tokens written into bitcoin transactions since early 2023.", "technical": "Whole-transaction weight of any transaction carrying an inscription envelope, over total block weight. It attributes the entire transaction, not only its envelope bytes.", "limit": "Attributing the whole transaction rather than only the envelope overstates what inscriptions cost, because the payment part of the transaction would have existed anyway.", "keywords": [ "inscriptions", "ordinals", "nfts on bitcoin", "jpegs", "block space", "weight share", "block space" ], "shape": "osc", "kind": "flow" }, { "slug": "inscription-fee-share", "series": "inscription_fee_share", "label": "Inscription share of block fees", "subtitle": "what share of the block's fee income inscriptions paid", "categories": [ "what-blockspace-was-used-for" ], "canonical": "what-blockspace-was-used-for", "unit": "share", "provisional": false, "quality": "exact", "plain": "What share of the fees paid for this block came from inscriptions, the images, text and tokens written into bitcoin transactions since early 2023. Read beside the weight share: paying more of the fees than the space taken means this use outbid everyone else.", "technical": "Whole-transaction fees paid by any transaction carrying an inscription envelope, over total block fees.", "limit": "Attributing the whole transaction rather than only the envelope overstates what inscriptions cost, because the payment part of the transaction would have existed anyway.", "keywords": [ "inscriptions", "ordinals", "nfts on bitcoin", "jpegs", "block space", "fee share", "who pays the fees" ], "shape": "osc", "kind": "flow" }, { "slug": "runestone-weight-share", "series": "runestone_weight_share", "label": "Runestone share of block weight", "subtitle": "the Runes token protocol's OP_RETURN messages", "categories": [ "what-blockspace-was-used-for" ], "canonical": "what-blockspace-was-used-for", "unit": "share", "provisional": false, "quality": "exact", "plain": "How much of the block's capacity was taken up by Runes, a token protocol that writes its messages into OP_RETURN outputs.", "technical": "Whole-transaction weight of any transaction carrying a runestone, over total block weight.", "limit": null, "keywords": [ "runes", "runestones", "tokens on bitcoin", "block space", "weight share", "block space" ], "shape": "osc", "kind": "flow" }, { "slug": "runestone-fee-share", "series": "runestone_fee_share", "label": "Runestone share of block fees", "subtitle": "what share of the block's fee income runestones paid", "categories": [ "what-blockspace-was-used-for" ], "canonical": "what-blockspace-was-used-for", "unit": "share", "provisional": false, "quality": "exact", "plain": "What share of the fees paid for this block came from Runes, a token protocol that writes its messages into OP_RETURN outputs. Read beside the weight share: paying more of the fees than the space taken means this use outbid everyone else.", "technical": "Whole-transaction fees paid by any transaction carrying a runestone, over total block fees.", "limit": null, "keywords": [ "runes", "runestones", "tokens on bitcoin", "block space", "fee share", "who pays the fees" ], "shape": "osc", "kind": "flow" }, { "slug": "consolidation-weight-share", "series": "consolidation_weight_share", "label": "Consolidation share of block weight", "subtitle": "sweeping many small outputs into one", "categories": [ "what-blockspace-was-used-for" ], "canonical": "what-blockspace-was-used-for", "unit": "share", "provisional": true, "quality": "reconstruction", "plain": "How much of the block's capacity was taken up by wallets tidying up, sweeping lots of small chunks of bitcoin into one big one, usually when fees are low.", "technical": "Shape heuristic: whole-transaction weight of transactions with at least 5 inputs and at most 2 outputs, over total block weight.", "limit": "Provisional. The 5-in / 2-out threshold is arbitrary, chosen in METRIC-IDEAS s3.2 rather than derived. This is a shape heuristic over the transaction graph, not a label: it counts transactions that LOOK like this, and cannot tell you who made them or why.", "keywords": [ "consolidation", "utxo cleanup", "what is the block used for", "low fees", "weight share", "block space" ], "shape": "osc", "kind": "flow" }, { "slug": "consolidation-fee-share", "series": "consolidation_fee_share", "label": "Consolidation share of block fees", "subtitle": "what share of the block's fee income consolidations paid", "categories": [ "what-blockspace-was-used-for" ], "canonical": "what-blockspace-was-used-for", "unit": "share", "provisional": true, "quality": "reconstruction", "plain": "What share of the fees paid for this block came from wallets tidying up, sweeping lots of small chunks of bitcoin into one big one, usually when fees are low. Read beside the weight share: paying more of the fees than the space taken means this use outbid everyone else.", "technical": "Shape heuristic: whole-transaction fees of transactions with at least 5 inputs and at most 2 outputs, over total block fees.", "limit": "Provisional. The 5-in / 2-out threshold is arbitrary, chosen in METRIC-IDEAS s3.2 rather than derived. This is a shape heuristic over the transaction graph, not a label: it counts transactions that LOOK like this, and cannot tell you who made them or why.", "keywords": [ "consolidation", "utxo cleanup", "what is the block used for", "low fees", "fee share", "who pays the fees" ], "shape": "osc", "kind": "flow" }, { "slug": "batch-payout-weight-share", "series": "batch_weight_share", "label": "Batch-payout share of block weight", "subtitle": "one transaction paying many people", "categories": [ "what-blockspace-was-used-for" ], "canonical": "what-blockspace-was-used-for", "unit": "share", "provisional": true, "quality": "reconstruction", "plain": "How much of the block's capacity was taken up by transactions paying lots of people at once, which is how exchanges and mining pools send withdrawals.", "technical": "Shape heuristic: whole-transaction weight of transactions with at least 10 outputs, over total block weight.", "limit": "Provisional. Ten outputs is an arbitrary threshold. This is a shape heuristic over the transaction graph, not a label: it counts transactions that LOOK like this, and cannot tell you who made them or why.", "keywords": [ "batching", "exchange withdrawals", "payouts", "what is the block used for", "weight share", "block space" ], "shape": "osc", "kind": "flow" }, { "slug": "batch-payout-fee-share", "series": "batch_fee_share", "label": "Batch-payout share of block fees", "subtitle": "what share of the block's fee income batch payouts paid", "categories": [ "what-blockspace-was-used-for" ], "canonical": "what-blockspace-was-used-for", "unit": "share", "provisional": true, "quality": "reconstruction", "plain": "What share of the fees paid for this block came from transactions paying lots of people at once, which is how exchanges and mining pools send withdrawals. Read beside the weight share: paying more of the fees than the space taken means this use outbid everyone else.", "technical": "Shape heuristic: whole-transaction fees of transactions with at least 10 outputs, over total block fees.", "limit": "Provisional. Ten outputs is an arbitrary threshold. This is a shape heuristic over the transaction graph, not a label: it counts transactions that LOOK like this, and cannot tell you who made them or why.", "keywords": [ "batching", "exchange withdrawals", "payouts", "what is the block used for", "fee share", "who pays the fees" ], "validFrom": 372715, "shape": "osc", "kind": "flow" }, { "slug": "coinjoin-shaped-weight-share", "series": "coinjoin_shape_weight_share", "label": "CoinJoin-shaped share of block weight", "subtitle": "transactions with the fingerprint of a privacy join", "categories": [ "what-blockspace-was-used-for" ], "canonical": "what-blockspace-was-used-for", "unit": "share", "provisional": true, "quality": "reconstruction", "plain": "How much of the block's capacity was taken up by transactions that look like a CoinJoin, where several people combine one transaction to break the link between their coins.", "technical": "Shape heuristic: whole-transaction weight of transactions with at least 3 outputs of exactly equal value, over total block weight. Catches the Wasabi and Whirlpool shapes.", "limit": "Provisional, and it misses PayJoin entirely, which is deliberately shaped to look like an ordinary payment. This is a shape heuristic over the transaction graph, not a label: it counts transactions that LOOK like this, and cannot tell you who made them or why.", "keywords": [ "coinjoin", "privacy", "wasabi", "whirlpool", "what is the block used for", "weight share", "block space" ], "sameAs": [ { "slug": "coinjoin-blockspace-share", "relation": "near-duplicate", "note": "Tier D publishes the same equal-output detector measured in virtual size over non-coinbase vsize. Same transactions, a different denominator, not a second signal." } ], "shape": "osc", "kind": "flow" }, { "slug": "coinjoin-shaped-fee-share", "series": "coinjoin_shape_fee_share", "label": "CoinJoin-shaped share of block fees", "subtitle": "what share of the block's fee income CoinJoin-shaped transactions paid", "categories": [ "what-blockspace-was-used-for" ], "canonical": "what-blockspace-was-used-for", "unit": "share", "provisional": true, "quality": "reconstruction", "plain": "What share of the fees paid for this block came from transactions that look like a CoinJoin, where several people combine one transaction to break the link between their coins. Read beside the weight share: paying more of the fees than the space taken means this use outbid everyone else.", "technical": "Shape heuristic: whole-transaction fees of transactions with at least 3 outputs of exactly equal value, over total block fees.", "limit": "Provisional, and it misses PayJoin entirely, which is deliberately shaped to look like an ordinary payment. This is a shape heuristic over the transaction graph, not a label: it counts transactions that LOOK like this, and cannot tell you who made them or why.", "keywords": [ "coinjoin", "privacy", "wasabi", "whirlpool", "what is the block used for", "fee share", "who pays the fees" ], "validFrom": 372725, "shape": "osc", "kind": "flow" }, { "slug": "op-return-outputs", "series": "op_return_outputs", "label": "OP_RETURN outputs", "subtitle": "outputs that carry data instead of money", "categories": [ "data-on-the-chain" ], "canonical": "data-on-the-chain", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many outputs in this block exist to carry data rather than to hold bitcoin. They can never be spent, so they are the deliberate way to write something into the chain.", "technical": "Count of OP_RETURN outputs in the block.", "limit": "It is almost identical to the count of transactions carrying an OP_RETURN (r = 1.0000), because nearly every such transaction carries exactly one.", "keywords": [ "op_return", "data on the chain", "runes", "is bitcoin being spammed" ], "sameAs": [ { "slug": "op-return-transactions", "relation": "near-duplicate", "note": "r = 1.0000; the two are equal in the median block." } ], "shape": "osc", "kind": "flow" }, { "slug": "op-return-transactions", "series": "op_return_txs", "label": "Transactions with an OP_RETURN", "subtitle": "transactions that write data into the chain", "categories": [ "data-on-the-chain" ], "canonical": "data-on-the-chain", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many transactions in this block wrote data into the chain using an OP_RETURN output.", "technical": "Count of transactions containing at least one OP_RETURN output.", "limit": "It is almost identical to the OP_RETURN output count (r = 1.0000), because nearly every such transaction carries exactly one.", "keywords": [ "op_return", "data on the chain", "runes", "spam" ], "sameAs": [ { "slug": "op-return-outputs", "relation": "near-duplicate", "note": "r = 1.0000." } ], "shape": "osc", "kind": "flow" }, { "slug": "op-return-payload-bytes", "series": "op_return_payload_bytes", "label": "OP_RETURN payload bytes", "subtitle": "how many bytes of pure data the block carried", "categories": [ "data-on-the-chain" ], "canonical": "data-on-the-chain", "unit": "bytes", "provisional": false, "quality": "exact", "plain": "How many bytes of pure data were written into this block through OP_RETURN outputs.", "technical": "The concatenated data pushes of every OP_RETURN output in the block. Stored as raw payload bytes rather than a decoded protocol name, because a decode can always be redone and a byte never stored cannot.", "limit": null, "keywords": [ "op_return", "data bytes", "chain bloat", "is bitcoin being spammed" ], "shape": "osc", "kind": "flow" }, { "slug": "inscription-count", "series": "inscription_count", "label": "Inscriptions", "subtitle": "how many inscriptions were revealed", "categories": [ "data-on-the-chain" ], "canonical": "data-on-the-chain", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many inscriptions, the images and text written into witness data, were revealed in this block.", "technical": "Count of inscription envelopes revealed in the block.", "limit": null, "keywords": [ "inscriptions", "ordinals", "nfts on bitcoin", "jpegs" ], "shape": "osc", "kind": "flow" }, { "slug": "inscription-transactions", "series": "inscription_txs", "label": "Inscription reveal transactions", "subtitle": "transactions that revealed an inscription", "categories": [ "data-on-the-chain" ], "canonical": "data-on-the-chain", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many transactions in this block existed to reveal an inscription.", "technical": "Count of transactions carrying at least one inscription envelope.", "limit": null, "keywords": [ "inscriptions", "ordinals", "reveal transaction" ], "shape": "osc", "kind": "flow" }, { "slug": "inscription-body-bytes", "series": "inscription_body_bytes", "label": "Inscription body bytes", "subtitle": "how many bytes of inscription content the block carried", "categories": [ "data-on-the-chain" ], "canonical": "data-on-the-chain", "unit": "bytes", "provisional": false, "quality": "exact", "plain": "How many bytes of actual inscription content, the image or text itself, were written into this block.", "technical": "Total bytes in inscription envelope bodies in the block.", "limit": null, "keywords": [ "inscriptions", "ordinals", "chain bloat", "jpegs", "data bytes" ], "shape": "osc", "kind": "flow" }, { "slug": "runestone-transactions", "series": "runestone_txs", "label": "Runestone transactions", "subtitle": "transactions carrying a Runes message", "categories": [ "data-on-the-chain" ], "canonical": "data-on-the-chain", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many transactions in this block carried a runestone, the message format used by the Runes token protocol.", "technical": "Count of transactions carrying a runestone.", "limit": null, "keywords": [ "runes", "runestones", "tokens on bitcoin" ], "shape": "osc", "kind": "flow" }, { "slug": "burned-outputs", "series": "burned_outputs", "label": "Cumulative data-carrier outputs", "subtitle": "unspendable outputs that will sit in the chain forever", "categories": [ "data-on-the-chain" ], "canonical": "data-on-the-chain", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many outputs have been created that can never be spent. They leave the spendable set immediately but stay in the chain forever, and at the tip they outnumber real unspent outputs about three to one.", "technical": "Running count of provably unspendable data-carrier outputs.", "limit": null, "keywords": [ "burned outputs", "op_return", "chain bloat", "utxo set", "spam" ], "shape": "trend", "kind": "stock" }, { "slug": "spent-outputs", "series": "spent_outputs", "label": "Outputs spent", "subtitle": "chunks of bitcoin consumed in this block", "categories": [ "network-activity" ], "canonical": "network-activity", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many existing chunks of bitcoin were consumed as inputs in this block.", "technical": "Count of outputs spent in the block.", "limit": null, "keywords": [ "spent outputs", "inputs", "network usage", "utxo" ], "shape": "osc", "kind": "flow" }, { "slug": "created-outputs", "series": "created_outputs", "label": "Outputs created", "subtitle": "new chunks of bitcoin made in this block", "categories": [ "network-activity" ], "canonical": "network-activity", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many new chunks of bitcoin were created as outputs in this block.", "technical": "Count of outputs created in the block.", "limit": null, "keywords": [ "created outputs", "new utxos", "network usage" ], "sameAs": [ { "slug": "outputs-non-coinbase", "relation": "definition-variant", "note": "Tier D publishes the same count with the coinbase and the zero-value data outputs removed." } ], "shape": "osc", "kind": "flow" }, { "slug": "utxo-count", "series": "utxo_count", "label": "UTXO set size", "subtitle": "how many spendable chunks of bitcoin exist", "categories": [ "network-activity" ], "canonical": "network-activity", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many separate spendable chunks of bitcoin exist right now. Every node has to keep track of all of them, so this is the number that decides how heavy running bitcoin is.", "technical": "Created minus spent minus provably unspendable. Data-carrier outputs never leave the set, and runestone OP_RETURNs alone account for a few hundred million of them, so counting them would overstate the set by more than 2x at the tip. Core's gettxoutsetinfo and Open Bitcoin Metrics both exclude them, and so does this.", "limit": "Outputs are not users. A rise can mean adoption or it can mean one exchange fragmenting its balances.", "keywords": [ "utxo set", "how many utxos", "node requirements", "chain state" ], "validFrom": 833, "shape": "osc", "kind": "stock" }, { "slug": "unspent-outputs-incl-unspendable", "series": "output_count_all", "label": "All unspent outputs including unspendable", "subtitle": "the output count without the data-carrier exclusion", "categories": [ "data-quality", "network-activity" ], "canonical": "data-quality", "unit": "count", "provisional": false, "quality": "exact", "plain": "The same count as the UTXO set size, but without throwing out the outputs that can never be spent. The gap between the two lines is a direct measure of how much of the output set is data rather than money.", "technical": "The same running sum as the UTXO set size WITHOUT the provably-unspendable exclusion.", "limit": "On its own this overstates the real UTXO set by more than 2x at the tip. It is published to be read as a pair with the UTXO set size, not alone.", "keywords": [ "output count", "utxo set", "chain bloat", "spam", "data outputs" ], "diagnostic": true, "validFrom": 705, "shape": "osc", "kind": "stock" }, { "slug": "utxo-set-change", "series": "utxo_delta", "label": "UTXO set change", "subtitle": "whether the set grew or shrank this block", "categories": [ "network-activity" ], "canonical": "network-activity", "unit": "count", "provisional": false, "quality": "exact", "plain": "Whether this block added more spendable chunks of bitcoin than it consumed. Negative blocks are wallets tidying up, which usually happens when fees are cheap.", "technical": "Outputs created minus outputs spent, exact.", "limit": null, "keywords": [ "utxo growth", "utxo set change", "consolidation", "chain state" ], "shape": "osc", "kind": "flow" }, { "slug": "spent-volume", "series": "spent_volume", "label": "Spent output volume", "subtitle": "how much bitcoin moved", "categories": [ "network-activity" ], "canonical": "network-activity", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "How many bitcoin changed hands in this block. It is the rawest measure of activity, and it is much larger than the amount actually paid to anyone.", "technical": "Total value of outputs spent in the block. Unadjusted: change coming back to the sender is included.", "limit": "Change inflates it, often severely. Someone spending 0.01 BTC out of a 10 BTC output shows up here as 10 BTC moving. It is also numerically almost identical to the raw output value series (typical gap 2e-5), because in aggregate what is spent equals what is created.", "keywords": [ "transfer volume", "how much bitcoin moved", "onchain volume", "network usage" ], "sameAs": [ { "slug": "non-coinbase-output-value", "relation": "near-duplicate", "note": "r = 1.0000, median relative gap 2e-5. In aggregate spent value equals created value." } ], "validFrom": 199590, "shape": "osc", "kind": "flow" }, { "slug": "non-coinbase-output-value", "series": "output_value_nc", "label": "Non-coinbase output value", "subtitle": "value created by ordinary transactions", "categories": [ "network-activity" ], "canonical": "network-activity", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The total value of the outputs ordinary transactions created in this block, leaving out the miner's own reward.", "technical": "Matches Core's getblockstats total_out on all 961,001 heights, and is the quantity Open Bitcoin Metrics calls raw output value.", "limit": "Change is included, so it is not a payments figure. It is numerically almost identical to spent volume (median gap 2e-5).", "keywords": [ "output value", "transfer volume", "onchain volume", "total out" ], "sameAs": [ { "slug": "spent-volume", "relation": "near-duplicate", "note": "r = 1.0000, median relative gap 2e-5." }, { "slug": "raw-output-value", "relation": "near-duplicate", "note": "The coinbase-inclusive version of the same quantity; median relative gap 3e-3." } ], "validFrom": 199590, "shape": "osc", "kind": "flow" }, { "slug": "raw-output-value", "series": "created_value", "label": "Raw output value", "subtitle": "value created including the coinbase", "categories": [ "network-activity" ], "canonical": "network-activity", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The total value of every output created in this block, including the miner's own reward.", "technical": "Total value of outputs created in the block. Not transfer volume: change is in it, and so is the coinbase.", "limit": "Change and the coinbase are both included, so it is not a payments figure. It differs from the non-coinbase version by a median of 0.3%.", "keywords": [ "output value", "created value", "onchain volume" ], "sameAs": [ { "slug": "non-coinbase-output-value", "relation": "near-duplicate", "note": "median relative gap 3e-3." } ], "validFrom": 199590, "shape": "osc", "kind": "flow" }, { "slug": "price-quality", "series": "price_quality", "label": "USD price quality at this block", "subtitle": "how good the price behind this block is", "categories": [ "data-quality" ], "canonical": "data-quality", "unit": "raw", "provisional": false, "quality": "price-dependent", "plain": "Every euro figure on this site rests on knowing what bitcoin cost at a given moment. This says how good that knowledge is at each block: a full hour of real exchange data, a partial window, a price carried forward from earlier, or no market at all.", "technical": "3 = a full 60-minute carry window, 2 = partial, 1 = carried forward or a single exchange partition, 0 = no market. Taken from the PREFIX of resolution_flag, never by equality: the flag carries an optional EUR verdict after a semicolon, and equality-testing it silently misfiles 17,924 blocks.", "limit": "This is a diagnostic, not a market measure. It tells you how much to trust the chart beside it.", "keywords": [ "price quality", "data quality", "can i trust this", "price source" ], "diagnostic": true, "shape": "trend", "kind": "stock" }, { "slug": "eur-basis", "series": "eur_basis", "label": "Which EUR series this block used", "subtitle": "real euro book, or dollars converted", "categories": [ "data-quality" ], "canonical": "data-quality", "unit": "raw", "provisional": false, "quality": "price-dependent", "plain": "Whether the euro price for this block came from a real euro order book or was the dollar price converted at the ECB rate. Mostly 2011 to 2013 needed the conversion.", "technical": "1 = eur_native (a real BTC-EUR book), 2 = eur_synthetic (USD x ECB FX), 0 = no price. Native is primary and goes NULL past 24 hours of staleness, which is 17,924 blocks. Every EUR metric in this tier used this rule and no other.", "limit": "This is a diagnostic. It does not tell you a euro number is wrong, only which route it took.", "keywords": [ "eur price", "euro basis", "data quality", "exchange rate", "can i trust this" ], "diagnostic": true, "shape": "trend", "kind": "stock" }, { "slug": "realized-cap-degraded-share", "series": "rc_degraded_share", "label": "Realized cap priced off a degraded quote", "subtitle": "how much of the cost basis rests on a weak price", "categories": [ "data-quality" ], "canonical": "data-quality", "unit": "share", "provisional": false, "quality": "price-dependent", "plain": "How much of the total cost basis was priced using a weak or carried-forward price rather than a full hour of real market data. It is what lets you see that a 2011 number and a 2025 number are not the same kind of number.", "technical": "Share of the live realized cap whose cost basis came from a block whose USD price was NOT a full 60-minute carry, that is carry-forward, single-partition, partial or absent. Read by PREFIX of resolution_flag.", "limit": "This is a diagnostic on the input data, not a market measure.", "keywords": [ "data quality", "realized cap", "can i trust this", "price quality" ], "diagnostic": true, "shape": "osc", "kind": "stock" }, { "slug": "supply-no-costbasis", "series": "supply_no_costbasis", "label": "Supply with no cost basis", "subtitle": "coins mined before a price existed", "categories": [ "data-quality" ], "canonical": "data-quality", "unit": "BTC", "provisional": false, "quality": "price-dependent", "plain": "How many bitcoin were mined before anyone had ever traded one for money, so no one can say what they cost. Every profit measure on this site treats them as having cost nothing, which flatters those measures, and this is the size of that assumption.", "technical": "Live supply created below height 68,774, before any market price existed. This is the size of the zero-cost-basis assumption every realized-cap measure here rests on. Published beside them rather than buried.", "limit": "Nothing can be done about this: no price existed, so any other choice would be an invention. Coin Metrics and Glassnode make the same assumption.", "keywords": [ "no cost basis", "satoshi coins", "data quality", "pre market coins", "1.46 million" ], "diagnostic": true, "validFrom": 6047, "shape": "osc", "kind": "stock" }, { "slug": "supply-no-costbasis-share", "series": "supply_no_costbasis_share", "label": "Supply with no cost basis (share)", "subtitle": "what fraction of supply has no known cost", "categories": [ "data-quality" ], "canonical": "data-quality", "unit": "share", "provisional": false, "quality": "price-dependent", "plain": "The same figure as a share of all bitcoin: about 7% of supply at the tip has no knowable cost, and that share shrinks as the supply grows.", "technical": "Supply with no cost basis / circulating supply.", "limit": "This is a diagnostic, not a market measure.", "keywords": [ "no cost basis", "data quality", "satoshi coins", "share" ], "diagnostic": true, "shape": "trend", "kind": "stock" }, { "slug": "live-output-value", "series": "supply_utxo", "label": "Live output value", "subtitle": "supply recomputed from the UTXO set", "categories": [ "data-quality" ], "canonical": "data-quality", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Circulating supply worked out a second way, by adding up every unspent output instead of every block reward. The two lines must be identical, and watching them stay identical is how we know the chain has been parsed correctly.", "technical": "Created value minus spent value. Must equal circulating supply at every height; see VALIDATION.md.", "limit": "It is a validation oracle, not a market measure. It agrees with circulating supply to 1e-14, which is floating-point noise, so charting both is a check and never news.", "keywords": [ "validation", "data quality", "utxo supply", "supply check" ], "sameAs": [ { "slug": "circulating-supply", "relation": "algebraic-identity", "note": "Must be identical by construction; agrees to a maximum relative gap of 2.8e-13." } ], "diagnostic": true, "validFrom": 3851, "shape": "trend", "kind": "stock" }, { "slug": "supply-aged-under-1d", "series": "hodl_lt1d", "label": "Supply aged under 1 day", "subtitle": "bitcoin that has sat still less than a day", "categories": [ "supply-by-age" ], "canonical": "supply-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The smallest band and the most volatile: coins that changed hands today. It swells on days the price moves hard and on days exchanges rebalance, and it empties again within a week.", "technical": "Circulating supply held in unspent outputs whose age falls less than a day. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to circulating supply exactly, verified to machine precision.", "limit": "Almost all of this is exchange churn and change rather than people buying and selling, so read it as a proxy for how busy today was, not for how many coins found new owners. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "hodl waves", "coin age", "how long have coins been held", "supply by age", "under 1 day" ], "validFrom": 21486, "shape": "osc", "kind": "stock" }, { "slug": "supply-aged-1d-1w", "series": "hodl_1d_1w", "label": "Supply aged 1 day to 1 week", "subtitle": "bitcoin that has sat still between a day and a week", "categories": [ "supply-by-age" ], "canonical": "supply-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "This week's buyers. A band that stays fat for several weeks running means new money keeps arriving rather than the same coins circulating.", "technical": "Circulating supply held in unspent outputs whose age falls between a day and a week. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to circulating supply exactly, verified to machine precision.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "hodl waves", "coin age", "how long have coins been held", "supply by age", "1 day to 1 week" ], "validFrom": 231495, "shape": "osc", "kind": "stock" }, { "slug": "supply-aged-1w-1m", "series": "hodl_1w_1m", "label": "Supply aged 1 week to 1 month", "subtitle": "bitcoin that has sat still between a week and a month", "categories": [ "supply-by-age" ], "canonical": "supply-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The first band where coins have visibly settled: they were bought, and then nothing happened for a few weeks. It fills fastest in the early part of a rally.", "technical": "Circulating supply held in unspent outputs whose age falls between a week and a month. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to circulating supply exactly, verified to machine precision.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "hodl waves", "coin age", "how long have coins been held", "supply by age", "1 week to 1 month" ], "shape": "osc", "kind": "stock" }, { "slug": "supply-aged-1m-3m", "series": "hodl_1m_3m", "label": "Supply aged 1 to 3 months", "subtitle": "bitcoin that has sat still between one and three months", "categories": [ "supply-by-age" ], "canonical": "supply-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The band that tests whether a move stuck. Coins bought in a spike arrive here about a month later, and whether they stay or drain says whether that spike found real holders.", "technical": "Circulating supply held in unspent outputs whose age falls between one and three months. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to circulating supply exactly, verified to machine precision.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "hodl waves", "coin age", "how long have coins been held", "supply by age", "1 to 3 months" ], "shape": "osc", "kind": "stock" }, { "slug": "supply-aged-3m-6m", "series": "hodl_3m_6m", "label": "Supply aged 3 to 6 months", "subtitle": "bitcoin that has sat still between three and six months", "categories": [ "supply-by-age" ], "canonical": "supply-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The waiting room for long-term holder status: at 155 days coins here cross into the long-term holder cohort. A fat band means a large wave of coins is about to be reclassified.", "technical": "Circulating supply held in unspent outputs whose age falls between three and six months. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to circulating supply exactly, verified to machine precision.", "limit": "The 155-day line falls inside this band, so part of it is already counted as long-term holder supply and part is not. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "hodl waves", "coin age", "how long have coins been held", "supply by age", "3 to 6 months" ], "shape": "osc", "kind": "stock" }, { "slug": "supply-aged-6m-1y", "series": "hodl_6m_1y", "label": "Supply aged 6 to 12 months", "subtitle": "bitcoin that has sat still between six months and a year", "categories": [ "supply-by-age" ], "canonical": "supply-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Coins that survived at least two quarters without being sold. This band swells about six months after every major accumulation phase and drains into the next rally.", "technical": "Circulating supply held in unspent outputs whose age falls between six months and a year. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to circulating supply exactly, verified to machine precision.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "hodl waves", "coin age", "how long have coins been held", "supply by age", "6 to 12 months" ], "shape": "osc", "kind": "stock" }, { "slug": "supply-aged-1y-2y", "series": "hodl_1y_2y", "label": "Supply aged 1 to 2 years", "subtitle": "bitcoin that has sat still between one and two years", "categories": [ "supply-by-age" ], "canonical": "supply-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Last cycle's buyers. This is the band that empties hardest near cycle tops, because coins bought roughly a year before a high are the ones sitting on the largest gains.", "technical": "Circulating supply held in unspent outputs whose age falls between one and two years. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to circulating supply exactly, verified to machine precision.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "hodl waves", "coin age", "how long have coins been held", "supply by age", "1 to 2 years" ], "shape": "osc", "kind": "stock" }, { "slug": "supply-aged-2y-3y", "series": "hodl_2y_3y", "label": "Supply aged 2 to 3 years", "subtitle": "bitcoin that has sat still between two and three years", "categories": [ "supply-by-age" ], "canonical": "supply-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Bought a full four-year cycle ago and held through an entire bear market. Historically the most profitable cohort at a top, and therefore the one with the strongest reason to sell.", "technical": "Circulating supply held in unspent outputs whose age falls between two and three years. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to circulating supply exactly, verified to machine precision.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "hodl waves", "coin age", "how long have coins been held", "supply by age", "2 to 3 years" ], "shape": "osc", "kind": "stock" }, { "slug": "supply-aged-3y-5y", "series": "hodl_3y_5y", "label": "Supply aged 3 to 5 years", "subtitle": "bitcoin that has sat still between three and five years", "categories": [ "supply-by-age" ], "canonical": "supply-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "This band spans a halving, so everything in it was mined or bought under a different issuance regime. It moves rarely and each time it does it is worth asking why.", "technical": "Circulating supply held in unspent outputs whose age falls between three and five years. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to circulating supply exactly, verified to machine precision.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "hodl waves", "coin age", "how long have coins been held", "supply by age", "3 to 5 years" ], "shape": "osc", "kind": "stock" }, { "slug": "supply-aged-5y-7y", "series": "hodl_5y_7y", "label": "Supply aged 5 to 7 years", "subtitle": "bitcoin that has sat still between five and seven years", "categories": [ "supply-by-age" ], "canonical": "supply-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Coins held across two halvings. Movement here is unusual enough to be individually newsworthy and is often an old exchange or an early holder rather than a trader.", "technical": "Circulating supply held in unspent outputs whose age falls between five and seven years. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to circulating supply exactly, verified to machine precision.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "hodl waves", "coin age", "how long have coins been held", "supply by age", "5 to 7 years" ], "shape": "osc", "kind": "stock" }, { "slug": "supply-aged-7y-10y", "series": "hodl_7y_10y", "label": "Supply aged 7 to 10 years", "subtitle": "bitcoin that has sat still between seven and ten years", "categories": [ "supply-by-age" ], "canonical": "supply-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Bitcoin bought before most people had heard of it. This band grows almost monotonically, which is itself the finding: these coins essentially do not come back.", "technical": "Circulating supply held in unspent outputs whose age falls between seven and ten years. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to circulating supply exactly, verified to machine precision.", "limit": "A rising band here is mostly coins ageing in from below, not new conviction. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "hodl waves", "coin age", "how long have coins been held", "supply by age", "7 to 10 years" ], "shape": "osc", "kind": "stock" }, { "slug": "supply-aged-over-10y", "series": "hodl_10y_plus", "label": "Supply aged over 10 years", "subtitle": "bitcoin that has sat still more than ten years", "categories": [ "supply-by-age" ], "canonical": "supply-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Satoshi-era and early-adopter coins. Much of it is probably lost keys rather than patient holding, which is why it is the best available floor under any \"how many bitcoin are lost\" estimate. When it falls at all, it makes the news.", "technical": "Circulating supply held in unspent outputs whose age falls more than ten years. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to circulating supply exactly, verified to machine precision. Bit-identical to the retired \"supply last active over 10 years\" series.", "limit": "It cannot distinguish deliberate cold storage from permanently lost keys, and it is the same series as the old \"supply last active over 10 years\" line. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "hodl waves", "coin age", "how long have coins been held", "supply by age", "over 10 years" ], "aliasSeries": [ "supply_ge_10y" ], "shape": "trend", "kind": "stock" }, { "slug": "supply-untouched-1y", "series": "supply_ge_1y", "label": "Supply untouched for over a year", "subtitle": "the 1y+ HODL wave", "categories": [ "holder-cohorts", "cycle-position" ], "canonical": "holder-cohorts", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "How many bitcoin have not moved in over a year. On the cycle dashboard this is the one row read upside down: a big pile of coins untouched for a year is what a bottom looks like, so a hot reading there means that pile is being spent back into the market.", "technical": "Circulating supply held in outputs aged one year or more, which is exactly the sum of the age bands at or above one year. The cycle dashboard ranks its SHARE of supply, detrended over 129,600 blocks (about 2.5 years) and inverted before ranking, so that red still means \"near a top\". Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144.", "limit": "The raw level only grinds upward over the years, so what the dashboard ranks is its deviation from its own multi-year trend, not its level. It also turns early: it went hot before three of the last four tops rather than at them. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "1y hodl wave", "hodl waves", "supply last active 1 year", "bottoms", "are holders selling", "accumulation", "coin age" ], "shape": "osc", "kind": "stock" }, { "slug": "coin-days-destroyed-under-1d", "series": "cdd_lt1d", "label": "Coin-days destroyed, coins aged under 1 day", "subtitle": "dormant time given up by coins held less than a day", "categories": [ "old-coins-spent-by-age" ], "canonical": "old-coins-spent-by-age", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "Coins that moved within a day of arriving destroy almost no stored time: this band is 92% of all bitcoin volume but only 1.2% of all coin-days destroyed. That gap is the whole argument for measuring holding time instead of volume.", "technical": "For every coin spent whose age fell less than a day, its size in bitcoin times the days it had sat still. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total coin-days destroyed exactly. This band is 1.2% of the all-time total.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "coin days destroyed", "cdd by age", "old coins moving", "which holders are selling", "under 1 day" ], "shape": "osc", "kind": "flow" }, { "slug": "coin-days-destroyed-1d-1w", "series": "cdd_1d_1w", "label": "Coin-days destroyed, coins aged 1 day to 1 week", "subtitle": "dormant time given up by coins held between a day and a week", "categories": [ "old-coins-spent-by-age" ], "canonical": "old-coins-spent-by-age", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "Fast money: 4.4% of volume and 2.7% of destroyed holding time. Still mostly trading rather than holders changing their minds.", "technical": "For every coin spent whose age fell between a day and a week, its size in bitcoin times the days it had sat still. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total coin-days destroyed exactly. This band is 2.7% of the all-time total.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "coin days destroyed", "cdd by age", "old coins moving", "which holders are selling", "1 day to 1 week" ], "shape": "osc", "kind": "flow" }, { "slug": "coin-days-destroyed-1w-1m", "series": "cdd_1w_1m", "label": "Coin-days destroyed, coins aged 1 week to 1 month", "subtitle": "dormant time given up by coins held between a week and a month", "categories": [ "old-coins-spent-by-age" ], "canonical": "old-coins-spent-by-age", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "The first band where holding time starts to outweigh volume: 1.6% of bitcoin moved, but 5.2% of all coin-days destroyed. Past here, age does the talking, not size.", "technical": "For every coin spent whose age fell between a week and a month, its size in bitcoin times the days it had sat still. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total coin-days destroyed exactly. This band is 5.2% of the all-time total.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "coin days destroyed", "cdd by age", "old coins moving", "which holders are selling", "1 week to 1 month" ], "shape": "osc", "kind": "flow" }, { "slug": "coin-days-destroyed-1m-3m", "series": "cdd_1m_3m", "label": "Coin-days destroyed, coins aged 1 to 3 months", "subtitle": "dormant time given up by coins held between one and three months", "categories": [ "old-coins-spent-by-age" ], "canonical": "old-coins-spent-by-age", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "How much accumulated holding time was given up by coins that had been sitting between one and three months before they moved. This band is 9.2% of all coin-days ever destroyed.", "technical": "For every coin spent whose age fell between one and three months, its size in bitcoin times the days it had sat still. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total coin-days destroyed exactly. This band is 9.2% of the all-time total.", "limit": "This band carries the same signal as its spent-volume twin, at a measured correlation of 0.989, because coins inside a narrow age band all carry a similar number of days. It is charted here but has no page of its own: read the spent-volume band instead, which says the same thing in bitcoin rather than bitcoin-days. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "coin days destroyed", "cdd by age", "old coins moving", "which holders are selling", "1 to 3 months" ], "sameAs": [ { "slug": "spent-volume-aged-1m-3m", "relation": "near-duplicate", "note": "r = 0.989 over 4,806 sampled heights." } ], "page": false, "shape": "osc", "kind": "flow" }, { "slug": "coin-days-destroyed-3m-6m", "series": "cdd_3m_6m", "label": "Coin-days destroyed, coins aged 3 to 6 months", "subtitle": "dormant time given up by coins held between three and six months", "categories": [ "old-coins-spent-by-age" ], "canonical": "old-coins-spent-by-age", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "How much accumulated holding time was given up by coins that had been sitting between three and six months before they moved. This band is 10.3% of all coin-days ever destroyed.", "technical": "For every coin spent whose age fell between three and six months, its size in bitcoin times the days it had sat still. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total coin-days destroyed exactly. This band is 10.3% of the all-time total.", "limit": "This band carries the same signal as its spent-volume twin, at a measured correlation of 0.976, because coins inside a narrow age band all carry a similar number of days. It is charted here but has no page of its own: read the spent-volume band instead, which says the same thing in bitcoin rather than bitcoin-days. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "coin days destroyed", "cdd by age", "old coins moving", "which holders are selling", "3 to 6 months" ], "sameAs": [ { "slug": "spent-volume-aged-3m-6m", "relation": "near-duplicate", "note": "r = 0.976 over 4,806 sampled heights." } ], "page": false, "shape": "osc", "kind": "flow" }, { "slug": "coin-days-destroyed-6m-1y", "series": "cdd_6m_1y", "label": "Coin-days destroyed, coins aged 6 to 12 months", "subtitle": "dormant time given up by coins held between six months and a year", "categories": [ "old-coins-spent-by-age" ], "canonical": "old-coins-spent-by-age", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "How much accumulated holding time was given up by coins that had been sitting between six months and a year before they moved. This band is 19.3% of all coin-days ever destroyed.", "technical": "For every coin spent whose age fell between six months and a year, its size in bitcoin times the days it had sat still. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total coin-days destroyed exactly. This band is 19.3% of the all-time total.", "limit": "This band carries the same signal as its spent-volume twin, at a measured correlation of 0.989, because coins inside a narrow age band all carry a similar number of days. It is charted here but has no page of its own: read the spent-volume band instead, which says the same thing in bitcoin rather than bitcoin-days. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "coin days destroyed", "cdd by age", "old coins moving", "which holders are selling", "6 to 12 months" ], "sameAs": [ { "slug": "spent-volume-aged-6m-1y", "relation": "near-duplicate", "note": "r = 0.989 over 4,806 sampled heights." } ], "page": false, "shape": "osc", "kind": "flow" }, { "slug": "coin-days-destroyed-1y-2y", "series": "cdd_1y_2y", "label": "Coin-days destroyed, coins aged 1 to 2 years", "subtitle": "dormant time given up by coins held between one and two years", "categories": [ "old-coins-spent-by-age" ], "canonical": "old-coins-spent-by-age", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "How much accumulated holding time was given up by coins that had been sitting between one and two years before they moved. This band is 14.3% of all coin-days ever destroyed.", "technical": "For every coin spent whose age fell between one and two years, its size in bitcoin times the days it had sat still. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total coin-days destroyed exactly. This band is 14.3% of the all-time total.", "limit": "This band carries the same signal as its spent-volume twin, at a measured correlation of 0.984, because coins inside a narrow age band all carry a similar number of days. It is charted here but has no page of its own: read the spent-volume band instead, which says the same thing in bitcoin rather than bitcoin-days. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "coin days destroyed", "cdd by age", "old coins moving", "which holders are selling", "1 to 2 years" ], "sameAs": [ { "slug": "spent-volume-aged-1y-2y", "relation": "near-duplicate", "note": "r = 0.984 over 4,806 sampled heights." } ], "page": false, "shape": "osc", "kind": "flow" }, { "slug": "coin-days-destroyed-2y-3y", "series": "cdd_2y_3y", "label": "Coin-days destroyed, coins aged 2 to 3 years", "subtitle": "dormant time given up by coins held between two and three years", "categories": [ "old-coins-spent-by-age" ], "canonical": "old-coins-spent-by-age", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "How much accumulated holding time was given up by coins that had been sitting between two and three years before they moved. This band is 10.3% of all coin-days ever destroyed.", "technical": "For every coin spent whose age fell between two and three years, its size in bitcoin times the days it had sat still. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total coin-days destroyed exactly. This band is 10.3% of the all-time total.", "limit": "This band carries the same signal as its spent-volume twin, at a measured correlation of 0.999, because coins inside a narrow age band all carry a similar number of days. It is charted here but has no page of its own: read the spent-volume band instead, which says the same thing in bitcoin rather than bitcoin-days. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "coin days destroyed", "cdd by age", "old coins moving", "which holders are selling", "2 to 3 years" ], "sameAs": [ { "slug": "spent-volume-aged-2y-3y", "relation": "near-duplicate", "note": "r = 0.999 over 4,806 sampled heights." } ], "page": false, "shape": "osc", "kind": "flow" }, { "slug": "coin-days-destroyed-3y-5y", "series": "cdd_3y_5y", "label": "Coin-days destroyed, coins aged 3 to 5 years", "subtitle": "dormant time given up by coins held between three and five years", "categories": [ "old-coins-spent-by-age" ], "canonical": "old-coins-spent-by-age", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "How much accumulated holding time was given up by coins that had been sitting between three and five years before they moved. This band is 18.1% of all coin-days ever destroyed.", "technical": "For every coin spent whose age fell between three and five years, its size in bitcoin times the days it had sat still. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total coin-days destroyed exactly. This band is 18.1% of the all-time total.", "limit": "This band carries the same signal as its spent-volume twin, at a measured correlation of 0.986, because coins inside a narrow age band all carry a similar number of days. It is charted here but has no page of its own: read the spent-volume band instead, which says the same thing in bitcoin rather than bitcoin-days. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "coin days destroyed", "cdd by age", "old coins moving", "which holders are selling", "3 to 5 years" ], "sameAs": [ { "slug": "spent-volume-aged-3y-5y", "relation": "near-duplicate", "note": "r = 0.986 over 4,806 sampled heights." } ], "page": false, "shape": "osc", "kind": "flow" }, { "slug": "coin-days-destroyed-5y-7y", "series": "cdd_5y_7y", "label": "Coin-days destroyed, coins aged 5 to 7 years", "subtitle": "dormant time given up by coins held between five and seven years", "categories": [ "old-coins-spent-by-age" ], "canonical": "old-coins-spent-by-age", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "How much accumulated holding time was given up by coins that had been sitting between five and seven years before they moved. This band is 4.5% of all coin-days ever destroyed.", "technical": "For every coin spent whose age fell between five and seven years, its size in bitcoin times the days it had sat still. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total coin-days destroyed exactly. This band is 4.5% of the all-time total.", "limit": "This band carries the same signal as its spent-volume twin, at a measured correlation of 0.998, because coins inside a narrow age band all carry a similar number of days. It is charted here but has no page of its own: read the spent-volume band instead, which says the same thing in bitcoin rather than bitcoin-days. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "coin days destroyed", "cdd by age", "old coins moving", "which holders are selling", "5 to 7 years" ], "sameAs": [ { "slug": "spent-volume-aged-5y-7y", "relation": "near-duplicate", "note": "r = 0.998 over 4,806 sampled heights." } ], "page": false, "shape": "osc", "kind": "flow" }, { "slug": "coin-days-destroyed-7y-10y", "series": "cdd_7y_10y", "label": "Coin-days destroyed, coins aged 7 to 10 years", "subtitle": "dormant time given up by coins held between seven and ten years", "categories": [ "old-coins-spent-by-age" ], "canonical": "old-coins-spent-by-age", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "How much accumulated holding time was given up by coins that had been sitting between seven and ten years before they moved. This band is 4.3% of all coin-days ever destroyed.", "technical": "For every coin spent whose age fell between seven and ten years, its size in bitcoin times the days it had sat still. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total coin-days destroyed exactly. This band is 4.3% of the all-time total.", "limit": "This band carries the same signal as its spent-volume twin, at a measured correlation of 0.999, because coins inside a narrow age band all carry a similar number of days. It is charted here but has no page of its own: read the spent-volume band instead, which says the same thing in bitcoin rather than bitcoin-days. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "coin days destroyed", "cdd by age", "old coins moving", "which holders are selling", "7 to 10 years" ], "sameAs": [ { "slug": "spent-volume-aged-7y-10y", "relation": "near-duplicate", "note": "r = 0.999 over 4,806 sampled heights." } ], "page": false, "shape": "osc", "kind": "flow" }, { "slug": "coin-days-destroyed-over-10y", "series": "cdd_10y_plus", "label": "Coin-days destroyed, coins aged over 10 years", "subtitle": "dormant time given up by coins held more than ten years", "categories": [ "old-coins-spent-by-age" ], "canonical": "old-coins-spent-by-age", "unit": "BTC-days", "provisional": false, "quality": "exact", "plain": "How much accumulated holding time was given up by coins that had been sitting more than ten years before they moved. This band is 0.8% of all coin-days ever destroyed.", "technical": "For every coin spent whose age fell more than ten years, its size in bitcoin times the days it had sat still. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total coin-days destroyed exactly. This band is 0.8% of the all-time total.", "limit": "This band carries the same signal as its spent-volume twin, at a measured correlation of 0.994, because coins inside a narrow age band all carry a similar number of days. It is charted here but has no page of its own: read the spent-volume band instead, which says the same thing in bitcoin rather than bitcoin-days. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "coin days destroyed", "cdd by age", "old coins moving", "which holders are selling", "over 10 years" ], "sameAs": [ { "slug": "spent-volume-aged-over-10y", "relation": "near-duplicate", "note": "r = 0.994 over 4,806 sampled heights." } ], "page": false, "shape": "osc", "kind": "flow" }, { "slug": "spent-volume-aged-under-1d", "series": "sv_lt1d", "label": "Spent volume, coins aged under 1 day", "subtitle": "bitcoin moved after sitting less than a day", "categories": [ "spent-volume-by-age" ], "canonical": "spent-volume-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Bitcoin that moved within a day of arriving. It is 92% of all onchain volume, which is the single most useful fact about onchain volume: almost none of it is holders changing their minds.", "technical": "Value of outputs spent whose age fell less than a day. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total spent output volume exactly.", "limit": "Most of this is exchange internals, change returning to the sender and consolidation, so it is not a payments figure and never was. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "spent volume by age", "which holders are selling", "old coins moving", "coin age", "under 1 day" ], "validFrom": 199592, "shape": "osc", "kind": "flow" }, { "slug": "spent-volume-aged-1d-1w", "series": "sv_1d_1w", "label": "Spent volume, coins aged 1 day to 1 week", "subtitle": "bitcoin moved after sitting between a day and a week", "categories": [ "spent-volume-by-age" ], "canonical": "spent-volume-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Coins bought this week and already sold. A rising line is short-term trading heating up, not holders capitulating.", "technical": "Value of outputs spent whose age fell between a day and a week. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total spent output volume exactly.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "spent volume by age", "which holders are selling", "old coins moving", "coin age", "1 day to 1 week" ], "shape": "osc", "kind": "flow" }, { "slug": "spent-volume-aged-1w-1m", "series": "sv_1w_1m", "label": "Spent volume, coins aged 1 week to 1 month", "subtitle": "bitcoin moved after sitting between a week and a month", "categories": [ "spent-volume-by-age" ], "canonical": "spent-volume-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The first sign of impatience: coins that were held long enough to look like a decision, then sold anyway.", "technical": "Value of outputs spent whose age fell between a week and a month. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total spent output volume exactly.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "spent volume by age", "which holders are selling", "old coins moving", "coin age", "1 week to 1 month" ], "shape": "osc", "kind": "flow" }, { "slug": "spent-volume-aged-1m-3m", "series": "sv_1m_3m", "label": "Spent volume, coins aged 1 to 3 months", "subtitle": "bitcoin moved after sitting between one and three months", "categories": [ "spent-volume-by-age" ], "canonical": "spent-volume-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Coins bought roughly one move ago and sold into the next one. This is where a failed rally shows up first.", "technical": "Value of outputs spent whose age fell between one and three months. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total spent output volume exactly.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "spent volume by age", "which holders are selling", "old coins moving", "coin age", "1 to 3 months" ], "shape": "osc", "kind": "flow" }, { "slug": "spent-volume-aged-3m-6m", "series": "sv_3m_6m", "label": "Spent volume, coins aged 3 to 6 months", "subtitle": "bitcoin moved after sitting between three and six months", "categories": [ "spent-volume-by-age" ], "canonical": "spent-volume-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The band that straddles the 155-day long-term holder line, so it mixes coins the industry counts as patient with coins it does not.", "technical": "Value of outputs spent whose age fell between three and six months. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total spent output volume exactly.", "limit": "The 155-day boundary falls inside this band, so it does not map cleanly onto the long-term holder cohort. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "spent volume by age", "which holders are selling", "old coins moving", "coin age", "3 to 6 months" ], "shape": "osc", "kind": "flow" }, { "slug": "spent-volume-aged-6m-1y", "series": "sv_6m_1y", "label": "Spent volume, coins aged 6 to 12 months", "subtitle": "bitcoin moved after sitting between six months and a year", "categories": [ "spent-volume-by-age" ], "canonical": "spent-volume-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Coins held through at least two quarters and then sold. Sustained readings here mean the patient cohort is starting to let go.", "technical": "Value of outputs spent whose age fell between six months and a year. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total spent output volume exactly.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "spent volume by age", "which holders are selling", "old coins moving", "coin age", "6 to 12 months" ], "shape": "osc", "kind": "flow" }, { "slug": "spent-volume-aged-1y-2y", "series": "sv_1y_2y", "label": "Spent volume, coins aged 1 to 2 years", "subtitle": "bitcoin moved after sitting between one and two years", "categories": [ "spent-volume-by-age" ], "canonical": "spent-volume-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Last cycle's buyers taking profit. This band leads the way at tops: it is the first old cohort to sell into strength.", "technical": "Value of outputs spent whose age fell between one and two years. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total spent output volume exactly.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "spent volume by age", "which holders are selling", "old coins moving", "coin age", "1 to 2 years" ], "shape": "osc", "kind": "flow" }, { "slug": "spent-volume-aged-2y-3y", "series": "sv_2y_3y", "label": "Spent volume, coins aged 2 to 3 years", "subtitle": "bitcoin moved after sitting between two and three years", "categories": [ "spent-volume-by-age" ], "canonical": "spent-volume-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Coins bought a full cycle ago being sold. Movement here is real distribution, not trading, and it clusters in the last third of a bull market.", "technical": "Value of outputs spent whose age fell between two and three years. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total spent output volume exactly.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "spent volume by age", "which holders are selling", "old coins moving", "coin age", "2 to 3 years" ], "shape": "osc", "kind": "flow" }, { "slug": "spent-volume-aged-3y-5y", "series": "sv_3y_5y", "label": "Spent volume, coins aged 3 to 5 years", "subtitle": "bitcoin moved after sitting between three and five years", "categories": [ "spent-volume-by-age" ], "canonical": "spent-volume-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Coins that lived through a halving and a bear market before moving. Every spike in this band is a decision somebody thought about for years.", "technical": "Value of outputs spent whose age fell between three and five years. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total spent output volume exactly.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "spent volume by age", "which holders are selling", "old coins moving", "coin age", "3 to 5 years" ], "shape": "osc", "kind": "flow" }, { "slug": "spent-volume-aged-5y-7y", "series": "sv_5y_7y", "label": "Spent volume, coins aged 5 to 7 years", "subtitle": "bitcoin moved after sitting between five and seven years", "categories": [ "spent-volume-by-age" ], "canonical": "spent-volume-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Held across two halvings, then sold. Rare enough that individual spikes usually have a story attached, such as an old exchange estate being wound up.", "technical": "Value of outputs spent whose age fell between five and seven years. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total spent output volume exactly.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "spent volume by age", "which holders are selling", "old coins moving", "coin age", "5 to 7 years" ], "shape": "osc", "kind": "flow" }, { "slug": "spent-volume-aged-7y-10y", "series": "sv_7y_10y", "label": "Spent volume, coins aged 7 to 10 years", "subtitle": "bitcoin moved after sitting between seven and ten years", "categories": [ "spent-volume-by-age" ], "canonical": "spent-volume-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Pre-2018 bitcoin moving. Around 0.006% of all volume ever, so any visible spike here is a single large holder, not a trend.", "technical": "Value of outputs spent whose age fell between seven and ten years. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total spent output volume exactly.", "limit": "Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "spent volume by age", "which holders are selling", "old coins moving", "coin age", "7 to 10 years" ], "shape": "osc", "kind": "flow" }, { "slug": "spent-volume-aged-over-10y", "series": "sv_10y_plus", "label": "Spent volume, coins aged over 10 years", "subtitle": "bitcoin moved after sitting more than ten years", "categories": [ "spent-volume-by-age" ], "canonical": "spent-volume-by-age", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Satoshi-era coins waking up. This is 0.0008% of all volume ever recorded, so a spike is always an individual event and is usually reported as news the same day.", "technical": "Value of outputs spent whose age fell more than ten years. Age is real elapsed time off a monotonised block clock (the running maximum of block timestamps), not blocks divided by 144. The twelve bands sum to total spent output volume exactly.", "limit": "A single old wallet can create the entire spike, and a coin moving is not the same as a coin being sold. Age is per output, not per owner: consolidating coins or receiving change resets the clock on bitcoin nobody sold.", "keywords": [ "spent volume by age", "which holders are selling", "old coins moving", "coin age", "over 10 years" ], "shape": "osc", "kind": "flow" }, { "slug": "addresses-with-a-balance", "series": "addr_nonzero", "label": "Addresses with a balance", "subtitle": "how many addresses hold anything at all", "categories": [ "how-many-holders" ], "canonical": "how-many-holders", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many separate addresses hold any bitcoin at all. It is the closest thing the chain offers to a headcount of owners, and it is still not a headcount: it rises when wallets create change addresses and falls when they tidy them up.", "technical": "Distinct scriptPubKeys with a strictly positive balance at this height. An address here is a scriptPubKey, so the same public key paid as P2PK and as P2PKH counts twice where a block explorer shows one. Bare multisig, non-standard and future-witness scripts are counted too, because they hold real supply. Measured 2026-08-05, this whole-script universe is what a block explorer counts too: it sits 0.24% above bitinfocharts at the tip, while the address-shaped-only subset is 4.30% below. This is the comparable line.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. Our universe is every spendable script, so bare multisig, raw P2PK and non-standard scripts are in this number even though they have no address text. MEASURED 2026-08-05: that turns out to be what a block explorer counts too -- this series is 0.24% above bitinfocharts' 59,144,095 at the tip, while the address-shaped-only subset is 4.30% below it. So THIS is the comparable line.", "keywords": [ "how many people own bitcoin", "addresses", "holders", "adoption", "wallets", "non zero addresses" ], "kind": "stock", "sameAs": [ { "slug": "entities-with-a-balance", "relation": "near-duplicate", "note": "The entity version, 56.42M against 59.29M at the tip, 4.8% lower. Not a second measurement." } ], "validFrom": 1085, "shape": "osc" }, { "slug": "addresses-with-a-balance-addressable", "series": "addr_nonzero_addressable", "label": "Addresses with a balance (address-shaped only)", "subtitle": "the subset you could write down", "categories": [ "data-quality", "how-many-holders" ], "canonical": "data-quality", "unit": "count", "provisional": false, "quality": "exact", "plain": "The same count, restricted to holdings that sit in a script with a conventional address you could write on paper. The gap to the full count is bitcoin held in scripts that have no address text at all: 4.5% at the tip, and 80% back in 2010.", "technical": "The subset of addresses with a balance whose script type has a conventional address encoding: P2PKH, P2SH, P2WPKH, P2WSH, P2TR. Built on the assumption that this would be the explorer-comparable number; the reconciliation says otherwise, so read it as what it is, the share of held balances that sit in a writable address.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. It cannot merge a P2PK script with the P2PKH of the same key, because script_hash16 is one-way, so the two are counted separately throughout.", "keywords": [ "addresses", "script types", "data quality", "p2pk", "taproot" ], "diagnostic": true, "kind": "stock", "shape": "osc" }, { "slug": "new-addresses", "series": "addr_new", "label": "New addresses", "subtitle": "addresses seen for the first time ever", "categories": [ "how-many-holders" ], "canonical": "how-many-holders", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many addresses appeared in this block that had never been seen before in the whole history of the chain. It looks like an adoption number and mostly is not: most new addresses are change addresses the sender's own wallet just invented.", "technical": "Scripts seen for the first time ever in this block, against the set of every script in chain history. This is the series that needed the 1.3-billion-row side table.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. Most 'new addresses' are change addresses the sender's own wallet just invented, not new owners. The series is a wallet-software indicator first and an adoption indicator a distant second.", "keywords": [ "new addresses", "adoption", "growth", "how many people own bitcoin", "wallets" ], "kind": "flow", "sameAs": [ { "slug": "new-entities", "relation": "near-duplicate", "note": "The tier D entity version of this line, which folds co-spent addresses into one owner. At block 961,000 this reads 3,584 against 3,633 new addresses, a fold of barely 1%: a brand-new script has usually not been co-spent with anything yet, so it has nothing to be folded into. Read one of the two, not both as agreement." } ], "shape": "osc" }, { "slug": "addresses-ever-seen", "series": "addr_total", "label": "Addresses ever seen", "subtitle": "the running total, which only goes up", "categories": [ "how-many-holders" ], "canonical": "how-many-holders", "unit": "count", "provisional": false, "quality": "exact", "plain": "Every address that has ever appeared on the chain, added up. It only ever goes up, including for addresses that were emptied years ago and will never be used again.", "technical": "Running total of new addresses. Monotone by construction.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. Monotone series flatter the present: it can only ever go up, so it says nothing about whether anyone still holds anything.", "keywords": [ "total addresses", "addresses ever", "adoption", "growth" ], "kind": "stock", "sameAs": [ { "slug": "entities-ever-seen", "relation": "near-duplicate", "note": "The entity version of the same count, 717.7M against 1.536B at the tip. Not a second measurement." } ], "validFrom": 549, "shape": "trend" }, { "slug": "active-addresses", "series": "addr_active", "label": "Active addresses", "subtitle": "addresses that moved coins in this block", "categories": [ "how-many-holders", "network-activity" ], "canonical": "how-many-holders", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many addresses sent or received in this block. It is the standard proxy for how busy the network is, and it is per block here rather than per day, which is finer than anyone else publishes.", "technical": "Distinct addresses that sent or received in this block. An address that does both in the same block counts once.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. Per BLOCK, not per day: a busy block and a quiet block are different points, and summing 144 of them double-counts any address active twice in a day.", "keywords": [ "active addresses", "how busy is bitcoin", "network usage", "daily active", "adoption" ], "kind": "flow", "sameAs": [ { "slug": "active-entities", "relation": "near-duplicate", "note": "The tier D entity version of this line, which folds co-spent addresses into one owner. At block 961,000 this reads 8,120 against 11,685 active addresses. The fold only ever removes, never adds, so the entity line sits below the address line everywhere. Read one of the two, not both as agreement." } ], "shape": "osc" }, { "slug": "sending-addresses", "series": "addr_sending", "label": "Sending addresses", "subtitle": "addresses that spent in this block", "categories": [ "how-many-holders" ], "canonical": "how-many-holders", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many addresses had coins spent out of them in this block. Read against receiving addresses it shows the shape of a block: few senders and many receivers is an exchange paying people out.", "technical": "Distinct addresses that had an output spent in this block.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount.", "keywords": [ "sending addresses", "spenders", "network usage", "are holders selling" ], "kind": "flow", "sameAs": [ { "slug": "sending-entities", "relation": "near-duplicate", "note": "The tier D entity version of this line, which folds co-spent addresses into one owner. At block 961,000 this reads 3,207 against 4,845 sending addresses, the same fold applied to the sending side. Read one of the two, not both as agreement." } ], "shape": "osc" }, { "slug": "receiving-addresses", "series": "addr_receiving", "label": "Receiving addresses", "subtitle": "addresses that were paid in this block", "categories": [ "how-many-holders" ], "canonical": "how-many-holders", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many addresses received coins in this block. It runs well above the sending count because one batched exchange payout pays hundreds of addresses from a single transaction.", "technical": "Distinct addresses that received an output in this block.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. Batched exchange payouts pay hundreds of addresses from one transaction, so this line tracks exchange batching policy as much as payment count.", "keywords": [ "receiving addresses", "payments", "network usage", "batching" ], "kind": "flow", "sameAs": [ { "slug": "receiving-entities", "relation": "near-duplicate", "note": "The tier D entity version of this line, which folds co-spent addresses into one owner. At block 961,000 this reads 6,436 against 8,403 receiving addresses. Read one of the two, not both as agreement." } ], "shape": "osc" }, { "slug": "supply-in-addresses-under-0p001", "series": "addr_supply_lt_0p001", "label": "Supply held by addresses of under 0.001 BTC", "subtitle": "bitcoin sitting in addresses holding under 0.001 BTC", "categories": [ "supply-by-wallet-size" ], "canonical": "supply-by-wallet-size", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Dust: balances too small to spend economically at most fee levels. The band is enormous in address count and negligible in coins, which is the first thing to understand about address statistics.", "technical": "Live BTC held by addresses whose balance falls under 0.001 BTC at this height. Band edges sit exactly on histogram bin boundaries, so this is exact rather than interpolated. The ten bands sum to circulating supply excluding provable burns at every height.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The bands are re-sorted every block: an address that grows past an edge moves its whole balance to the next band, so a band can fall while nobody sold anything.", "keywords": [ "supply by wallet size", "whale", "distribution", "who owns bitcoin", "rich list", "under 0.001 BTC" ], "kind": "stock", "sameAs": [ { "slug": "supply-in-entities-under-0p001", "relation": "near-duplicate", "note": "The tier D entity version of this band, which folds co-spent addresses into one owner. Measured at the tip the two differ by +1.1%, because clustering reaches only 7.24% of supply. Do not read them as two signals." } ], "shape": "osc" }, { "slug": "supply-in-addresses-0p001-0p01", "series": "addr_supply_0p001_0p01", "label": "Supply held by addresses of 0.001 to 0.01 BTC", "subtitle": "bitcoin sitting in addresses holding between 0.001 and 0.01 BTC", "categories": [ "supply-by-wallet-size" ], "canonical": "supply-by-wallet-size", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Small change. Much of this is exchange-internal or the residue of old payments rather than anyone's savings.", "technical": "Live BTC held by addresses whose balance falls between 0.001 and 0.01 BTC at this height. Band edges sit exactly on histogram bin boundaries, so this is exact rather than interpolated. The ten bands sum to circulating supply excluding provable burns at every height.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The bands are re-sorted every block: an address that grows past an edge moves its whole balance to the next band, so a band can fall while nobody sold anything.", "keywords": [ "supply by wallet size", "whale", "distribution", "who owns bitcoin", "rich list", "0.001 to 0.01 BTC" ], "kind": "stock", "sameAs": [ { "slug": "supply-in-entities-0p001-0p01", "relation": "near-duplicate", "note": "The tier D entity version of this band, which folds co-spent addresses into one owner. Measured at the tip the two differ by +2.1%, because clustering reaches only 7.24% of supply. Do not read them as two signals." } ], "shape": "osc" }, { "slug": "supply-in-addresses-0p01-0p1", "series": "addr_supply_0p01_0p1", "label": "Supply held by addresses of 0.01 to 0.1 BTC", "subtitle": "bitcoin sitting in addresses holding between 0.01 and 0.1 BTC", "categories": [ "supply-by-wallet-size" ], "canonical": "supply-by-wallet-size", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The band where retail saving starts to be visible: a few hundred to a few thousand euro at recent prices.", "technical": "Live BTC held by addresses whose balance falls between 0.01 and 0.1 BTC at this height. Band edges sit exactly on histogram bin boundaries, so this is exact rather than interpolated. The ten bands sum to circulating supply excluding provable burns at every height.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The bands are re-sorted every block: an address that grows past an edge moves its whole balance to the next band, so a band can fall while nobody sold anything.", "keywords": [ "supply by wallet size", "whale", "distribution", "who owns bitcoin", "rich list", "0.01 to 0.1 BTC" ], "kind": "stock", "sameAs": [ { "slug": "supply-in-entities-0p01-0p1", "relation": "near-duplicate", "note": "The tier D entity version of this band, which folds co-spent addresses into one owner. Measured at the tip the two differ by +2.3%, because clustering reaches only 7.24% of supply. Do not read them as two signals." } ], "shape": "osc" }, { "slug": "supply-in-addresses-0p1-1", "series": "addr_supply_0p1_1", "label": "Supply held by addresses of 0.1 to 1 BTC", "subtitle": "bitcoin sitting in addresses holding between 0.1 and 1 BTC", "categories": [ "supply-by-wallet-size" ], "canonical": "supply-by-wallet-size", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Sub-wholecoiner savers. This band has grown through every cycle and is the cleanest visible signature of ordinary people buying and keeping.", "technical": "Live BTC held by addresses whose balance falls between 0.1 and 1 BTC at this height. Band edges sit exactly on histogram bin boundaries, so this is exact rather than interpolated. The ten bands sum to circulating supply excluding provable burns at every height.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The bands are re-sorted every block: an address that grows past an edge moves its whole balance to the next band, so a band can fall while nobody sold anything.", "keywords": [ "supply by wallet size", "whale", "distribution", "who owns bitcoin", "rich list", "0.1 to 1 BTC" ], "kind": "stock", "sameAs": [ { "slug": "supply-in-entities-0p1-1", "relation": "near-duplicate", "note": "The tier D entity version of this band, which folds co-spent addresses into one owner. Measured at the tip the two differ by +5.5%, because clustering reaches only 7.24% of supply. Do not read them as two signals." } ], "shape": "osc" }, { "slug": "supply-in-addresses-1-10", "series": "addr_supply_1_10", "label": "Supply held by addresses of 1 to 10 BTC", "subtitle": "bitcoin sitting in addresses holding between 1 and 10 BTC", "categories": [ "supply-by-wallet-size" ], "canonical": "supply-by-wallet-size", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Wholecoiners and small stackers. It is the band people mean when they talk about individual holders rather than institutions.", "technical": "Live BTC held by addresses whose balance falls between 1 and 10 BTC at this height. Band edges sit exactly on histogram bin boundaries, so this is exact rather than interpolated. The ten bands sum to circulating supply excluding provable burns at every height.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The bands are re-sorted every block: an address that grows past an edge moves its whole balance to the next band, so a band can fall while nobody sold anything.", "keywords": [ "supply by wallet size", "whale", "distribution", "who owns bitcoin", "rich list", "1 to 10 BTC" ], "kind": "stock", "sameAs": [ { "slug": "supply-in-entities-1-10", "relation": "near-duplicate", "note": "The tier D entity version of this band, which folds co-spent addresses into one owner. Measured at the tip the two differ by -3.0%, because clustering reaches only 7.24% of supply. Do not read them as two signals." } ], "shape": "osc" }, { "slug": "supply-in-addresses-10-100", "series": "addr_supply_10_100", "label": "Supply held by addresses of 10 to 100 BTC", "subtitle": "bitcoin sitting in addresses holding between 10 and 100 BTC", "categories": [ "supply-by-wallet-size" ], "canonical": "supply-by-wallet-size", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Serious individual and small-fund money. Big enough to move a market in 2013 and invisible in it now.", "technical": "Live BTC held by addresses whose balance falls between 10 and 100 BTC at this height. Band edges sit exactly on histogram bin boundaries, so this is exact rather than interpolated. The ten bands sum to circulating supply excluding provable burns at every height.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The bands are re-sorted every block: an address that grows past an edge moves its whole balance to the next band, so a band can fall while nobody sold anything.", "keywords": [ "supply by wallet size", "whale", "distribution", "who owns bitcoin", "rich list", "10 to 100 BTC" ], "kind": "stock", "sameAs": [ { "slug": "supply-in-entities-10-100", "relation": "near-duplicate", "note": "The tier D entity version of this band, which folds co-spent addresses into one owner. Measured at the tip the two differ by -0.3%, because clustering reaches only 7.24% of supply. Do not read them as two signals." } ], "validFrom": 5445, "shape": "osc" }, { "slug": "supply-in-addresses-100-1k", "series": "addr_supply_100_1k", "label": "Supply held by addresses of 100 to 1,000 BTC", "subtitle": "bitcoin sitting in addresses holding between 100 and 1,000 BTC", "categories": [ "supply-by-wallet-size" ], "canonical": "supply-by-wallet-size", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Where individual holders end and desks, funds and exchange hot wallets begin. Nothing in the data says which of those a given address is.", "technical": "Live BTC held by addresses whose balance falls between 100 and 1,000 BTC at this height. Band edges sit exactly on histogram bin boundaries, so this is exact rather than interpolated. The ten bands sum to circulating supply excluding provable burns at every height.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The bands are re-sorted every block: an address that grows past an edge moves its whole balance to the next band, so a band can fall while nobody sold anything.", "keywords": [ "supply by wallet size", "whale", "distribution", "who owns bitcoin", "rich list", "100 to 1,000 BTC" ], "kind": "stock", "sameAs": [ { "slug": "supply-in-entities-100-1k", "relation": "near-duplicate", "note": "The tier D entity version of this band, which folds co-spent addresses into one owner. Measured at the tip the two differ by -1.1%, because clustering reaches only 7.24% of supply. Do not read them as two signals." } ], "shape": "osc" }, { "slug": "supply-in-addresses-1k-10k", "series": "addr_supply_1k_10k", "label": "Supply held by addresses of 1,000 to 10,000 BTC", "subtitle": "bitcoin sitting in addresses holding between 1,000 and 10,000 BTC", "categories": [ "supply-by-wallet-size" ], "canonical": "supply-by-wallet-size", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Institutional scale. Movements here are usually operational, an exchange rotating storage, rather than anybody changing their mind.", "technical": "Live BTC held by addresses whose balance falls between 1,000 and 10,000 BTC at this height. Band edges sit exactly on histogram bin boundaries, so this is exact rather than interpolated. The ten bands sum to circulating supply excluding provable burns at every height.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The bands are re-sorted every block: an address that grows past an edge moves its whole balance to the next band, so a band can fall while nobody sold anything.", "keywords": [ "supply by wallet size", "whale", "distribution", "who owns bitcoin", "rich list", "1,000 to 10,000 BTC" ], "kind": "stock", "sameAs": [ { "slug": "supply-in-entities-1k-10k", "relation": "near-duplicate", "note": "The tier D entity version of this band, which folds co-spent addresses into one owner. Measured at the tip the two differ by -0.5%, because clustering reaches only 7.24% of supply. Do not read them as two signals." } ], "shape": "osc" }, { "slug": "supply-in-addresses-10k-100k", "series": "addr_supply_10k_100k", "label": "Supply held by addresses of 10,000 to 100,000 BTC", "subtitle": "bitcoin sitting in addresses holding between 10,000 and 100,000 BTC", "categories": [ "supply-by-wallet-size" ], "canonical": "supply-by-wallet-size", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The largest ordinary addresses on the chain: exchange cold storage, custodians and ETF vaults.", "technical": "Live BTC held by addresses whose balance falls between 10,000 and 100,000 BTC at this height. Band edges sit exactly on histogram bin boundaries, so this is exact rather than interpolated. The ten bands sum to circulating supply excluding provable burns at every height.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The bands are re-sorted every block: an address that grows past an edge moves its whole balance to the next band, so a band can fall while nobody sold anything.", "keywords": [ "supply by wallet size", "whale", "distribution", "who owns bitcoin", "rich list", "10,000 to 100,000 BTC" ], "kind": "stock", "sameAs": [ { "slug": "supply-in-entities-10k-100k", "relation": "near-duplicate", "note": "The tier D entity version of this band, which folds co-spent addresses into one owner. Measured at the tip the two differ by +3.9%, because clustering reaches only 7.24% of supply. Do not read them as two signals." } ], "shape": "osc" }, { "slug": "supply-in-addresses-100k-plus", "series": "addr_supply_100k_plus", "label": "Supply held by addresses of 100,000 BTC and above", "subtitle": "bitcoin sitting in addresses holding of 100,000 BTC or more", "categories": [ "supply-by-wallet-size" ], "canonical": "supply-by-wallet-size", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "A handful of addresses in the whole world. This band is a small enough set that a single custodian reshuffling storage redraws it.", "technical": "Live BTC held by addresses whose balance falls of 100,000 BTC or more at this height. Band edges sit exactly on histogram bin boundaries, so this is exact rather than interpolated. The ten bands sum to circulating supply excluding provable burns at every height.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The bands are re-sorted every block: an address that grows past an edge moves its whole balance to the next band, so a band can fall while nobody sold anything.", "keywords": [ "supply by wallet size", "whale", "distribution", "who owns bitcoin", "rich list", "100,000 BTC and above" ], "kind": "stock", "sameAs": [ { "slug": "supply-in-entities-100k-plus", "relation": "near-duplicate", "note": "The tier D entity version of this band, which folds co-spent addresses into one owner. Measured at the tip the two differ by +0.0%, because clustering reaches only 7.24% of supply. Do not read them as two signals." } ], "shape": "osc" }, { "slug": "addresses-holding-0p01-btc", "series": "addr_ge_0p01", "label": "Addresses holding at least 0.01 BTC", "subtitle": "how many addresses clear 0.01 BTC", "categories": [ "addresses-by-balance" ], "canonical": "addresses-by-balance", "unit": "count", "provisional": false, "quality": "exact", "plain": "The entry rung. Crossing it means a balance worth having rather than dust. It rises when holders accumulate and also when one holder splits a balance across several addresses, and nothing in the data separates the two.", "technical": "Count of addresses with a balance at or above 0.01 BTC. The edge is a power of ten and lands exactly on a histogram bin boundary, so the count is exact.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The famous 'wholecoiner' framing (>= 1 BTC) is an address count, not a person count, and the same person splitting one holding across ten addresses adds ten to it.", "keywords": [ "wholecoiner", "addresses holding 0.01 BTC", "whale", "rich list", "who owns bitcoin", "accumulation" ], "kind": "stock", "validFrom": 1597, "shape": "osc" }, { "slug": "addresses-holding-0p1-btc", "series": "addr_ge_0p1", "label": "Addresses holding at least 0.1 BTC", "subtitle": "how many addresses clear 0.1 BTC", "categories": [ "addresses-by-balance" ], "canonical": "addresses-by-balance", "unit": "count", "provisional": false, "quality": "exact", "plain": "A tenth of a coin, the rung most retail savers actually reach. It rises when holders accumulate and also when one holder splits a balance across several addresses, and nothing in the data separates the two.", "technical": "Count of addresses with a balance at or above 0.1 BTC. The edge is a power of ten and lands exactly on a histogram bin boundary, so the count is exact.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The famous 'wholecoiner' framing (>= 1 BTC) is an address count, not a person count, and the same person splitting one holding across ten addresses adds ten to it.", "keywords": [ "wholecoiner", "addresses holding 0.1 BTC", "whale", "rich list", "who owns bitcoin", "accumulation" ], "kind": "stock", "validFrom": 2061, "shape": "osc" }, { "slug": "addresses-holding-1-btc", "series": "addr_ge_1", "label": "Addresses holding at least 1 BTC", "subtitle": "how many addresses clear 1 BTC", "categories": [ "addresses-by-balance" ], "canonical": "addresses-by-balance", "unit": "count", "provisional": false, "quality": "exact", "plain": "The wholecoiner line, the most quoted number in this whole family and the one most often misread: it counts addresses, not people. It rises when holders accumulate and also when one holder splits a balance across several addresses, and nothing in the data separates the two.", "technical": "Count of addresses with a balance at or above 1 BTC. The edge is a power of ten and lands exactly on a histogram bin boundary, so the count is exact.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The famous 'wholecoiner' framing (>= 1 BTC) is an address count, not a person count, and the same person splitting one holding across ten addresses adds ten to it.", "keywords": [ "wholecoiner", "addresses holding 1 BTC", "whale", "rich list", "who owns bitcoin", "accumulation" ], "kind": "stock", "validFrom": 2965, "shape": "osc" }, { "slug": "addresses-holding-10-btc", "series": "addr_ge_10", "label": "Addresses holding at least 10 BTC", "subtitle": "how many addresses clear 10 BTC", "categories": [ "addresses-by-balance" ], "canonical": "addresses-by-balance", "unit": "count", "provisional": false, "quality": "exact", "plain": "Ten coins. Rare enough that this line barely moves except through real accumulation. It rises when holders accumulate and also when one holder splits a balance across several addresses, and nothing in the data separates the two.", "technical": "Count of addresses with a balance at or above 10 BTC. The edge is a power of ten and lands exactly on a histogram bin boundary, so the count is exact.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The famous 'wholecoiner' framing (>= 1 BTC) is an address count, not a person count, and the same person splitting one holding across ten addresses adds ten to it.", "keywords": [ "wholecoiner", "addresses holding 10 BTC", "whale", "rich list", "who owns bitcoin", "accumulation" ], "kind": "stock", "validFrom": 4743, "shape": "osc" }, { "slug": "addresses-holding-100-btc", "series": "addr_ge_100", "label": "Addresses holding at least 100 BTC", "subtitle": "how many addresses clear 100 BTC", "categories": [ "addresses-by-balance" ], "canonical": "addresses-by-balance", "unit": "count", "provisional": false, "quality": "exact", "plain": "The conventional start of \"whale\". A few tens of thousands of addresses in the world. It rises when holders accumulate and also when one holder splits a balance across several addresses, and nothing in the data separates the two.", "technical": "Count of addresses with a balance at or above 100 BTC. The edge is a power of ten and lands exactly on a histogram bin boundary, so the count is exact.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The famous 'wholecoiner' framing (>= 1 BTC) is an address count, not a person count, and the same person splitting one holding across ten addresses adds ten to it.", "keywords": [ "wholecoiner", "addresses holding 100 BTC", "whale", "rich list", "who owns bitcoin", "accumulation" ], "kind": "stock", "shape": "osc" }, { "slug": "addresses-holding-1k-btc", "series": "addr_ge_1k", "label": "Addresses holding at least 1,000 BTC", "subtitle": "how many addresses clear 1,000 BTC", "categories": [ "addresses-by-balance" ], "canonical": "addresses-by-balance", "unit": "count", "provisional": false, "quality": "exact", "plain": "Institutional scale, and small enough a set that individual movements show up. It rises when holders accumulate and also when one holder splits a balance across several addresses, and nothing in the data separates the two.", "technical": "Count of addresses with a balance at or above 1,000 BTC. The edge is a power of ten and lands exactly on a histogram bin boundary, so the count is exact.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The famous 'wholecoiner' framing (>= 1 BTC) is an address count, not a person count, and the same person splitting one holding across ten addresses adds ten to it.", "keywords": [ "wholecoiner", "addresses holding 1,000 BTC", "whale", "rich list", "who owns bitcoin", "accumulation" ], "kind": "stock", "shape": "osc" }, { "slug": "addresses-holding-10k-btc", "series": "addr_ge_10k", "label": "Addresses holding at least 10,000 BTC", "subtitle": "how many addresses clear 10,000 BTC", "categories": [ "addresses-by-balance" ], "canonical": "addresses-by-balance", "unit": "count", "provisional": false, "quality": "exact", "plain": "A few thousand addresses ever. Almost all of them are custodial. It rises when holders accumulate and also when one holder splits a balance across several addresses, and nothing in the data separates the two.", "technical": "Count of addresses with a balance at or above 10,000 BTC. The edge is a power of ten and lands exactly on a histogram bin boundary, so the count is exact.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The famous 'wholecoiner' framing (>= 1 BTC) is an address count, not a person count, and the same person splitting one holding across ten addresses adds ten to it.", "keywords": [ "wholecoiner", "addresses holding 10,000 BTC", "whale", "rich list", "who owns bitcoin", "accumulation" ], "kind": "stock", "shape": "osc" }, { "slug": "addresses-holding-100k-btc", "series": "addr_ge_100k", "label": "Addresses holding at least 100,000 BTC", "subtitle": "how many addresses clear 100,000 BTC", "categories": [ "addresses-by-balance" ], "canonical": "addresses-by-balance", "unit": "count", "provisional": false, "quality": "exact", "plain": "A number you can count on your fingers. Treat every move in this line as one entity doing one thing. It rises when holders accumulate and also when one holder splits a balance across several addresses, and nothing in the data separates the two.", "technical": "Count of addresses with a balance at or above 100,000 BTC. The edge is a power of ten and lands exactly on a histogram bin boundary, so the count is exact.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The famous 'wholecoiner' framing (>= 1 BTC) is an address count, not a person count, and the same person splitting one holding across ten addresses adds ten to it.", "keywords": [ "wholecoiner", "addresses holding 100,000 BTC", "whale", "rich list", "who owns bitcoin", "accumulation" ], "kind": "stock", "shape": "trend" }, { "slug": "addresses-holding-1-eur", "series": "addr_ge_1_usd", "label": "Addresses holding at least 1 euro", "subtitle": "how many addresses clear 1 in money", "categories": [ "addresses-by-value" ], "canonical": "addresses-by-value", "unit": "count", "provisional": false, "quality": "price-dependent", "plain": "The smallest rung, and mostly a dust line: it moves with the price as much as with adoption. Unlike the coin thresholds beside it, this line moves when the price moves even if nobody buys or sells a thing.", "technical": "Count of addresses whose balance is worth at least 1 at THIS block's price. The threshold in bitcoin moves every block, so it is folded against a live balance histogram rather than filtered.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The threshold lands inside one balance bin (bins are 40 to a decade, so 5.9% wide) and that bin is split linearly in log balance, so the count is exact to well under a bin rather than exact to the coin. It is priced off the same series as tier B, so before 2012 it inherits thin, wide-spread quotes from a handful of exchanges, and coins created before height 68,774 have no price at all and carry a cost basis of zero.", "keywords": [ "addresses holding 1", "millionaire addresses", "adoption", "who owns bitcoin", "wealth distribution" ], "seriesEur": "addr_ge_1_eur", "kind": "stock", "shape": "osc" }, { "slug": "addresses-holding-10-eur", "series": "addr_ge_10_usd", "label": "Addresses holding at least 10 euro", "subtitle": "how many addresses clear 10 in money", "categories": [ "addresses-by-value" ], "canonical": "addresses-by-value", "unit": "count", "provisional": false, "quality": "price-dependent", "plain": "Pocket money. A useful floor on \"addresses holding a meaningful amount\". Unlike the coin thresholds beside it, this line moves when the price moves even if nobody buys or sells a thing.", "technical": "Count of addresses whose balance is worth at least 10 at THIS block's price. The threshold in bitcoin moves every block, so it is folded against a live balance histogram rather than filtered.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The threshold lands inside one balance bin (bins are 40 to a decade, so 5.9% wide) and that bin is split linearly in log balance, so the count is exact to well under a bin rather than exact to the coin. It is priced off the same series as tier B, so before 2012 it inherits thin, wide-spread quotes from a handful of exchanges, and coins created before height 68,774 have no price at all and carry a cost basis of zero.", "keywords": [ "addresses holding 10", "millionaire addresses", "adoption", "who owns bitcoin", "wealth distribution" ], "seriesEur": "addr_ge_10_eur", "kind": "stock", "shape": "osc" }, { "slug": "addresses-holding-100-eur", "series": "addr_ge_100_usd", "label": "Addresses holding at least 100 euro", "subtitle": "how many addresses clear 100 in money", "categories": [ "addresses-by-value" ], "canonical": "addresses-by-value", "unit": "count", "provisional": false, "quality": "price-dependent", "plain": "The first rung that plausibly represents a person who decided to buy something. Unlike the coin thresholds beside it, this line moves when the price moves even if nobody buys or sells a thing.", "technical": "Count of addresses whose balance is worth at least 100 at THIS block's price. The threshold in bitcoin moves every block, so it is folded against a live balance histogram rather than filtered.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The threshold lands inside one balance bin (bins are 40 to a decade, so 5.9% wide) and that bin is split linearly in log balance, so the count is exact to well under a bin rather than exact to the coin. It is priced off the same series as tier B, so before 2012 it inherits thin, wide-spread quotes from a handful of exchanges, and coins created before height 68,774 have no price at all and carry a cost basis of zero.", "keywords": [ "addresses holding 100", "millionaire addresses", "adoption", "who owns bitcoin", "wealth distribution" ], "seriesEur": "addr_ge_100_eur", "kind": "stock", "shape": "osc" }, { "slug": "addresses-holding-1k-eur", "series": "addr_ge_1k_usd", "label": "Addresses holding at least 1,000 euro", "subtitle": "how many addresses clear 1,000 in money", "categories": [ "addresses-by-value" ], "canonical": "addresses-by-value", "unit": "count", "provisional": false, "quality": "price-dependent", "plain": "A real saving. This line is the clearest adoption proxy in the family. Unlike the coin thresholds beside it, this line moves when the price moves even if nobody buys or sells a thing.", "technical": "Count of addresses whose balance is worth at least 1,000 at THIS block's price. The threshold in bitcoin moves every block, so it is folded against a live balance histogram rather than filtered.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The threshold lands inside one balance bin (bins are 40 to a decade, so 5.9% wide) and that bin is split linearly in log balance, so the count is exact to well under a bin rather than exact to the coin. It is priced off the same series as tier B, so before 2012 it inherits thin, wide-spread quotes from a handful of exchanges, and coins created before height 68,774 have no price at all and carry a cost basis of zero.", "keywords": [ "addresses holding 1,000", "millionaire addresses", "adoption", "who owns bitcoin", "wealth distribution" ], "seriesEur": "addr_ge_1k_eur", "kind": "stock", "shape": "osc" }, { "slug": "addresses-holding-10k-eur", "series": "addr_ge_10k_usd", "label": "Addresses holding at least 10,000 euro", "subtitle": "how many addresses clear 10,000 in money", "categories": [ "addresses-by-value" ], "canonical": "addresses-by-value", "unit": "count", "provisional": false, "quality": "price-dependent", "plain": "Serious retail money. Unlike the coin thresholds beside it, this line moves when the price moves even if nobody buys or sells a thing.", "technical": "Count of addresses whose balance is worth at least 10,000 at THIS block's price. The threshold in bitcoin moves every block, so it is folded against a live balance histogram rather than filtered.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The threshold lands inside one balance bin (bins are 40 to a decade, so 5.9% wide) and that bin is split linearly in log balance, so the count is exact to well under a bin rather than exact to the coin. It is priced off the same series as tier B, so before 2012 it inherits thin, wide-spread quotes from a handful of exchanges, and coins created before height 68,774 have no price at all and carry a cost basis of zero.", "keywords": [ "addresses holding 10,000", "millionaire addresses", "adoption", "who owns bitcoin", "wealth distribution" ], "seriesEur": "addr_ge_10k_eur", "kind": "stock", "shape": "osc" }, { "slug": "addresses-holding-100k-eur", "series": "addr_ge_100k_usd", "label": "Addresses holding at least 100,000 euro", "subtitle": "how many addresses clear 100,000 in money", "categories": [ "addresses-by-value" ], "canonical": "addresses-by-value", "unit": "count", "provisional": false, "quality": "price-dependent", "plain": "Wealthy individuals and small institutions. Unlike the coin thresholds beside it, this line moves when the price moves even if nobody buys or sells a thing.", "technical": "Count of addresses whose balance is worth at least 100,000 at THIS block's price. The threshold in bitcoin moves every block, so it is folded against a live balance histogram rather than filtered.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The threshold lands inside one balance bin (bins are 40 to a decade, so 5.9% wide) and that bin is split linearly in log balance, so the count is exact to well under a bin rather than exact to the coin. It is priced off the same series as tier B, so before 2012 it inherits thin, wide-spread quotes from a handful of exchanges, and coins created before height 68,774 have no price at all and carry a cost basis of zero.", "keywords": [ "addresses holding 100,000", "millionaire addresses", "adoption", "who owns bitcoin", "wealth distribution" ], "seriesEur": "addr_ge_100k_eur", "kind": "stock", "shape": "osc" }, { "slug": "addresses-holding-1m-eur", "series": "addr_ge_1m_usd", "label": "Addresses holding at least 1,000,000 euro", "subtitle": "how many addresses clear 1,000,000 in money", "categories": [ "addresses-by-value" ], "canonical": "addresses-by-value", "unit": "count", "provisional": false, "quality": "price-dependent", "plain": "Millionaire addresses. The headline number the press likes, and the one most distorted by custodians holding for thousands of people at once. Unlike the coin thresholds beside it, this line moves when the price moves even if nobody buys or sells a thing.", "technical": "Count of addresses whose balance is worth at least 1,000,000 at THIS block's price. The threshold in bitcoin moves every block, so it is folded against a live balance histogram rather than filtered.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. The threshold lands inside one balance bin (bins are 40 to a decade, so 5.9% wide) and that bin is split linearly in log balance, so the count is exact to well under a bin rather than exact to the coin. It is priced off the same series as tier B, so before 2012 it inherits thin, wide-spread quotes from a handful of exchanges, and coins created before height 68,774 have no price at all and carry a cost basis of zero.", "keywords": [ "addresses holding 1,000,000", "millionaire addresses", "adoption", "who owns bitcoin", "wealth distribution" ], "seriesEur": "addr_ge_1m_eur", "kind": "stock", "shape": "osc" }, { "slug": "addresses-in-profit", "series": "addr_in_profit", "label": "Addresses in profit", "subtitle": "addresses worth more than they cost", "categories": [ "coins-in-profit" ], "canonical": "coins-in-profit", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many addresses are holding coins worth more than they paid. Counting addresses gives a tiny balance the same weight as a huge one, so this answers \"how many holders are up\" where supply in profit answers \"how much money is up\".", "technical": "Addresses whose average acquisition price is below the current price. Cost basis is specific identification, not average: a spend removes the exact cost of the exact output spent, so an emptied address returns to a cost basis of exactly zero. Read off the same 1,024-bin cost axis tier B uses for supply in profit.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. It is priced off the same series as tier B, so before 2012 it inherits thin, wide-spread quotes from a handful of exchanges, and coins created before height 68,774 have no price at all and carry a cost basis of zero. Addresses built only from pre-2010-07-17 coins carry a zero cost basis and are therefore always counted in profit; `addr_noprice` sizes that group.", "keywords": [ "addresses in profit", "how many holders are up", "am i in profit", "underwater" ], "seriesEur": "addr_in_profit_eur", "kind": "stock", "shape": "osc" }, { "slug": "addresses-in-loss", "series": "addr_in_loss", "label": "Addresses in loss", "subtitle": "addresses worth less than they cost", "categories": [ "coins-in-profit" ], "canonical": "coins-in-profit", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many addresses are holding coins worth less than they paid.", "technical": "Addresses with a balance minus addresses in profit, defined as the residual so that profit plus loss equals the non-zero address count exactly at every height.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. It is priced off the same series as tier B, so before 2012 it inherits thin, wide-spread quotes from a handful of exchanges, and coins created before height 68,774 have no price at all and carry a cost basis of zero.", "keywords": [ "addresses in loss", "underwater", "how many holders are down", "bear market" ], "seriesEur": "addr_in_loss_eur", "kind": "stock", "validFrom": 90080, "shape": "osc" }, { "slug": "addresses-in-profit-share", "series": "addr_profit_pct", "label": "Percent of addresses in profit", "subtitle": "the share of addresses above water", "categories": [ "coins-in-profit" ], "canonical": "coins-in-profit", "unit": "share", "provisional": true, "quality": "reconstruction", "plain": "What share of addresses holding anything are above water. It is the address-weighted twin of supply in profit, and the two disagreeing is informative: it means the money and the holders are not in the same position.", "technical": "Addresses in profit / addresses with a balance.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. It is priced off the same series as tier B, so before 2012 it inherits thin, wide-spread quotes from a handful of exchanges, and coins created before height 68,774 have no price at all and carry a cost basis of zero. Dust addresses dominate the count, so this is much closer to a count of tiny balances above water than to a measure of money in profit; the supply-weighted twin is tier B's supply_profit.", "keywords": [ "percent of addresses in profit", "how many holders are up", "am i in profit", "tops", "capitulation" ], "seriesEur": "addr_profit_pct_eur", "sameAs": [ { "slug": "supply-in-profit-share", "relation": "correlated", "note": "The supply-weighted twin of the same question. They answer it with different denominators and are meant to be read together, not interchangeably." } ], "kind": "stock", "shape": "osc" }, { "slug": "addresses-with-no-cost-basis", "series": "addr_noprice", "label": "Addresses with no cost basis", "subtitle": "addresses that are counted in profit by default", "categories": [ "data-quality" ], "canonical": "data-quality", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many addresses hold coins whose cost can never be known, so they are counted as in profit no matter what the price does. It is published so you can subtract it from the profit split rather than trust it: 95.4% of addresses below block 100,000, still 2.4% at the tip.", "technical": "Addresses holding a positive balance whose entire recorded cost basis is zero, either because their coins were created before a market existed (below height 68,774) or because the priced value rounded below one cent.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. Published so the profit split can be sized rather than trusted.", "keywords": [ "no cost basis", "data quality", "addresses in profit", "satoshi coins", "can i trust this" ], "diagnostic": true, "kind": "stock", "validFrom": 2706, "shape": "osc" }, { "slug": "accumulation-addresses", "series": "addr_accumulation", "label": "Accumulation addresses", "subtitle": "addresses that only ever receive", "categories": [ "accumulation" ], "canonical": "accumulation", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many addresses have received bitcoin more than once and never spent any of it. It is meant to find patient savers, and without an exchange label list it also catches exchange cold storage and miner payout addresses, so it runs far above the version other providers publish.", "technical": "Addresses with at least two received outputs, no spend ever, a positive balance, and a receipt within the last seven years. Glassnode additionally removes exchange and miner addresses BY LABEL. We hold no label list, so this is not a like-for-like series.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. We do not cluster addresses into owners here and we do not use any exchange or miner label list, so nothing on this chart is an entity count. Never-spending is not the same as accumulating: a lost key, a long-dormant exchange cold wallet and a patient saver are the same shape here.", "keywords": [ "accumulation addresses", "are people accumulating", "hodlers", "savers", "cold storage" ], "kind": "stock", "shape": "osc" }, { "slug": "accumulation-supply", "series": "addr_accumulation_balance", "label": "Supply in accumulation addresses", "subtitle": "how much bitcoin sits in never-spending addresses", "categories": [ "accumulation" ], "canonical": "accumulation", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "How much bitcoin sits in addresses that only ever receive. Ours holds 8,470,288 BTC, about 42% of supply, which is far too high to be patient savers alone and is the clearest possible sign that this set contains exchange and custodial storage.", "technical": "Live BTC held by the addresses counted as accumulation addresses.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. We do not cluster addresses into owners here and we do not use any exchange or miner label list, so nothing on this chart is an entity count.", "keywords": [ "accumulation supply", "are people accumulating", "hodlers", "cold storage", "illiquid supply" ], "kind": "stock", "sameAs": [ { "slug": "never-spent-supply", "relation": "definition-variant", "note": "Tier D asks a related question at the entity level with a stricter rule (never spent at all, ever). 14.86M BTC against 8.47M here at the tip, so they are not interchangeable." } ], "shape": "osc" }, { "slug": "accumulation-addresses-ex-coinbase", "series": "addr_accumulation_ex_coinbase", "label": "Accumulation addresses, excluding coinbase recipients", "subtitle": "the only miner exclusion the chain allows", "categories": [ "accumulation" ], "canonical": "accumulation", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "The same count with every address that has ever been paid directly by a miner removed. It is the only miner exclusion derivable from the chain without buying a label list, and it barely moves the number: it removes about 0.02%. That is the honest measure of how far a label-free version can get.", "technical": "Accumulation addresses minus every address that has ever received a coinbase output. A partial exclusion: a pool paying out from a second-hop address is not caught by it.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. We do not cluster addresses into owners here and we do not use any exchange or miner label list, so nothing on this chart is an entity count.", "keywords": [ "accumulation addresses", "miner exclusion", "are people accumulating", "labels" ], "sameAs": [ { "slug": "accumulation-addresses", "relation": "near-duplicate", "note": "The coinbase exclusion removes about 0.02% of the set. Charting both shows how little a label-free miner filter can do." } ], "kind": "stock", "shape": "osc" }, { "slug": "accumulation-supply-ex-coinbase", "series": "addr_accumulation_balance_ex_coinbase", "label": "Supply in accumulation addresses, excluding coinbase recipients", "subtitle": "the same supply with miner-paid addresses removed", "categories": [ "accumulation" ], "canonical": "accumulation", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "The bitcoin held by never-spending addresses, with miner-paid addresses taken out. The gap to the line beside it is how much of the \"accumulation\" pile is traceable to mining, and it is small.", "technical": "Live BTC held by the addresses counted as accumulation addresses excluding coinbase recipients.", "limit": "An address is not a person and not a wallet. One person routinely holds thousands of addresses, one address can hold many people's coins, and ordinary wallet software makes a brand-new change address on almost every spend. So this line moves with wallet behaviour, change outputs, batching and consolidation at least as much as it moves with how many people own bitcoin. Read its direction and its shape; never read the level as a headcount. We do not cluster addresses into owners here and we do not use any exchange or miner label list, so nothing on this chart is an entity count.", "keywords": [ "accumulation supply", "miner exclusion", "hodlers", "cold storage" ], "sameAs": [ { "slug": "accumulation-supply", "relation": "near-duplicate", "note": "The coinbase exclusion removes about 0.02%." } ], "kind": "stock", "shape": "osc" }, { "slug": "coinjoin-transactions", "series": "coinjoin_tx_count", "label": "CoinJoin transactions", "subtitle": "transactions with the fingerprint of a privacy join", "categories": [ "coinjoin-rounds" ], "canonical": "coinjoin-rounds", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many transactions in this block look like a CoinJoin, where several people build one transaction together so that nobody can tell whose coins came out the other side. It is the clearest measure of privacy tooling actually being used.", "technical": "Count of non-coinbase transactions with at least three outputs of exactly equal value. Detection is by SHAPE only, over the evidence log: a transaction with three or more outputs of exactly equal value. It catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds and also the occasional batch payment that happens to pay two people the same amount, PayJoin is invisible to it by construction, and no clustering is involved, so this family carries no entity caveat and every line is a lower bound. These are also exactly the transactions the cluster map refuses to merge on, so this family is the reader's view of how much of the chain the clustering declines to touch.", "limit": "Detection is by SHAPE only. A transaction with three or more outputs of exactly the same value is counted; that catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds, and it also catches the occasional ordinary batch payment that happens to pay two people the same amount. PayJoin is invisible to it by construction, and so is any future design that does not produce equal outputs, so every line here is a LOWER bound. No clustering is involved in this family, so it does not inherit the entity caveat.", "keywords": [ "coinjoin", "privacy", "mixing", "are people using privacy tools", "wasabi", "whirlpool" ], "kind": "flow", "shape": "osc" }, { "slug": "whirlpool-rounds", "series": "coinjoin_whirlpool_count", "label": "Whirlpool rounds", "subtitle": "Samourai Whirlpool, by its exact shape", "categories": [ "coinjoin-rounds" ], "canonical": "coinjoin-rounds", "unit": "count", "provisional": false, "quality": "exact", "plain": "Rounds of Samourai's Whirlpool, the most rigidly shaped mixer on bitcoin: always five people in, five equal outputs out, at one of four fixed sizes. It is a lower bound: a round that does not match the published shape is counted only in the generic CoinJoin line.", "technical": "Exactly five inputs, five outputs, all five outputs equal, and the output value one of the four pool denominations (0.001, 0.01, 0.05 and 0.5 BTC). The tightest detector in the family and therefore the one least likely to catch anything else. Detection is by SHAPE only, over the evidence log: a transaction with three or more outputs of exactly equal value. It catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds and also the occasional batch payment that happens to pay two people the same amount, PayJoin is invisible to it by construction, and no clustering is involved, so this family carries no entity caveat and every line is a lower bound.", "limit": "Detection is by SHAPE only. A transaction with three or more outputs of exactly the same value is counted; that catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds, and it also catches the occasional ordinary batch payment that happens to pay two people the same amount. PayJoin is invisible to it by construction, and so is any future design that does not produce equal outputs, so every line here is a LOWER bound. No clustering is involved in this family, so it does not inherit the entity caveat.", "keywords": [ "coinjoin", "privacy", "mixing", "whirlpool", "are people using privacy tools" ], "kind": "flow", "shape": "osc" }, { "slug": "wasabi-rounds", "series": "coinjoin_wasabi_count", "label": "Wasabi-shaped rounds", "subtitle": "wide rounds with many repeated amounts", "categories": [ "coinjoin-rounds" ], "canonical": "coinjoin-rounds", "unit": "count", "provisional": false, "quality": "exact", "plain": "Rounds with the shape Wasabi and WabiSabi produce: many participants, many outputs, and the same amounts repeated across them. It is a lower bound: a round that does not match the published shape is counted only in the generic CoinJoin line.", "technical": "At least ten outputs, at least five of them equal, and at least five inputs. A shape, not a signature: any other wide mixer producing repeated denominations lands here too. Detection is by SHAPE only, over the evidence log: a transaction with three or more outputs of exactly equal value. It catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds and also the occasional batch payment that happens to pay two people the same amount, PayJoin is invisible to it by construction, and no clustering is involved, so this family carries no entity caveat and every line is a lower bound.", "limit": "Detection is by SHAPE only. A transaction with three or more outputs of exactly the same value is counted; that catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds, and it also catches the occasional ordinary batch payment that happens to pay two people the same amount. PayJoin is invisible to it by construction, and so is any future design that does not produce equal outputs, so every line here is a LOWER bound. No clustering is involved in this family, so it does not inherit the entity caveat.", "keywords": [ "coinjoin", "privacy", "mixing", "wasabi-shaped", "are people using privacy tools" ], "kind": "flow", "shape": "osc" }, { "slug": "joinmarket-rounds", "series": "coinjoin_joinmarket_count", "label": "JoinMarket-shaped rounds", "subtitle": "equal outputs plus one change each", "categories": [ "coinjoin-rounds" ], "canonical": "coinjoin-rounds", "unit": "count", "provisional": false, "quality": "exact", "plain": "Rounds with JoinMarket's shape, where each participant takes one equal output plus their own change, so the transaction has roughly twice as many outputs as it has equal ones. It is a lower bound: a round that does not match the published shape is counted only in the generic CoinJoin line.", "technical": "At least two equal outputs, at least as many inputs as equal outputs, and a total output count between 2k-1 and 2k where k is the number of equal outputs. Detection is by SHAPE only, over the evidence log: a transaction with three or more outputs of exactly equal value. It catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds and also the occasional batch payment that happens to pay two people the same amount, PayJoin is invisible to it by construction, and no clustering is involved, so this family carries no entity caveat and every line is a lower bound.", "limit": "Detection is by SHAPE only. A transaction with three or more outputs of exactly the same value is counted; that catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds, and it also catches the occasional ordinary batch payment that happens to pay two people the same amount. PayJoin is invisible to it by construction, and so is any future design that does not produce equal outputs, so every line here is a LOWER bound. No clustering is involved in this family, so it does not inherit the entity caveat.", "keywords": [ "coinjoin", "privacy", "mixing", "joinmarket-shaped", "are people using privacy tools" ], "kind": "flow", "shape": "osc" }, { "slug": "wide-mix-transactions", "series": "coinjoin_largemix_count", "label": "Wide-in wide-out transactions", "subtitle": "genuinely ambiguous large joins", "categories": [ "coinjoin-rounds" ], "canonical": "coinjoin-rounds", "unit": "count", "provisional": false, "quality": "exact", "plain": "Transactions with twenty or more inputs AND twenty or more outputs. A large privacy round and an exchange consolidating then paying out look identical in this shape, which is why it is published separately rather than folded into the CoinJoin line. It is a lower bound: a round that does not match the published shape is counted only in the generic CoinJoin line.", "technical": "At least 20 inputs, at least 20 outputs and at least 20 distinct input scripts. Flagged in the evidence log rather than refused by policy p1, so these transactions DO contribute co-spend evidence. Detection is by SHAPE only, over the evidence log: a transaction with three or more outputs of exactly equal value. It catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds and also the occasional batch payment that happens to pay two people the same amount, PayJoin is invisible to it by construction, and no clustering is involved, so this family carries no entity caveat and every line is a lower bound.", "limit": "Detection is by SHAPE only. A transaction with three or more outputs of exactly the same value is counted; that catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds, and it also catches the occasional ordinary batch payment that happens to pay two people the same amount. PayJoin is invisible to it by construction, and so is any future design that does not produce equal outputs, so every line here is a LOWER bound. No clustering is involved in this family, so it does not inherit the entity caveat.", "keywords": [ "coinjoin", "privacy", "mixing", "wide-in", "are people using privacy tools" ], "kind": "flow", "shape": "osc" }, { "slug": "coinjoin-volume", "series": "coinjoin_volume", "label": "CoinJoin volume", "subtitle": "how much bitcoin went through privacy joins", "categories": [ "coinjoin-footprint" ], "canonical": "coinjoin-footprint", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "How much bitcoin passed through CoinJoin-shaped transactions in this block. It counts the coins that came out of the join, so a coin mixed twice is counted twice.", "technical": "Total output value of the transactions counted as CoinJoins. Detection is by SHAPE only, over the evidence log: a transaction with three or more outputs of exactly equal value. It catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds and also the occasional batch payment that happens to pay two people the same amount, PayJoin is invisible to it by construction, and no clustering is involved, so this family carries no entity caveat and every line is a lower bound.", "limit": "Detection is by SHAPE only. A transaction with three or more outputs of exactly the same value is counted; that catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds, and it also catches the occasional ordinary batch payment that happens to pay two people the same amount. PayJoin is invisible to it by construction, and so is any future design that does not produce equal outputs, so every line here is a LOWER bound. No clustering is involved in this family, so it does not inherit the entity caveat.", "keywords": [ "coinjoin volume", "privacy", "mixing", "how much is being mixed" ], "kind": "flow", "shape": "osc" }, { "slug": "coinjoin-inputs", "series": "coinjoin_inputs", "label": "CoinJoin inputs", "subtitle": "how many coins went into the joins", "categories": [ "coinjoin-footprint" ], "canonical": "coinjoin-footprint", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many inputs the block's CoinJoin transactions consumed. Read against the output count it shows the shape of the rounds: a mixer that takes five and pays five is doing something different from one that takes fifty and pays a hundred.", "technical": "Sum of the input counts of the transactions counted as CoinJoins. Detection is by SHAPE only, over the evidence log: a transaction with three or more outputs of exactly equal value. It catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds and also the occasional batch payment that happens to pay two people the same amount, PayJoin is invisible to it by construction, and no clustering is involved, so this family carries no entity caveat and every line is a lower bound.", "limit": "Detection is by SHAPE only. A transaction with three or more outputs of exactly the same value is counted; that catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds, and it also catches the occasional ordinary batch payment that happens to pay two people the same amount. PayJoin is invisible to it by construction, and so is any future design that does not produce equal outputs, so every line here is a LOWER bound. No clustering is involved in this family, so it does not inherit the entity caveat.", "keywords": [ "coinjoin inputs", "privacy", "mixing", "participants" ], "kind": "flow", "shape": "osc" }, { "slug": "coinjoin-outputs", "series": "coinjoin_outputs", "label": "CoinJoin outputs", "subtitle": "how many coins came out of the joins", "categories": [ "coinjoin-footprint" ], "canonical": "coinjoin-footprint", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many outputs the block's CoinJoin transactions created. Each one is a chunk of bitcoin whose history is now harder to follow.", "technical": "Sum of the output counts of the transactions counted as CoinJoins. Detection is by SHAPE only, over the evidence log: a transaction with three or more outputs of exactly equal value. It catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds and also the occasional batch payment that happens to pay two people the same amount, PayJoin is invisible to it by construction, and no clustering is involved, so this family carries no entity caveat and every line is a lower bound.", "limit": "Detection is by SHAPE only. A transaction with three or more outputs of exactly the same value is counted; that catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds, and it also catches the occasional ordinary batch payment that happens to pay two people the same amount. PayJoin is invisible to it by construction, and so is any future design that does not produce equal outputs, so every line here is a LOWER bound. No clustering is involved in this family, so it does not inherit the entity caveat.", "keywords": [ "coinjoin outputs", "privacy", "mixing", "utxos" ], "kind": "flow", "shape": "osc" }, { "slug": "coinjoin-transaction-share", "series": "coinjoin_tx_share", "label": "CoinJoin share of transactions", "subtitle": "what fraction of the block was a privacy join", "categories": [ "coinjoin-footprint" ], "canonical": "coinjoin-footprint", "unit": "share", "provisional": false, "quality": "exact", "plain": "What share of the block's transactions look like a privacy join. This is the honest headline for \"how much of bitcoin is being mixed\", and it is small.", "technical": "CoinJoin transactions over non-coinbase transactions in the same block. Detection is by SHAPE only, over the evidence log: a transaction with three or more outputs of exactly equal value. It catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds and also the occasional batch payment that happens to pay two people the same amount, PayJoin is invisible to it by construction, and no clustering is involved, so this family carries no entity caveat and every line is a lower bound.", "limit": "Detection is by SHAPE only. A transaction with three or more outputs of exactly the same value is counted; that catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds, and it also catches the occasional ordinary batch payment that happens to pay two people the same amount. PayJoin is invisible to it by construction, and so is any future design that does not produce equal outputs, so every line here is a LOWER bound. No clustering is involved in this family, so it does not inherit the entity caveat.", "keywords": [ "coinjoin share", "privacy", "how much of bitcoin is mixed", "mixing" ], "kind": "flow", "shape": "osc" }, { "slug": "coinjoin-volume-share", "series": "coinjoin_volume_share", "label": "CoinJoin share of value", "subtitle": "what fraction of the money moved was mixed", "categories": [ "coinjoin-footprint" ], "canonical": "coinjoin-footprint", "unit": "share", "provisional": false, "quality": "exact", "plain": "What share of the value moved in this block passed through a privacy join. It runs well above the transaction share, because joins are large transactions.", "technical": "CoinJoin output value over total non-coinbase output value in the same block. Detection is by SHAPE only, over the evidence log: a transaction with three or more outputs of exactly equal value. It catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds and also the occasional batch payment that happens to pay two people the same amount, PayJoin is invisible to it by construction, and no clustering is involved, so this family carries no entity caveat and every line is a lower bound.", "limit": "Detection is by SHAPE only. A transaction with three or more outputs of exactly the same value is counted; that catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds, and it also catches the occasional ordinary batch payment that happens to pay two people the same amount. PayJoin is invisible to it by construction, and so is any future design that does not produce equal outputs, so every line here is a LOWER bound. No clustering is involved in this family, so it does not inherit the entity caveat.", "keywords": [ "coinjoin share of volume", "privacy", "mixing", "how much money is mixed" ], "kind": "flow", "shape": "osc" }, { "slug": "coinjoin-blockspace-share", "series": "coinjoin_vsize_share", "label": "CoinJoin share of blockspace", "subtitle": "what fraction of the block privacy joins bought", "categories": [ "coinjoin-footprint" ], "canonical": "coinjoin-footprint", "unit": "share", "provisional": false, "quality": "exact", "plain": "What share of the block's space privacy joins took up. Joins are big transactions with many inputs and many outputs, so they buy more blockspace than their headcount suggests.", "technical": "CoinJoin virtual size over total non-coinbase virtual size in the same block. Detection is by SHAPE only, over the evidence log: a transaction with three or more outputs of exactly equal value. It catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds and also the occasional batch payment that happens to pay two people the same amount, PayJoin is invisible to it by construction, and no clustering is involved, so this family carries no entity caveat and every line is a lower bound.", "limit": "Detection is by SHAPE only. A transaction with three or more outputs of exactly the same value is counted; that catches Wasabi, Whirlpool, JoinMarket and WabiSabi rounds, and it also catches the occasional ordinary batch payment that happens to pay two people the same amount. PayJoin is invisible to it by construction, and so is any future design that does not produce equal outputs, so every line here is a LOWER bound. No clustering is involved in this family, so it does not inherit the entity caveat.", "keywords": [ "coinjoin blockspace", "privacy", "mixing", "what is the block used for" ], "sameAs": [ { "slug": "coinjoin-shaped-weight-share", "relation": "near-duplicate", "note": "Tier B publishes the same detector measured in WEIGHT units over the whole block, this one is in VIRTUAL SIZE over the block's non-coinbase transactions. Same transactions, two denominators: read one or the other, not both as evidence." } ], "kind": "flow", "shape": "osc" }, { "slug": "transfer-volume", "series": "xfer_volume", "label": "Transfer volume", "subtitle": "every coin that moved, change included", "categories": [ "transfer-volume" ], "canonical": "transfer-volume", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Every bitcoin that moved in this block, with nothing taken out. Most of it never changed owner: it is change coming back to the sender, exchanges rotating their own storage, and wallets tidying up. It is the ceiling of the three lines here, not the answer.", "technical": "Total non-coinbase output value per block. Coinbase is excluded throughout tier D, because issuance is not a transfer and a coinbase transaction has no input entity.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence here is MODERATE. The correction is real and large, but how much of it is right depends on the cluster map. The change-adjusted line beside it uses no clustering at all (an output is only dropped if its own address was also an input), so the gap between the two is exactly how much of the correction our heuristic is responsible for. If you distrust the clustering, read the change-adjusted line as the floor and the unadjusted line as the ceiling.", "keywords": [ "transfer volume", "how much bitcoin moved", "on chain volume", "transaction volume" ], "kind": "flow", "validFrom": 199590, "shape": "osc" }, { "slug": "transfer-volume-change-adjusted", "series": "xfer_volume_change_adj", "label": "Transfer volume, change-adjusted", "subtitle": "with obvious change removed, no guessing involved", "categories": [ "transfer-volume" ], "canonical": "transfer-volume", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "The same volume with the most obvious self-payments removed: outputs that went straight back to an address the transaction had just spent from. This needs no clustering and no heuristic that can be wrong, so it is the line to trust if you distrust the entity guess. Treat it as the floor.", "technical": "Output value where the output's own script was not also one of the transaction's input scripts. Address reuse only, so it catches nothing that a fresh change address hides.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence here is MODERATE. The correction is real and large, but how much of it is right depends on the cluster map. The change-adjusted line beside it uses no clustering at all (an output is only dropped if its own address was also an input), so the gap between the two is exactly how much of the correction our heuristic is responsible for. If you distrust the clustering, read the change-adjusted line as the floor and the unadjusted line as the ceiling.", "keywords": [ "change adjusted volume", "real volume", "how much bitcoin moved", "self transfer" ], "kind": "flow", "validFrom": 199618, "shape": "osc" }, { "slug": "transfer-volume-entity-adjusted", "series": "xfer_volume_entity_adj", "label": "Transfer volume, entity-adjusted", "subtitle": "value that reached somebody else", "categories": [ "transfer-volume" ], "canonical": "transfer-volume", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "The bitcoin that actually reached a different owner, with every payment we can see going back to the sender taken out. This is the number Glassnode calls entity-adjusted transfer volume, and it is the closest this page gets to \"how much money changed hands\".", "technical": "Output value landing on an entity that was not already an input entity of the same transaction. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence here is MODERATE. The correction is real and large, but how much of it is right depends on the cluster map. The change-adjusted line beside it uses no clustering at all (an output is only dropped if its own address was also an input), so the gap between the two is exactly how much of the correction our heuristic is responsible for. If you distrust the clustering, read the change-adjusted line as the floor and the unadjusted line as the ceiling.", "keywords": [ "entity adjusted volume", "real volume", "how much money changed hands", "glassnode" ], "sameAs": [ { "slug": "transfer-volume-change-adjusted", "relation": "definition-variant", "note": "The change-adjusted line uses no clustering at all, so the gap between the two is exactly how much of the correction our own heuristic is responsible for. Floor and estimate, not two independent measurements." } ], "kind": "flow", "validFrom": 199621, "shape": "osc" }, { "slug": "self-transfer-volume", "series": "self_transfer_volume", "label": "Self-transfer volume", "subtitle": "the value that never left its owner", "categories": [ "transfer-volume" ], "canonical": "transfer-volume", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "The bitcoin that moved without changing owner: change, consolidation and exchanges shuffling their own coins. It is usually most of the raw volume, which is the single most useful thing to know about on-chain volume figures.", "technical": "Transfer volume minus entity-adjusted transfer volume, so it is the residual rather than an independent measurement. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence here is MODERATE. The correction is real and large, but how much of it is right depends on the cluster map. The change-adjusted line beside it uses no clustering at all (an output is only dropped if its own address was also an input), so the gap between the two is exactly how much of the correction our heuristic is responsible for. If you distrust the clustering, read the change-adjusted line as the floor and the unadjusted line as the ceiling.", "keywords": [ "self transfer", "change outputs", "consolidation", "real volume", "how much bitcoin moved" ], "sameAs": [ { "slug": "transfer-volume-entity-adjusted", "relation": "algebraic-identity", "note": "This IS transfer volume minus the entity-adjusted line. Charting both plus the unadjusted line shows one number three ways." } ], "kind": "flow", "shape": "osc" }, { "slug": "entity-adjusted-share-of-volume", "series": "entity_adj_volume_ratio", "label": "Entity-adjusted share of volume", "subtitle": "how much of the raw volume survives the correction", "categories": [ "size-of-the-correction" ], "canonical": "size-of-the-correction", "unit": "share", "provisional": true, "quality": "reconstruction", "plain": "How much of the raw volume is left once self-payments are removed. This is the chart that shows the size of the correction rather than asking you to eyeball two lines, and it is the reason nobody should quote raw on-chain volume.", "technical": "Entity-adjusted transfer volume over transfer volume. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence here is MODERATE. The correction is real and large, but how much of it is right depends on the cluster map. The change-adjusted line beside it uses no clustering at all (an output is only dropped if its own address was also an input), so the gap between the two is exactly how much of the correction our heuristic is responsible for. If you distrust the clustering, read the change-adjusted line as the floor and the unadjusted line as the ceiling.", "keywords": [ "how much volume is real", "entity adjusted", "self transfer", "volume correction" ], "kind": "flow", "shape": "osc" }, { "slug": "change-adjusted-share-of-volume", "series": "change_adj_volume_ratio", "label": "Change-adjusted share of volume", "subtitle": "the same correction, without any clustering", "categories": [ "size-of-the-correction" ], "canonical": "size-of-the-correction", "unit": "share", "provisional": false, "quality": "exact", "plain": "The same measure of the correction, computed without any clustering at all. Where this line and the entity-adjusted one beside it agree, the correction owes nothing to our guesswork.", "technical": "Change-adjusted transfer volume over transfer volume. Address reuse only, no clustering.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence here is MODERATE. The correction is real and large, but how much of it is right depends on the cluster map. The change-adjusted line beside it uses no clustering at all (an output is only dropped if its own address was also an input), so the gap between the two is exactly how much of the correction our heuristic is responsible for. If you distrust the clustering, read the change-adjusted line as the floor and the unadjusted line as the ceiling.", "keywords": [ "change adjusted", "how much volume is real", "volume correction", "self transfer" ], "sameAs": [ { "slug": "entity-adjusted-share-of-volume", "relation": "definition-variant", "note": "The same ratio with a weaker, safer numerator. The gap between them is the clustering's contribution and nothing else." } ], "kind": "flow", "shape": "osc" }, { "slug": "transactions-non-coinbase", "series": "xfer_tx_count", "label": "Transactions, non-coinbase", "subtitle": "the block's transactions with the coinbase left out", "categories": [ "real-transactions" ], "canonical": "real-transactions", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many real transactions the block carried, not counting the coinbase transaction that pays the miner. It is the denominator the two entity-adjusted lines beside it are measured against.", "technical": "Non-coinbase transaction count per block.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence MODERATE, same basis as the volume family. A transaction counted as self-only here is one where every output landed back on an entity that was spending in it; consolidations dominate that line.", "keywords": [ "transactions", "transaction count", "how busy is bitcoin", "network usage" ], "sameAs": [ { "slug": "transactions-per-block", "relation": "definition-variant", "note": "Tier A's transaction count includes the coinbase transaction, this one does not. The difference is exactly one per block." } ], "kind": "flow", "shape": "osc" }, { "slug": "transactions-entity-adjusted", "series": "xfer_tx_count_entity_adj", "label": "Transactions, entity-adjusted", "subtitle": "transactions that actually paid someone else", "categories": [ "real-transactions" ], "canonical": "real-transactions", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many of the block's transactions moved bitcoin to a different owner. The rest are people moving coins between their own addresses, which the raw transaction count cannot tell apart.", "technical": "Non-coinbase transactions with at least one output landing on an entity that was not already an input entity of the same transaction. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence MODERATE, same basis as the volume family. A transaction counted as self-only here is one where every output landed back on an entity that was spending in it; consolidations dominate that line.", "keywords": [ "real transactions", "entity adjusted", "how busy is bitcoin", "payments" ], "kind": "flow", "shape": "osc" }, { "slug": "self-transfer-transactions", "series": "self_tx_count", "label": "Self-transfer transactions", "subtitle": "transactions that only moved coins within one wallet", "categories": [ "real-transactions" ], "canonical": "real-transactions", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many transactions in the block only moved coins between addresses belonging to the same owner: consolidations, wallet migrations and exchanges rotating storage.", "technical": "Non-coinbase transactions minus entity-adjusted transactions, so it is the residual. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence MODERATE, same basis as the volume family. A transaction counted as self-only here is one where every output landed back on an entity that was spending in it; consolidations dominate that line.", "keywords": [ "self transfer", "consolidation", "wallet shuffling", "real transactions" ], "sameAs": [ { "slug": "transactions-entity-adjusted", "relation": "algebraic-identity", "note": "This IS the non-coinbase count minus the entity-adjusted count." } ], "kind": "flow", "shape": "trend" }, { "slug": "entity-adjusted-share-of-transactions", "series": "entity_adj_tx_ratio", "label": "Entity-adjusted share of transactions", "subtitle": "how many transactions survive the correction", "categories": [ "size-of-the-correction" ], "canonical": "size-of-the-correction", "unit": "share", "provisional": true, "quality": "reconstruction", "plain": "What share of transactions actually paid somebody else. Read beside the volume version: when the two disagree, the self-shuffling is concentrated in either the big transactions or the small ones.", "technical": "Entity-adjusted transactions over non-coinbase transactions. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence MODERATE, same basis as the volume family. A transaction counted as self-only here is one where every output landed back on an entity that was spending in it; consolidations dominate that line.", "keywords": [ "how many transactions are real", "entity adjusted", "payments", "network usage" ], "kind": "flow", "shape": "osc" }, { "slug": "outputs-non-coinbase", "series": "xfer_outputs", "label": "Outputs, non-coinbase", "subtitle": "chunks of bitcoin created, coinbase aside", "categories": [ "real-transactions" ], "canonical": "real-transactions", "unit": "count", "provisional": false, "quality": "exact", "plain": "How many outputs the block created, not counting the miner's own payment. It is the denominator for the line beside it.", "technical": "Non-coinbase output count per block, with zero-value data outputs already dropped: they are data carriers and would invent entities that hold nothing.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence MODERATE, same basis as the volume family. A transaction counted as self-only here is one where every output landed back on an entity that was spending in it; consolidations dominate that line.", "keywords": [ "outputs", "utxos created", "network usage" ], "sameAs": [ { "slug": "created-outputs", "relation": "definition-variant", "note": "Tier A counts every output created including the coinbase's and including zero-value data outputs, this one counts neither." } ], "kind": "flow", "shape": "osc" }, { "slug": "outputs-to-another-entity", "series": "xfer_outputs_entity_adj", "label": "Outputs to another entity", "subtitle": "chunks of bitcoin that reached someone else", "categories": [ "real-transactions" ], "canonical": "real-transactions", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many of the block's outputs actually paid a different owner. The gap to the line beside it is the change output, the single most common thing on the bitcoin blockchain.", "technical": "Non-coinbase outputs landing on an entity that was not already an input entity of the same transaction. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence MODERATE, same basis as the volume family. A transaction counted as self-only here is one where every output landed back on an entity that was spending in it; consolidations dominate that line.", "keywords": [ "real outputs", "change outputs", "entity adjusted", "payments" ], "kind": "flow", "shape": "osc" }, { "slug": "active-entities", "series": "active_entities", "label": "Active entities", "subtitle": "owners doing something in this block", "categories": [ "how-many-owners" ], "canonical": "how-many-owners", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many separate owners appear in this block, on either side of a transaction. It is the address count with co-spending folded in, so it is the closer of the two to a headcount of people, and it is still not one.", "technical": "Distinct entities appearing as an input or an output entity of a transaction in this block. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence MODERATE-TO-LOW for the LEVEL and higher for the SHAPE. Under-merging inflates every count here: two addresses we failed to join are counted as two entities. Read the trend, not the absolute number, and read it beside tier C's address counts, which are exact.", "keywords": [ "active entities", "active users", "how busy is bitcoin", "how many people use bitcoin", "adoption" ], "sameAs": [ { "slug": "active-addresses", "relation": "near-duplicate", "note": "The tier C address twin of this line, which is EXACT where this one is inferred. At block 961,000 this reads 8,120 against 11,685 active addresses. The fold only ever removes, never adds, so the entity line sits below the address line everywhere." } ], "kind": "flow", "shape": "osc" }, { "slug": "sending-entities", "series": "sending_entities", "label": "Sending entities", "subtitle": "owners who spent in this block", "categories": [ "how-many-owners" ], "canonical": "how-many-owners", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many owners spent bitcoin in this block. Against receiving entities it shows the shape of the traffic: few senders and many receivers is one exchange paying a lot of people.", "technical": "Distinct entities that had an output spent in this block. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence MODERATE-TO-LOW for the LEVEL and higher for the SHAPE. Under-merging inflates every count here: two addresses we failed to join are counted as two entities. Read the trend, not the absolute number, and read it beside tier C's address counts, which are exact.", "keywords": [ "sending entities", "spenders", "are holders selling", "network usage" ], "sameAs": [ { "slug": "sending-addresses", "relation": "near-duplicate", "note": "The tier C address twin of this line, which is EXACT where this one is inferred. At block 961,000 this reads 3,207 against 4,845 sending addresses, the same fold applied to the sending side." } ], "kind": "flow", "shape": "osc" }, { "slug": "receiving-entities", "series": "receiving_entities", "label": "Receiving entities", "subtitle": "owners who were paid in this block", "categories": [ "how-many-owners" ], "canonical": "how-many-owners", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many owners received bitcoin in this block.", "technical": "Distinct entities that received an output in this block. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence MODERATE-TO-LOW for the LEVEL and higher for the SHAPE. Under-merging inflates every count here: two addresses we failed to join are counted as two entities. Read the trend, not the absolute number, and read it beside tier C's address counts, which are exact.", "keywords": [ "receiving entities", "payments", "network usage", "adoption" ], "sameAs": [ { "slug": "receiving-addresses", "relation": "near-duplicate", "note": "The tier C address twin of this line, which is EXACT where this one is inferred. At block 961,000 this reads 6,436 against 8,403 receiving addresses." } ], "kind": "flow", "shape": "osc" }, { "slug": "new-entities", "series": "new_entities", "label": "New entities", "subtitle": "owners seen for the first time ever", "categories": [ "how-many-owners" ], "canonical": "how-many-owners", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many owners received bitcoin for the very first time in this block. It is the least bad adoption proxy on the page, and it is still mostly wallets making new addresses.", "technical": "Entities receiving value for the first time, per block. A birth stays where it was: if the cluster is later merged into another one, this series is not re-derived. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence MODERATE-TO-LOW on the level. A new entity here is the first time a cluster we know about receives value; if we later merge that cluster into another one, the birth stays where it was. The series is therefore a count of first appearances under the map as it stands, not a re-derived history.", "keywords": [ "new entities", "adoption", "growth", "how many people own bitcoin" ], "sameAs": [ { "slug": "new-addresses", "relation": "near-duplicate", "note": "The tier C address twin of this line, which is EXACT where this one is inferred. At block 961,000 this reads 3,584 against 3,633 new addresses, a fold of barely 1%: a brand-new script has usually not been co-spent with anything yet, so it has nothing to be folded into." } ], "kind": "flow", "shape": "osc" }, { "slug": "entities-ever-seen", "series": "entity_count", "label": "Entities ever seen", "subtitle": "the running total of owners, which only goes up", "categories": [ "how-many-owners" ], "canonical": "how-many-owners", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "Every owner that has ever received bitcoin, added up. It only goes up, including for owners who emptied out years ago.", "technical": "Cumulative count of clusters that have received value at least once. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence MODERATE-TO-LOW on the level. A new entity here is the first time a cluster we know about receives value; if we later merge that cluster into another one, the birth stays where it was. The series is therefore a count of first appearances under the map as it stands, not a re-derived history.", "keywords": [ "entities", "total owners", "adoption", "growth", "how many people own bitcoin" ], "sameAs": [ { "slug": "addresses-ever-seen", "relation": "near-duplicate", "note": "The address twin, which is exact. At the tip this reads 717.7M entities against 1.536B addresses: co-spending accounts for 818M merges, and that difference IS the clustering." } ], "kind": "stock", "validFrom": 531, "shape": "trend" }, { "slug": "entities-with-a-balance", "series": "entities_nonzero", "label": "Entities with a balance", "subtitle": "how many owners hold anything", "categories": [ "how-many-owners" ], "canonical": "how-many-owners", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many separate owners hold any bitcoin at all. It is the nearest thing on this page to a count of holders, and it is still an inference, not a headcount.", "technical": "Entities with a strictly positive balance at this height. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence MODERATE-TO-LOW on the level. A new entity here is the first time a cluster we know about receives value; if we later merge that cluster into another one, the birth stays where it was. The series is therefore a count of first appearances under the map as it stands, not a re-derived history.", "keywords": [ "entities with a balance", "holders", "how many people own bitcoin", "adoption", "owners" ], "sameAs": [ { "slug": "addresses-with-a-balance", "relation": "near-duplicate", "note": "The address twin, which is exact. At the tip this reads 56.42M entities against 59.29M addresses, 4.8% lower: clustering barely moves this number because most held scripts have never been co-spent." } ], "kind": "stock", "validFrom": 985, "shape": "trend" }, { "slug": "supply-held-by-entities", "series": "entity_supply_total", "label": "Supply held by entities", "subtitle": "the identity check on the whole tier", "categories": [ "how-many-owners" ], "canonical": "how-many-owners", "unit": "BTC", "provisional": false, "quality": "exact", "plain": "Every entity balance added up. It exists to be checked rather than read: it must equal circulating supply at every height, and if it ever does not, something in the clustering has lost or invented coins.", "technical": "Sum of every entity balance. Verified equal to tier A supply at the tip: both read 20,065,599.16655096 BTC at block 961,000.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence MODERATE-TO-LOW on the level. A new entity here is the first time a cluster we know about receives value; if we later merge that cluster into another one, the birth stays where it was. The series is therefore a count of first appearances under the map as it stands, not a re-derived history.", "keywords": [ "entity supply", "identity check", "data quality", "total supply" ], "sameAs": [ { "slug": "circulating-supply", "relation": "algebraic-identity", "note": "It must equal circulating supply at every height. It is published so the identity can be checked on the chart rather than trusted." } ], "kind": "stock", "validFrom": 3851, "shape": "trend" }, { "slug": "supply-in-entities-under-0p001", "series": "entity_supply_band_0_001", "label": "Supply held by entities of under 0.001 BTC", "subtitle": "bitcoin held by owners holding under 0.001 BTC", "categories": [ "supply-by-owner-size" ], "canonical": "supply-by-owner-size", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "Dust: balances too small to spend economically at most fee levels. Enormous in owner count and negligible in coins.", "technical": "Live BTC held by entities whose total balance falls under 0.001 BTC at this height, summed across every address the entity owns. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "supply by owner size", "whale", "distribution", "who owns bitcoin", "rich list", "under 0.001 BTC" ], "sameAs": [ { "slug": "supply-in-addresses-under-0p001", "relation": "near-duplicate", "note": "Tier C publishes the same band over ADDRESSES, and the two are meant to be read together rather than counted twice: clustering reaches only 7.24% of supply, so the entity line is the address line with a small correction. Measured at the tip, the gap is +1.1%. Under-merging pushes coins DOWN the ladder, so the large bands are understated and the middle bands overstated." } ], "kind": "stock", "shape": "osc" }, { "slug": "entities-holding-under-0p001", "series": "entity_count_band_0_001", "label": "Entities holding under 0.001 BTC", "subtitle": "how many owners hold under 0.001 BTC", "categories": [ "owners-by-balance" ], "canonical": "owners-by-balance", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "Dust: balances too small to spend economically at most fee levels. This line counts the owners in the band rather than the coins.", "technical": "Count of entities whose total balance falls under 0.001 BTC at this height. Tier C's address family publishes CUMULATIVE counts above a threshold rather than per band, so this series has no address twin to double-count against. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "owners by balance", "how many whales", "distribution", "who owns bitcoin", "rich list", "under 0.001 BTC" ], "kind": "stock", "shape": "trend" }, { "slug": "supply-in-entities-0p001-0p01", "series": "entity_supply_band_0_01", "label": "Supply held by entities of 0.001 to 0.01 BTC", "subtitle": "bitcoin held by owners holding between 0.001 and 0.01 BTC", "categories": [ "supply-by-owner-size" ], "canonical": "supply-by-owner-size", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "Small change, much of it the residue of old payments rather than anyone's savings.", "technical": "Live BTC held by entities whose total balance falls between 0.001 and 0.01 BTC at this height, summed across every address the entity owns. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "supply by owner size", "whale", "distribution", "who owns bitcoin", "rich list", "0.001 to 0.01 BTC" ], "sameAs": [ { "slug": "supply-in-addresses-0p001-0p01", "relation": "near-duplicate", "note": "Tier C publishes the same band over ADDRESSES, and the two are meant to be read together rather than counted twice: clustering reaches only 7.24% of supply, so the entity line is the address line with a small correction. Measured at the tip, the gap is +2.1%. Under-merging pushes coins DOWN the ladder, so the large bands are understated and the middle bands overstated." } ], "kind": "stock", "shape": "osc" }, { "slug": "entities-holding-0p001-0p01", "series": "entity_count_band_0_01", "label": "Entities holding 0.001 to 0.01 BTC", "subtitle": "how many owners hold between 0.001 and 0.01 BTC", "categories": [ "owners-by-balance" ], "canonical": "owners-by-balance", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "Small change, much of it the residue of old payments rather than anyone's savings. This line counts the owners in the band rather than the coins.", "technical": "Count of entities whose total balance falls between 0.001 and 0.01 BTC at this height. Tier C's address family publishes CUMULATIVE counts above a threshold rather than per band, so this series has no address twin to double-count against. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "owners by balance", "how many whales", "distribution", "who owns bitcoin", "rich list", "0.001 to 0.01 BTC" ], "kind": "stock", "shape": "osc" }, { "slug": "supply-in-entities-0p01-0p1", "series": "entity_supply_band_0_1", "label": "Supply held by entities of 0.01 to 0.1 BTC", "subtitle": "bitcoin held by owners holding between 0.01 and 0.1 BTC", "categories": [ "supply-by-owner-size" ], "canonical": "supply-by-owner-size", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "Where retail saving starts to be visible: a few hundred to a few thousand euro at recent prices.", "technical": "Live BTC held by entities whose total balance falls between 0.01 and 0.1 BTC at this height, summed across every address the entity owns. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "supply by owner size", "whale", "distribution", "who owns bitcoin", "rich list", "0.01 to 0.1 BTC" ], "sameAs": [ { "slug": "supply-in-addresses-0p01-0p1", "relation": "near-duplicate", "note": "Tier C publishes the same band over ADDRESSES, and the two are meant to be read together rather than counted twice: clustering reaches only 7.24% of supply, so the entity line is the address line with a small correction. Measured at the tip, the gap is +2.3%. Under-merging pushes coins DOWN the ladder, so the large bands are understated and the middle bands overstated." } ], "kind": "stock", "shape": "osc" }, { "slug": "entities-holding-0p01-0p1", "series": "entity_count_band_0_1", "label": "Entities holding 0.01 to 0.1 BTC", "subtitle": "how many owners hold between 0.01 and 0.1 BTC", "categories": [ "owners-by-balance" ], "canonical": "owners-by-balance", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "Where retail saving starts to be visible: a few hundred to a few thousand euro at recent prices. This line counts the owners in the band rather than the coins.", "technical": "Count of entities whose total balance falls between 0.01 and 0.1 BTC at this height. Tier C's address family publishes CUMULATIVE counts above a threshold rather than per band, so this series has no address twin to double-count against. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "owners by balance", "how many whales", "distribution", "who owns bitcoin", "rich list", "0.01 to 0.1 BTC" ], "kind": "stock", "shape": "osc" }, { "slug": "supply-in-entities-0p1-1", "series": "entity_supply_band_1", "label": "Supply held by entities of 0.1 to 1 BTC", "subtitle": "bitcoin held by owners holding between 0.1 and 1 BTC", "categories": [ "supply-by-owner-size" ], "canonical": "supply-by-owner-size", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "Sub-wholecoiner savers, and the band the clustering moves most: folding change addresses together lifts owners out of the dust bands and into this one.", "technical": "Live BTC held by entities whose total balance falls between 0.1 and 1 BTC at this height, summed across every address the entity owns. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "supply by owner size", "whale", "distribution", "who owns bitcoin", "rich list", "0.1 to 1 BTC" ], "sameAs": [ { "slug": "supply-in-addresses-0p1-1", "relation": "near-duplicate", "note": "Tier C publishes the same band over ADDRESSES, and the two are meant to be read together rather than counted twice: clustering reaches only 7.24% of supply, so the entity line is the address line with a small correction. Measured at the tip, the gap is +5.5%. Under-merging pushes coins DOWN the ladder, so the large bands are understated and the middle bands overstated." } ], "kind": "stock", "shape": "osc" }, { "slug": "entities-holding-0p1-1", "series": "entity_count_band_1", "label": "Entities holding 0.1 to 1 BTC", "subtitle": "how many owners hold between 0.1 and 1 BTC", "categories": [ "owners-by-balance" ], "canonical": "owners-by-balance", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "Sub-wholecoiner savers, and the band the clustering moves most: folding change addresses together lifts owners out of the dust bands and into this one. This line counts the owners in the band rather than the coins.", "technical": "Count of entities whose total balance falls between 0.1 and 1 BTC at this height. Tier C's address family publishes CUMULATIVE counts above a threshold rather than per band, so this series has no address twin to double-count against. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "owners by balance", "how many whales", "distribution", "who owns bitcoin", "rich list", "0.1 to 1 BTC" ], "kind": "stock", "shape": "osc" }, { "slug": "supply-in-entities-1-10", "series": "entity_supply_band_10", "label": "Supply held by entities of 1 to 10 BTC", "subtitle": "bitcoin held by owners holding between 1 and 10 BTC", "categories": [ "supply-by-owner-size" ], "canonical": "supply-by-owner-size", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "Wholecoiners and small stackers, counted as owners rather than as addresses.", "technical": "Live BTC held by entities whose total balance falls between 1 and 10 BTC at this height, summed across every address the entity owns. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "supply by owner size", "whale", "distribution", "who owns bitcoin", "rich list", "1 to 10 BTC" ], "sameAs": [ { "slug": "supply-in-addresses-1-10", "relation": "near-duplicate", "note": "Tier C publishes the same band over ADDRESSES, and the two are meant to be read together rather than counted twice: clustering reaches only 7.24% of supply, so the entity line is the address line with a small correction. Measured at the tip, the gap is -3.0%. Under-merging pushes coins DOWN the ladder, so the large bands are understated and the middle bands overstated." } ], "kind": "stock", "shape": "osc" }, { "slug": "entities-holding-1-10", "series": "entity_count_band_10", "label": "Entities holding 1 to 10 BTC", "subtitle": "how many owners hold between 1 and 10 BTC", "categories": [ "owners-by-balance" ], "canonical": "owners-by-balance", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "Wholecoiners and small stackers, counted as owners rather than as addresses. This line counts the owners in the band rather than the coins.", "technical": "Count of entities whose total balance falls between 1 and 10 BTC at this height. Tier C's address family publishes CUMULATIVE counts above a threshold rather than per band, so this series has no address twin to double-count against. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "owners by balance", "how many whales", "distribution", "who owns bitcoin", "rich list", "1 to 10 BTC" ], "kind": "stock", "shape": "osc" }, { "slug": "supply-in-entities-10-100", "series": "entity_supply_band_100", "label": "Supply held by entities of 10 to 100 BTC", "subtitle": "bitcoin held by owners holding between 10 and 100 BTC", "categories": [ "supply-by-owner-size" ], "canonical": "supply-by-owner-size", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "Serious individual and small-fund money.", "technical": "Live BTC held by entities whose total balance falls between 10 and 100 BTC at this height, summed across every address the entity owns. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "supply by owner size", "whale", "distribution", "who owns bitcoin", "rich list", "10 to 100 BTC" ], "sameAs": [ { "slug": "supply-in-addresses-10-100", "relation": "near-duplicate", "note": "Tier C publishes the same band over ADDRESSES, and the two are meant to be read together rather than counted twice: clustering reaches only 7.24% of supply, so the entity line is the address line with a small correction. Measured at the tip, the gap is -0.3%. Under-merging pushes coins DOWN the ladder, so the large bands are understated and the middle bands overstated." } ], "kind": "stock", "validFrom": 5239, "shape": "osc" }, { "slug": "entities-holding-10-100", "series": "entity_count_band_100", "label": "Entities holding 10 to 100 BTC", "subtitle": "how many owners hold between 10 and 100 BTC", "categories": [ "owners-by-balance" ], "canonical": "owners-by-balance", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "Serious individual and small-fund money. This line counts the owners in the band rather than the coins.", "technical": "Count of entities whose total balance falls between 10 and 100 BTC at this height. Tier C's address family publishes CUMULATIVE counts above a threshold rather than per band, so this series has no address twin to double-count against. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "owners by balance", "how many whales", "distribution", "who owns bitcoin", "rich list", "10 to 100 BTC" ], "kind": "stock", "validFrom": 4713, "shape": "osc" }, { "slug": "supply-in-entities-100-1k", "series": "entity_supply_band_1k", "label": "Supply held by entities of 100 to 1,000 BTC", "subtitle": "bitcoin held by owners holding between 100 and 1,000 BTC", "categories": [ "supply-by-owner-size" ], "canonical": "supply-by-owner-size", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "Where individual owners end and desks, funds and exchange hot wallets begin. Nothing in the data says which of those a given entity is.", "technical": "Live BTC held by entities whose total balance falls between 100 and 1,000 BTC at this height, summed across every address the entity owns. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "supply by owner size", "whale", "distribution", "who owns bitcoin", "rich list", "100 to 1,000 BTC" ], "sameAs": [ { "slug": "supply-in-addresses-100-1k", "relation": "near-duplicate", "note": "Tier C publishes the same band over ADDRESSES, and the two are meant to be read together rather than counted twice: clustering reaches only 7.24% of supply, so the entity line is the address line with a small correction. Measured at the tip, the gap is -1.1%. Under-merging pushes coins DOWN the ladder, so the large bands are understated and the middle bands overstated." } ], "kind": "stock", "shape": "osc" }, { "slug": "entities-holding-100-1k", "series": "entity_count_band_1k", "label": "Entities holding 100 to 1,000 BTC", "subtitle": "how many owners hold between 100 and 1,000 BTC", "categories": [ "owners-by-balance" ], "canonical": "owners-by-balance", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "Where individual owners end and desks, funds and exchange hot wallets begin. This line counts the owners in the band rather than the coins.", "technical": "Count of entities whose total balance falls between 100 and 1,000 BTC at this height. Tier C's address family publishes CUMULATIVE counts above a threshold rather than per band, so this series has no address twin to double-count against. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "owners by balance", "how many whales", "distribution", "who owns bitcoin", "rich list", "100 to 1,000 BTC" ], "kind": "stock", "shape": "osc" }, { "slug": "supply-in-entities-1k-10k", "series": "entity_supply_band_10k", "label": "Supply held by entities of 1,000 to 10,000 BTC", "subtitle": "bitcoin held by owners holding between 1,000 and 10,000 BTC", "categories": [ "supply-by-owner-size" ], "canonical": "supply-by-owner-size", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "Institutional scale. Movements here are usually operational rather than anybody changing their mind.", "technical": "Live BTC held by entities whose total balance falls between 1,000 and 10,000 BTC at this height, summed across every address the entity owns. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "supply by owner size", "whale", "distribution", "who owns bitcoin", "rich list", "1,000 to 10,000 BTC" ], "sameAs": [ { "slug": "supply-in-addresses-1k-10k", "relation": "near-duplicate", "note": "Tier C publishes the same band over ADDRESSES, and the two are meant to be read together rather than counted twice: clustering reaches only 7.24% of supply, so the entity line is the address line with a small correction. Measured at the tip, the gap is -0.5%. Under-merging pushes coins DOWN the ladder, so the large bands are understated and the middle bands overstated." } ], "kind": "stock", "shape": "osc" }, { "slug": "entities-holding-1k-10k", "series": "entity_count_band_10k", "label": "Entities holding 1,000 to 10,000 BTC", "subtitle": "how many owners hold between 1,000 and 10,000 BTC", "categories": [ "owners-by-balance" ], "canonical": "owners-by-balance", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "Institutional scale. This line counts the owners in the band rather than the coins.", "technical": "Count of entities whose total balance falls between 1,000 and 10,000 BTC at this height. Tier C's address family publishes CUMULATIVE counts above a threshold rather than per band, so this series has no address twin to double-count against. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "owners by balance", "how many whales", "distribution", "who owns bitcoin", "rich list", "1,000 to 10,000 BTC" ], "kind": "stock", "shape": "osc" }, { "slug": "supply-in-entities-10k-100k", "series": "entity_supply_band_100k", "label": "Supply held by entities of 10,000 to 100,000 BTC", "subtitle": "bitcoin held by owners holding between 10,000 and 100,000 BTC", "categories": [ "supply-by-owner-size" ], "canonical": "supply-by-owner-size", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "The largest ordinary owners on the chain: exchange cold storage, custodians and ETF vaults.", "technical": "Live BTC held by entities whose total balance falls between 10,000 and 100,000 BTC at this height, summed across every address the entity owns. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "supply by owner size", "whale", "distribution", "who owns bitcoin", "rich list", "10,000 to 100,000 BTC" ], "sameAs": [ { "slug": "supply-in-addresses-10k-100k", "relation": "near-duplicate", "note": "Tier C publishes the same band over ADDRESSES, and the two are meant to be read together rather than counted twice: clustering reaches only 7.24% of supply, so the entity line is the address line with a small correction. Measured at the tip, the gap is +3.9%. Under-merging pushes coins DOWN the ladder, so the large bands are understated and the middle bands overstated." } ], "kind": "stock", "shape": "osc" }, { "slug": "entities-holding-10k-100k", "series": "entity_count_band_100k", "label": "Entities holding 10,000 to 100,000 BTC", "subtitle": "how many owners hold between 10,000 and 100,000 BTC", "categories": [ "owners-by-balance" ], "canonical": "owners-by-balance", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "The largest ordinary owners on the chain: exchange cold storage, custodians and ETF vaults. This line counts the owners in the band rather than the coins.", "technical": "Count of entities whose total balance falls between 10,000 and 100,000 BTC at this height. Tier C's address family publishes CUMULATIVE counts above a threshold rather than per band, so this series has no address twin to double-count against. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "owners by balance", "how many whales", "distribution", "who owns bitcoin", "rich list", "10,000 to 100,000 BTC" ], "kind": "stock", "shape": "osc" }, { "slug": "supply-in-entities-100k-plus", "series": "entity_supply_band_100k_up", "label": "Supply held by entities of 100,000 BTC and above", "subtitle": "bitcoin held by owners holding of 100,000 BTC or more", "categories": [ "supply-by-owner-size" ], "canonical": "supply-by-owner-size", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "A handful of owners in the whole world, and the band clustering cannot touch at all: at the tip the entity and address lines agree to seven significant figures.", "technical": "Live BTC held by entities whose total balance falls of 100,000 BTC or more at this height, summed across every address the entity owns. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "supply by owner size", "whale", "distribution", "who owns bitcoin", "rich list", "100,000 BTC and above" ], "sameAs": [ { "slug": "supply-in-addresses-100k-plus", "relation": "near-duplicate", "note": "Tier C publishes the same band over ADDRESSES, and the two are meant to be read together rather than counted twice: clustering reaches only 7.24% of supply, so the entity line is the address line with a small correction. Measured at the tip, the gap is +0.0%. Under-merging pushes coins DOWN the ladder, so the large bands are understated and the middle bands overstated." } ], "kind": "stock", "shape": "osc" }, { "slug": "entities-holding-100k-plus", "series": "entity_count_band_100k_up", "label": "Entities holding 100,000 BTC and above", "subtitle": "how many owners hold of 100,000 BTC or more", "categories": [ "owners-by-balance" ], "canonical": "owners-by-balance", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "A handful of owners in the whole world, and the band clustering cannot touch at all: at the tip the entity and address lines agree to seven significant figures. This line counts the owners in the band rather than the coins.", "technical": "Count of entities whose total balance falls of 100,000 BTC or more at this height. Tier C's address family publishes CUMULATIVE counts above a threshold rather than per band, so this series has no address twin to double-count against. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. Co-spending reaches 933.4M of 972.7M scripts and folds them into 115.4M multi-script entities, but those entities hold only 7.24% of circulating supply. Everything else is a one-script entity, which is the same object tier C calls an address, so this line stays close to its address twin by construction.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. Confidence LOW-TO-MODERATE, and lowest at the top of the range. Under-merging pushes coins DOWN the ladder: an exchange whose addresses we failed to join appears as many mid-sized holders instead of one large one, so the large bands are understated and the middle bands overstated. Glassnode's equivalents use labelled exchange data and will not agree with these. The small bands are the most reliable and the 10k+ bands the least.", "keywords": [ "owners by balance", "how many whales", "distribution", "who owns bitcoin", "rich list", "100,000 BTC and above" ], "kind": "stock", "shape": "trend" }, { "slug": "illiquid-supply", "series": "illiquid_supply", "label": "Illiquid supply", "subtitle": "coins held by owners who almost never sell", "categories": [ "supply-off-the-market" ], "canonical": "supply-off-the-market", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "Bitcoin held by owners who have spent less than a quarter of everything they ever received. It is the closest thing on this page to \"supply that is not for sale\", and it is a large number. The three liquidity lines add up to circulating supply exactly, so a coin is in one of them and only one.", "technical": "Live BTC held by entities whose lifetime spent-over-received ratio is below 0.25 at this height. Liquidity is a RUNNING lifetime ratio: at every height an entity is scored on what it had spent of everything it had received BY THAT HEIGHT, with no look-ahead, so an entity that starts trading in 2024 is not retroactively a trader in 2015. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. No exchange, miner or ETF label list is used anywhere in this tier, which is the main reason these numbers differ from Glassnode's.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. On top of that, liquidity here is a RUNNING lifetime ratio: at every height an entity is scored on what it had spent of what it had received BY THAT HEIGHT, so an entity that becomes a trader in 2024 is not retroactively a trader in 2015. Glassnode's version of this leans on exchange labels to separate custodial float from held supply and ours cannot, so the illiquid line here will read higher than theirs. Confidence LOW on the level, MODERATE on the direction.", "keywords": [ "illiquid supply", "not for sale", "hodlers", "supply squeeze", "cold storage" ], "kind": "stock", "validFrom": 4082, "shape": "osc" }, { "slug": "liquid-supply", "series": "liquid_supply", "label": "Liquid supply", "subtitle": "coins held by owners who sometimes sell", "categories": [ "supply-off-the-market" ], "canonical": "supply-off-the-market", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "Bitcoin held by owners who have spent between a quarter and three quarters of what they received: people and businesses that use their coins as well as hold them. The three liquidity lines add up to circulating supply exactly, so a coin is in one of them and only one.", "technical": "Live BTC held by entities whose lifetime spent-over-received ratio is between 0.25 and 0.75. Liquidity is a RUNNING lifetime ratio: at every height an entity is scored on what it had spent of everything it had received BY THAT HEIGHT, with no look-ahead, so an entity that starts trading in 2024 is not retroactively a trader in 2015. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. No exchange, miner or ETF label list is used anywhere in this tier, which is the main reason these numbers differ from Glassnode's.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. On top of that, liquidity here is a RUNNING lifetime ratio: at every height an entity is scored on what it had spent of what it had received BY THAT HEIGHT, so an entity that becomes a trader in 2024 is not retroactively a trader in 2015. Glassnode's version of this leans on exchange labels to separate custodial float from held supply and ours cannot, so the illiquid line here will read higher than theirs. Confidence LOW on the level, MODERATE on the direction.", "keywords": [ "liquid supply", "tradable supply", "float" ], "kind": "stock", "shape": "osc" }, { "slug": "highly-liquid-supply", "series": "highly_liquid_supply", "label": "Highly liquid supply", "subtitle": "coins held by owners who trade", "categories": [ "supply-off-the-market" ], "canonical": "supply-off-the-market", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "Bitcoin held by owners who have spent more than three quarters of everything they ever received. Exchange and trading float, as far as it can be seen without a label list. The three liquidity lines add up to circulating supply exactly, so a coin is in one of them and only one.", "technical": "Live BTC held by entities whose lifetime spent-over-received ratio is above 0.75. Liquidity is a RUNNING lifetime ratio: at every height an entity is scored on what it had spent of everything it had received BY THAT HEIGHT, with no look-ahead, so an entity that starts trading in 2024 is not retroactively a trader in 2015. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. No exchange, miner or ETF label list is used anywhere in this tier, which is the main reason these numbers differ from Glassnode's.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. On top of that, liquidity here is a RUNNING lifetime ratio: at every height an entity is scored on what it had spent of what it had received BY THAT HEIGHT, so an entity that becomes a trader in 2024 is not retroactively a trader in 2015. Glassnode's version of this leans on exchange labels to separate custodial float from held supply and ours cannot, so the illiquid line here will read higher than theirs. Confidence LOW on the level, MODERATE on the direction.", "keywords": [ "highly liquid supply", "exchange supply", "float", "trading" ], "kind": "stock", "shape": "osc" }, { "slug": "illiquid-entities", "series": "illiquid_entities", "label": "Illiquid entities", "subtitle": "how many owners almost never sell", "categories": [ "supply-off-the-market" ], "canonical": "supply-off-the-market", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many owners have spent less than a quarter of everything they ever received. The three counts add up to the number of owners holding anything.", "technical": "Count of entities with a positive balance whose lifetime spent-over-received ratio is below 0.25. Liquidity is a RUNNING lifetime ratio: at every height an entity is scored on what it had spent of everything it had received BY THAT HEIGHT, with no look-ahead, so an entity that starts trading in 2024 is not retroactively a trader in 2015. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. No exchange, miner or ETF label list is used anywhere in this tier, which is the main reason these numbers differ from Glassnode's.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. On top of that, liquidity here is a RUNNING lifetime ratio: at every height an entity is scored on what it had spent of what it had received BY THAT HEIGHT, so an entity that becomes a trader in 2024 is not retroactively a trader in 2015. Glassnode's version of this leans on exchange labels to separate custodial float from held supply and ours cannot, so the illiquid line here will read higher than theirs. Confidence LOW on the level, MODERATE on the direction.", "keywords": [ "illiquid entities", "hodlers", "how many holders never sell" ], "kind": "stock", "validFrom": 1025, "shape": "trend" }, { "slug": "liquid-entities", "series": "liquid_entities", "label": "Liquid entities", "subtitle": "how many owners sometimes sell", "categories": [ "supply-off-the-market" ], "canonical": "supply-off-the-market", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many owners have spent between a quarter and three quarters of what they received. The three counts add up to the number of owners holding anything.", "technical": "Count of entities with a positive balance whose lifetime ratio is between 0.25 and 0.75. Liquidity is a RUNNING lifetime ratio: at every height an entity is scored on what it had spent of everything it had received BY THAT HEIGHT, with no look-ahead, so an entity that starts trading in 2024 is not retroactively a trader in 2015. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. No exchange, miner or ETF label list is used anywhere in this tier, which is the main reason these numbers differ from Glassnode's.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. On top of that, liquidity here is a RUNNING lifetime ratio: at every height an entity is scored on what it had spent of what it had received BY THAT HEIGHT, so an entity that becomes a trader in 2024 is not retroactively a trader in 2015. Glassnode's version of this leans on exchange labels to separate custodial float from held supply and ours cannot, so the illiquid line here will read higher than theirs. Confidence LOW on the level, MODERATE on the direction.", "keywords": [ "liquid entities", "spenders", "float" ], "kind": "stock", "shape": "osc" }, { "slug": "highly-liquid-entities", "series": "highly_liquid_entities", "label": "Highly liquid entities", "subtitle": "how many owners trade", "categories": [ "supply-off-the-market" ], "canonical": "supply-off-the-market", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many owners have spent more than three quarters of everything they ever received. The three counts add up to the number of owners holding anything.", "technical": "Count of entities with a positive balance whose lifetime ratio is above 0.75. Liquidity is a RUNNING lifetime ratio: at every height an entity is scored on what it had spent of everything it had received BY THAT HEIGHT, with no look-ahead, so an entity that starts trading in 2024 is not retroactively a trader in 2015. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. No exchange, miner or ETF label list is used anywhere in this tier, which is the main reason these numbers differ from Glassnode's.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. On top of that, liquidity here is a RUNNING lifetime ratio: at every height an entity is scored on what it had spent of what it had received BY THAT HEIGHT, so an entity that becomes a trader in 2024 is not retroactively a trader in 2015. Glassnode's version of this leans on exchange labels to separate custodial float from held supply and ours cannot, so the illiquid line here will read higher than theirs. Confidence LOW on the level, MODERATE on the direction.", "keywords": [ "highly liquid entities", "traders", "exchanges", "float" ], "kind": "stock", "shape": "osc" }, { "slug": "never-spent-supply", "series": "never_spent_supply", "label": "Supply that has never been spent", "subtitle": "coins held by owners who have never sent anything", "categories": [ "supply-off-the-market" ], "canonical": "supply-off-the-market", "unit": "BTC", "provisional": true, "quality": "reconstruction", "plain": "Bitcoin held by owners who have never made a single outgoing transaction. It is the strictest retention measure available without a label list: one spend, even a wallet moving its own coins to a new address, removes an owner from this line permanently.", "technical": "Live BTC held by entities with no outgoing transaction ever. A FLOOR on held supply rather than an estimate of it. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. No exchange, miner or ETF label list is used anywhere in this tier, which is the main reason these numbers differ from Glassnode's.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. This is the strictest retention measure available without labels: an entity counts only while it has never spent anything at all. One outgoing transaction, including a wallet moving its own coins to a new address, removes it permanently. It is therefore a FLOOR on held supply, not an estimate of it. Confidence MODERATE: the definition is unambiguous, the entity behind it is not.", "keywords": [ "never spent", "hodl", "supply that never moves", "illiquid supply", "lost coins" ], "sameAs": [ { "slug": "accumulation-supply", "relation": "definition-variant", "note": "Tier C's accumulation supply asks a related question at the ADDRESS level and with a different rule (at least two receipts, no spend, a receipt within seven years). They are not interchangeable: at the tip this line reads 14.86M BTC against accumulation supply's 8.47M." } ], "kind": "stock", "validFrom": 4150, "shape": "osc" }, { "slug": "never-spent-entities", "series": "never_spent_entities", "label": "Entities that have never spent", "subtitle": "how many owners have never sent anything", "categories": [ "supply-off-the-market" ], "canonical": "supply-off-the-market", "unit": "count", "provisional": true, "quality": "reconstruction", "plain": "How many owners have received bitcoin and never once sent any. Most of them hold very little: this line is dominated by tiny balances, which is why the supply version beside it is the one to read.", "technical": "Count of entities with a positive balance and no outgoing transaction ever. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. No exchange, miner or ETF label list is used anywhere in this tier, which is the main reason these numbers differ from Glassnode's.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. This is the strictest retention measure available without labels: an entity counts only while it has never spent anything at all. One outgoing transaction, including a wallet moving its own coins to a new address, removes it permanently. It is therefore a FLOOR on held supply, not an estimate of it. Confidence MODERATE: the definition is unambiguous, the entity behind it is not.", "keywords": [ "never spent", "hodlers", "how many holders never sell", "diamond hands" ], "kind": "stock", "validFrom": 1026, "shape": "trend" }, { "slug": "never-spent-share", "series": "never_spent_share", "label": "Never-spent share of supply", "subtitle": "what fraction of all bitcoin has never been sent by its owner", "categories": [ "supply-off-the-market" ], "canonical": "supply-off-the-market", "unit": "share", "provisional": true, "quality": "reconstruction", "plain": "What share of all the bitcoin in existence sits with owners who have never sent anything. At the tip it is about 74%, which sounds enormous until you remember that lost coins and coins whose owner simply never moved them count the same way.", "technical": "Never-spent supply over circulating supply. An entity is INFERRED, never observed: addresses spent together in one transaction are treated as one owner (policy p1_conservative), a merge that is refused on CoinJoin-shaped transactions and by a supply-share circuit breaker, so it under-merges rather than over-merges. No exchange, miner or ETF label list is used anywhere in this tier, which is the main reason these numbers differ from Glassnode's.", "limit": "The entity here is not in the blockchain, it is INFERRED by our own clustering: addresses that were spent together in one transaction are treated as one owner, except where the transaction looks like a CoinJoin or would build an implausibly large entity. That guess is conservative by design, so it under-merges rather than over-merges. Our numbers will not match Glassnode's: their clustering is proprietary and assisted by labelled exchange data we deliberately do not use. We answer the same question, we do not claim the same number. This is the strictest retention measure available without labels: an entity counts only while it has never spent anything at all. One outgoing transaction, including a wallet moving its own coins to a new address, removes it permanently. It is therefore a FLOOR on held supply, not an estimate of it. Confidence MODERATE: the definition is unambiguous, the entity behind it is not.", "keywords": [ "never spent share", "hodl", "supply that never moves", "lost coins", "diamond hands" ], "sameAs": [ { "slug": "never-spent-supply", "relation": "unit-variant", "note": "The same measurement expressed as a share of supply rather than in coins." } ], "kind": "stock", "shape": "osc" } ] }