Take a strategy with a daily Sharpe ratio of 0.10. Run it through a standard backtesting library and you'll get an annual Sharpe of about 1.59. Run the same numbers with the right calendar for crypto and you get 1.91.
Same trades. Same equity curve. A 20% gap, and nothing in your strategy caused it.
Where the 252 comes from
Stock markets are open roughly 252 days a year. Weekends and holidays are closed, so the industry settled on 252 as the number of trading days. Nearly every analytics tool inherited it: you take the average daily return, the daily volatility, and scale by 252 or its square root.
Crypto doesn't close. Bitcoin trades on Saturday, on Christmas, at 3am on a Sunday. There are 365 daily bars a year, and a tool that assumes 252 is quietly pretending that 113 of them don't exist.
I found this the annoying way. A strategy I'd tested looked weaker in one library than in a spreadsheet I'd built by hand, and I spent an evening hunting for a bug in my own code. The bug wasn't mine. It was a default I never looked at.
What the wrong number actually does
Annualized Sharpe scales with the square root of the number of periods. So the ratio between the two conventions is the square root of 365 over 252, which is about 1.20. Use 252 on crypto data and you understate the Sharpe by roughly 17%. Use 365 on an equity strategy and you overstate it by about 20%.
Volatility has the same problem. Daily volatility scaled by the square root of 252 comes out lower than the same figure scaled by 365. If you're sizing positions off a volatility target, the error flows straight into how much risk you take.
Returns are less dramatic but still wrong. A CAGR calculation that divides the number of bars by 252 to get years will think your backtest ran for far longer than it did. Eight years of daily crypto data looks like almost twelve. The annualized return shrinks to match.
Why nobody catches it
Because the output looks reasonable. A Sharpe of 1.6 instead of 1.9 doesn't scream error. It looks like a slightly weaker strategy, and you might shelve it. Or you compare it against an equity benchmark that used the correct 252, and the comparison is off by a fifth before you even start.
The mismatch also hides in mixed portfolios. If you're blending a crypto sleeve with a stock-index sleeve, each one needs its own annualization factor. Most tools apply one number to everything.
Most traders check the signal and the fees. Almost nobody checks the calendar.
A five-minute check
Open your backtest code and search for 252. It's often buried in a helper function or a library default. Then work out what your data's actual frequency is: for daily crypto bars, 365. For hourly bars, 24 times 365, which is 8,760. For 4-hour bars, 2,190.
Then rerun your headline numbers with the right factor and see which ones move. Sharpe, Sortino, volatility, and any CAGR that counts bars to get years. If the strategy still clears your bar, good. If it only clears it under one convention, you've learned something worth knowing before you put money behind it.
I'd also note the direction of the error matters. In my case the wrong default made things look worse, which is the safe mistake. The dangerous version is the opposite: a tool set to 365 applied to a strategy that only trades weekdays, flattering the result by a fifth.
At v33 Systematic we publish our backtest assumptions alongside the results, including the annualization factor, because a number without its calendar isn't something you can verify. The data is at v33systematic.com.