Skip to content

AI analysis

Crypto MVRV ratio: market value vs realized value

Rebuild a six-output realized-cap ledger, isolate price changes, and see why a self-transfer can move raw MVRV without revealing a purchase.

Six ivory ceramic forms sit in folded paper pockets below a floating oval ring, with a lime edge on black.
Illustration for ai analysis; examples in this article are educational.

The crypto MVRV ratio divides market capitalization by realized capitalization. For a basic UTXO model, realized cap values each unspent output at its price when created, rather than today's price. MVRV compares current supply value with that historical on-chain valuation; it does not verify what every investor paid, identify a fair price, or guarantee a market turning point.

The useful question behind an MVRV chart is which values entered the division. A ratio can change because today's price changed, because outputs moved and received new historical valuations, or because the provider changed its treatment of supply or ownership. Those explanations have different meanings.

Separate the two valuations

Market value marks the chosen supply at one current price. Realized value applies a historical price to each included balance or output, then adds the contributions. Glassnode's MVRV definition expresses the ratio as market cap divided by realized cap.

For the simple model used here:

  • Market cap = current price × included supply.
  • Realized cap = sum of each unspent output's quantity × its creation-price observation.
  • MVRV = market cap / realized cap.

An unspent transaction output, or UTXO, is an output that has not yet been spent by a later transaction input. Bitcoin's transaction guide describes this input-and-output structure. A wallet balance can contain several outputs created at different times.

The historical dollar prices come from a price dataset; they are not purchase receipts recorded inside the outputs. A coin can move because someone bought it, but also because a holder changed wallets. “Realized” describes the metric's repricing convention, not proof that money changed hands.

Supply must also match the selected series. The market cap versus FDV guide explains why supply definitions can produce different valuations. For MVRV, use the provider's matching numerator and denominator instead of combining an unrelated market-cap page with a realized-cap chart.

Rebuild realized cap from six outputs

This example is entirely hypothetical. A fictional UTXO-style asset has only the six unspent outputs below, totaling 15 units. Each creation price is an invented USD observation assigned to that output. There are no fees, issuance or burns in this exercise; it isolates valuation arithmetic rather than reproducing a live Bitcoin dataset.

The current price is $40 per unit. Each output's market value therefore uses $40, while its realized contribution retains its assigned creation price.

OutputUnitsCreation priceRealized contributionCurrent value at $40
A2$10$20$80
B3$20$60$120
C1$25$25$40
D4$30$120$160
E2$40$80$80
F3$50$150$120
Total15—$455$600

Realized cap is $20 + $60 + $25 + $120 + $80 + $150 = $455. Market cap is 15 × $40 = $600. Dividing produces 600 / 455 ≈ 1.3187.

Realized price is realized cap divided by the same supply: $455 / 15 ≈ $30.3333 per unit. Consequently, MVRV also equals $40 / $30.3333 ≈ 1.3187, using the unrounded realized price. This identity requires a common supply basis; it should not be assumed after mixing provider variants.

The $145 difference between market and realized cap is 31.87% of the modeled historical value. That is an aggregate comparison, not a statement that each holder has earned 31.87%. Output F is below its creation price, E is exactly at its creation price, and the others are above. Three of the fifteen units are below their assigned historical valuation even though aggregate MVRV exceeds one.

Nor do six outputs mean six people. Several outputs may share a controller, while a custodian may hold assets for many customers. The active addresses versus users guide explains why on-chain identifiers do not establish a human headcount.

Change price while freezing the ledger

Keep every output and its assigned creation price unchanged. Only the current price changes in these three hypothetical observations.

Current priceSupplyRealized capMarket capMVRV
$4015$455$6001.3187
$3215$455$4801.0549
$2415$455$3600.7912

A 20% price decline from $40 to $32 reduces MVRV by 20% because the denominator stays fixed. Nothing about that decline requires an on-chain sale or a change in investor ownership. Price enters the numerator directly.

In this frozen ledger, MVRV reaches one at $455 / 15 ≈ $30.3333. That is the price at which the two modeled valuations are equal. It is not a floor: the $24 row is arithmetically possible under exactly the same ledger assumptions.

At $24, market value is 20.88% below realized value. This does not tell us when buyers will appear or whether price will recover. A threshold at one has a clear accounting interpretation; attaching a forecast requires separate evidence.

Realized cap can also move in a live series, so the frozen-denominator exercise is a diagnostic rather than a complete market model. Check both components before describing a rising ratio as new demand or a falling one as investor capitulation.

Reprice an output without a purchase

Return to the $40 baseline. Suppose the controller of output B moves all three units between two wallets they control. B is spent and replaced by two new outputs containing one and two units. Both receive the stipulated $40 creation-price observation. No beneficial ownership changes, and this hypothetical transaction pays no fee.

The old $60 contribution disappears. The new contributions are $40 × 1 = $40 and $40 × 2 = $80. Raw realized cap becomes $455 − $60 + $40 + $80 = $515.

Supply remains 15 and market cap remains $600, but raw MVRV falls to 600 / 515 ≈ 1.1650. The ratio has declined about 11.65% with no change in the current price and no purchase in the scenario.

This follows the basic repricing mechanism in Glassnode's realized-cap methodology: spending outputs with lower historical prices can increase realized cap. In this example, describing the $60 denominator increase as $60 of fresh money invested would invent an economic event.

Change outputs present a related problem. Spending a large output to make a small payment can create both a recipient output and change returning to the sender. Glassnode's original account-based metrics research explains why internal transfers and change can influence raw UTXO measurements.

Its entity-adjusted MVRV documentation describes a variant that discards transfers within the same entity. In a simplified version of our example with perfect ownership knowledge, ignoring B's internal move would preserve its old contribution, leaving realized cap at $455 and MVRV at 1.3187. That illustrates continuity of the modeled basis; it does not reproduce Glassnode's complete averaging and clustering implementation.

Identify the provider's actual construction

Two MVRV charts can differ without either making a division error. Coin Metrics documents CapMVRVCur as CapMrktCurUSD / CapRealUSD. Its realized-cap method uses the closing USD price on the day of last movement. For UTXOs, that date is output creation. For account-based chains, it uses the more recent of account creation and the last date the account sent a ledger change. Its current-supply market cap also differs from some circulating-supply estimates. Coin Metrics capitalization methodology.

That is one documented implementation. Do not apply a Bitcoin output example to every account-based token by silently assuming the same lot-tracking rule. Ask how the provider assigns historical value after partial balance changes and which asset units it covers.

Also preserve variant names. Coin Metrics' free-float MVRV changes the market-value numerator, while MVRV z-score uses a different normalization. Neither is interchangeable with the raw ratio above. A threshold copied from another variant is not a definition.

Entity adjustment introduces another model. Glassnode describes entities as estimated common-control clusters using heuristics and proprietary algorithms, and notes that recent entity-based observations can revise. Glassnode entity methodology. A cluster is useful evidence about control, not a verified list of purchases or exchange customers.

For historical research, distinguish a series downloaded today from one available at the original observation time. Glassnode's point-in-time methodology describes preserving the information available when observations were first computed. Record which kind you used before assessing an old signal.

Audit the claim attached to the ratio

Use this worksheet before quoting an MVRV value or comparing two providers.

FieldRecord or validateFailure it catches
Asset and scopeNative asset, chain, included supply and exclusionsTreating unlike supplies as the same denominator
Metric identityProvider, exact series and raw or adjusted variantComparing MVRV with a cohort ratio or z-score
Price observationsQuote currency, current price time and historical price conventionCombining a live numerator with an older denominator
Ledger valuationOutput or account rule, self-transfers and change treatmentCalling every move a purchase
ReproductionMatching market cap / realized cap, allowing for roundingA mislabeled percentage or mismatched source
VersionCapture date, revision policy and point-in-time statusUsing later ownership knowledge in an earlier decision

Three practical limits remain even after the arithmetic reconciles. Dormant coins keep historical valuations in a raw model; inactivity does not establish that keys are lost. Fees or individual acquisition terms can differ from a provider's market-price observation. And customer ownership can change outside the observed ledger.

Coinbase's on-chain and off-chain glossary explains that internal ledger actions need not be recorded publicly until settlement. It follows that a trade settled entirely within a custodian need not create the output movement that resets this raw model. Treat MVRV as a specified on-chain valuation proxy, with that visibility limit intact.

Choose the next metric according to the unresolved question. For value associated with outputs spent during a period, the SOPR explanation follows that separate calculation. For transfers involving labeled trading venues, the exchange inflows and outflows guide examines the evidence needed before calling a transfer a buy or sale. MVRV alone does not answer either question.

Beside your next MVRV observation, record its matching market cap, realized cap, timestamp and adjustment rule. Then explain whether the change came from current price, ledger repricing or methodology. If those inputs are unavailable, keep the value as an unverified chart observation instead of turning it into a cost-basis claim.

Keep the context with the example.

Each worked example is illustrative, with its sources and assumptions in the article. Read our editorial standards for authorship, verification and corrections.