Someone asked me the other day what the beta of a mid-cap token was, like it was a fixed property of the asset. I ran the number and got something around 1.4. Then I changed the lookback from one year to six months and got 0.9. Then I changed the benchmark from Bitcoin to a broad crypto index and got 1.8. Same token, three answers, and none of them wrong exactly. That is the whole problem in miniature. Beta is supposed to be a stable description of how an asset moves with the market, and in crypto it is anything but stable.
I still use beta. It is a useful shorthand when I am talking about relative risk in a quick way. But I stopped treating the single number as if it means what it means for equities, and I think anyone sizing crypto positions should do the same. Here is where it falls apart and what I lean on instead.
What beta is actually assuming
Beta comes out of CAPM, and CAPM carries a set of assumptions that are quietly load-bearing. It assumes returns are roughly normal, so variance and covariance capture most of what you care about. It assumes there is a well-defined market portfolio, one clean proxy for the thing everything else is measured against. And it assumes the relationship between the asset and the market is stable enough that a coefficient estimated over the past year tells you something about the next one.
Equities bend these assumptions but do not shatter them. A diversified stock index is a defensible market proxy, daily stock returns are fat-tailed but not wildly so, and the beta of a large industrial company does not usually swing from 0.8 to 2.0 across a quarter. Crypto violates all three at once, and it violates them hard.
The three specific failures
The first is fat tails. Crypto return distributions have far more extreme moves than a normal distribution predicts, and the big days are where a lot of the action lives. Beta is a variance-and-covariance object, so it treats a calm month and a violent liquidation cascade as if they belong to the same underlying process. They do not. When you estimate beta over a window that happens to include a deleveraging event, that single stretch dominates the regression, and your coefficient is really describing one week of forced selling rather than the asset's normal behavior.
The second is the ambiguous market proxy. In equities, everyone more or less agrees what the market is. In crypto there is no consensus. Is the market Bitcoin? Bitcoin plus Ether? A market-cap-weighted index dominated by two assets? A basket that includes stablecoins and wrapped tokens? Each choice gives you a different beta for the same asset, and the differences are not small. Beta is only meaningful relative to a benchmark, and when the benchmark is contested, the number inherits that ambiguity. You are not measuring a property of the asset, you are measuring a property of the asset and your arbitrary choice of index, stuck together.
The third is instability across regimes. Crypto correlations are not constant. In a broad risk-off flush, almost everything correlates to one and moves with Bitcoin, so betas compress toward each other and toward one. In quieter periods, idiosyncratic stories take over, correlations drop, and the same tokens show much lower or noisier betas. A single beta estimated across both regimes is an average of two different worlds, and the average describes neither. It is highest precisely when it is least useful, in the crash, when everything moves together and diversification you thought you had disappears.
What I use instead
None of this means throw the concept out. It means stop asking beta to be one number and start asking narrower, more honest questions. A few things that hold up better in practice.
- Downside beta. Estimate the relationship using only the days the market fell. This is the number that matters for risk, because it captures how the asset behaves when you actually care, in drawdowns. Plenty of tokens have a friendly-looking full-sample beta and a downside beta well above it, which tells you the diversification is fair-weather.
- Regime-conditional estimates. Split your history into calm and stressed periods and compute beta separately in each, using realized volatility or a simple trend filter to define the split. Two numbers that bracket the range are more useful than one number that hides it. Report both and size for the worse one.
- Rolling beta over static beta. Never trust a single long-window estimate. Plot beta on a rolling window and look at how much it moves. The dispersion of the rolling series is itself the signal. If beta swings from 0.6 to 2.2 over a year, the point estimate is close to meaningless and you should treat the asset as high-uncertainty regardless of where it sits today.
- Tail co-movement directly. If what you fear is joint crashes, measure that, not variance. Look at how often the asset posts a large loss on the same days the market does. This gets at the thing fat tails break in ordinary beta, and it does not care whether the distribution is normal.
A practical rule I keep coming back to: if two beta estimates for the same asset disagree by more than roughly half a point when you only change the lookback window or the benchmark, stop quoting the number as a fact. Quote the range, and size the position for the ugly end of it. On our own scorecards at Blockcircle I would rather show a rolling band and a downside figure than one clean coefficient, because the clean coefficient is the one that lies to you in the exact moment it matters.
The mistake is not using beta. The mistake is inheriting a tool built for a world of roughly normal returns and one agreed-upon market, and using it in a world that has neither. Ask it the smaller questions it can actually answer, keep two or three estimates side by side, and let the spread between them be part of what you are looking at. That spread is usually telling you more than any single number would.