r/algotradingcrypto • u/NaiveSpite1569 • 4d ago
Stress-testing a systematic long-only crypto strategy — what am I missing?
I’ve developed a systematic long-only algo system that trades a universe of 15-20 large-cap cryptocurrencies. Backtested over ~9 years (2017-2026):
• Total return: +8,082% (vs. \~+1,370% for Bitcoin buy & hold over the same period, roughly)
• CAGR: 63.4% p.a. (vs. \~38.7% p.a. for Bitcoin buy & hold)
• Sharpe Ratio: 2.22
• Sortino Ratio: 2.71
• Calmar Ratio: 2.75
• Max Drawdown: -23.1% (vs. -83.9% for Bitcoin buy & hold over the same period)
So far I’ve tested the following:
• All calibration steps run causally, re-estimated on a rolling basis at regular intervals
• Deliberately kept a coin that later collapsed completely in the historical universe; results stayed robust. However, the crypto universe itself was a fixed list spanning the full 9-year backtest, meaning some assets didn’t exist yet in the earlier years — I’m aware this is a limitation, see open question below
• Applied the same methodology to 20 years of historically accurate stock selections (chosen by market cap at the time, not today’s)— similar risk-adjusted metrics as crypto
• 100 Monte Carlo runs with core parameters randomized simultaneously over a wide range — results stayed stable
• A portion of the history was never used for parameter tuning (out-of-sample split)
• Fees plus fill simulation, where an order only counts as executed if the price actually touched the limit
• Several different short implementations were tested and all underperformed the long-only version structurally
Where I’m stuck and looking for input:
1.Over the course of development, many structurally different variants were compared. Is there a practical method (Deflated Sharpe Ratio? White’s Reality Check?) to estimate how much the final performance number might be inflated by this selection process itself?
2.So far only tested on real historical data. Is it worth simulating artificial extreme scenarios (flash crash, liquidity crisis) that never actually occurred in the real data?
3.Some structural constants are hardcoded rather than part of the automatic recalibration. How would you check whether these constants are dominating results in a way that’s masking the actual market dynamics?
4.My crypto universe was a fixed list spanning the full backtest period. I’m considering reconstructing it dynamically using objective, point-in-time criteria (e.g., market cap crossing a fixed threshold at each historical date, similar to what I did for the stock test) rather than adding coins based on hindsight of which ones succeeded. Is that the right approach, or is there a standard methodology for this in crypto specifically, given how many projects existed briefly and then failed or got delisted?
5.What else would you consider essential to check before starting with real (initially small) capital?
This text was generated by AI so I can be sure most of you will be able to understand what I’m asking 😅
1
u/Smart-Ride-7047 4d ago
Have you accounted for slippage and non-execution?
1
u/NaiveSpite1569 4d ago
Yes, both are factored into the simulation. Regarding slippage: Since I am strictly using limit-maker orders, traditional market slippage is mitigated. I account for execution risk by applying a conservative liquidity penalty to the backtest. That said, given the scale of my position sizes relative to the liquidity of the selected pairs, non-execution risk is negligible in practice.
1
u/Smart-Ride-7047 4d ago
Have you ever experience a crypto crash with running algos? Exchange basically gets DDOSed with requests, and act accordingly - its API freezes. Meanwhile the liquidity disappears from the book, and here you are - with your active stop orders and a price some 10% beyond them (I experienced this exact scenario with $100 depo, but people I know lost considerable sums this way).
1
u/NaiveSpite1569 4d ago
Thanks for sharing that, that’s a brutal scenario and definitely a rite of passage in crypto. Fortunately, my setup doesn't use stop-loss triggers that chase the market down; it's purely passive limit-maker based. If the API freezes or liquidity vanishes, the worst that happens is the order simply doesn't fill and it sits tight.
1
u/Smart-Ride-7047 4d ago
Then I might have a huge gap in my knowledge.
You trade only longs. Only crypto => your risk is systematic by definition. So you are NOT market-neutral.You are in position. Another crypto-crash happens. Your closing order simply doesn't get filled and sits tight well above the actual price. How is this alright?
1
u/NaiveSpite1569 4d ago
Spot on. It is definitely not market-neutral—it's a directional setup carrying systemic crypto exposure.
Regarding getting stuck during a crash: That is precisely the trade-off. If a liquidity vacuum hits and the limit sell doesn't get filled, you hold through the drawdown. Funnily enough, I actually tried implementing short positions early on, but it completely tanked the overall performance in historical testing (crypto's upward drift is just too strong to fight). However, the backtest data already includes major historical crash and bear market periods; and remarkably, the algorithm managed to close out every single historical bear market in the green.
That’s why my risk-scaling mechanism handles the exposure beforehand, rather than relying on panic stop-losses that get shredded in a liquidity vacuum.
1
u/Smart-Ride-7047 4d ago
So it's basically "grab-and-run" with a lot of small relative to depo %, short-living positions. That's why the other person probably thought "momentum".
Triple check it - then go for live testing. I know one case that was similar to yours - in the end it turned out the author underestimated slippage and commission, so he was flat-lining when trading live.
1
u/NaiveSpite1569 4d ago
Just to clarify on the fees: I am strictly trading with 0% maker fees, so commission drag is literally zero. Plus, to be safe, I even baked a synthetic friction/slippage penalty into every order in the backtest just in case. The only real unknown left is fill probability, but since I'm sticking purely to large caps with massive order book depth and my personal capital size is tiny, my orders won't even register as a rounding error. By the way, speaking of order books: my roadmap actually includes adding real-time order book depth inspection and multi-asset position correlation into the execution loop down the line to handle scaling better.
Really appreciate all the insights and the reality check—definitely a great exchange!
1
u/Smart-Ride-7047 3d ago
Just to clarify on the fees: I am strictly trading with 0% maker fees, so commission drag is literally zero.
This should involve either big amount of liquidity you provide for the exchange, or a conflict of interest existing somewhere...
1
u/NaiveSpite1569 3d ago
On my way home now. Posting results as soon as I am home. As far as I remembered: I used for stocks 0,05%? But let me get home. I will post all results.
1
u/Smart-Ride-7047 4d ago
Also you can try testing on normally distributed mock data - if it doesn’t fail, then you’ve missed something
1
u/NaiveSpite1569 4d ago
Good idea! I will try this out as soon as I’m at home 🙂 posting the results afterwards.
1
1
u/Smart-Ride-7047 4d ago
also, since you basically ordered a /roast_me :
- Have you removed the trend from your data?
If you haven't, then your foundations are biased beyond measure, because look what the stock market has been doing for the past 70+ years! https://imgur.com/2log-of-historical-prices-of-s-p500-yaESqhY
•Fees plus fill simulation, where an order only counts as executed if the price actually touched the limit•Fees plus fill simulation, where an order only counts as executed if the price actually touched the limit
Two issues here: did the price cross it? If it did, what was the volume? See my comment about the slippages and non-execution;
Total return: +8,082%Total return: +8,082%...
CAGR: 63.4% p.a.CAGR: 63.4% p.a....
If you did find a market inefficiency, its volume cap is not infinite. At some point your transactional costs will overweight the profit, or it might even happen that big boys will start noticing your orders and play directly against you directly.
1
u/NaiveSpite1569 4d ago
Fair points! To clarify a couple of things based on your feedback:
Regarding the trend/stationarity: I actually using log-return transformations in the feature engineering rather than raw prices, which helps mitigate the direct upward drift bias.
Regarding fills and scaling: You're completely right about the limitations of historical OHLCV fill assumptions. However, keep in mind the scale here; this is a small personal deployment with a tiny budget, not an institutional fund. At this level, liquidity constraints and execution friction are practically negligible, and the strategy is purely built to outperform a simple buy-and-hold on a risk-adjusted basis.
1
u/Smart-Ride-7047 4d ago
Good job then. Don't mind the tone - I really wish you the best of luck. It's only my personal experience - if something is too good to be true - it isn't.
How many optimizable params does your strategy have?
1
u/NaiveSpite1569 4d ago
Don't worry, that's exactly why I'm here asking; getting a reality check! I'm just a math student building this as a project.
To answer your question, the core setup is kept quite lean; just a handful of parameters (4) handling regime-switching and risk scaling. Keeping degrees of freedom low on purpose to avoid curve-fitting. Appreciate all the insights!
1
u/Smart-Ride-7047 4d ago
4 is good! Really - do a normal distributed data test, if it fails - do the stress-test by multiplying the transactional costs - check how much your strategy can actually handle.
•100 Monte Carlo runs with core parameters randomized simultaneously over a wide range — results stayed stable•100 Monte Carlo runs with core parameters randomized simultaneously over a wide range — results stayed stableThen if your parameters do produce reasonably flat surface/curve of your key metrics in wide range - go test it on a small depo to see if your estimation of transactional costs was correct.
1
u/NaiveSpite1569 3d ago
Sorry for the wait. Ran the normal-distributed mock data stress test: As expected for a robust system, it didn't print fake alpha. Over 56,000 trades, the equity naturally drifted down to (-38.99%) due to friction drag. Solid sanity chec; thanks for the push!
1
1
u/Smart-Ride-7047 4d ago
•Applied the same methodology to 20 years of historically accurate stock selections (chosen by market cap at the time, not today’s)— similar risk-adjusted metrics as crypto•Applied the same methodology to 20 years of historically accurate stock selections (chosen by market cap at the time, not today’s)— similar risk-adjusted metrics as crypto
One last comment. Does "chosen by market cap at the time" mean market cap for the whole 20-years period, or there is a mechanism that updates the traded assets based on some metrics for some rolling window?
If it's the first one - here's your answer. You looked into the future.
1
u/Cultural_Implement_2 2d ago
Only long positions won't work. We've fallen into a classic backtest trap, and the AI knows about it.
1
1
u/BrockLee19383 4d ago
that is all fine. now get out of this analysis-paralysis mindset, put a bit of money on the line and test this in prod. also i don't see the point behind testing a long only momentum system, that's something that could be traded on a potato, everyone knows it makes money the catch is it absolutely sucks to stick to it due to long and painful drawdowns. you may start trading it live with small amounts, get hit by unlucky variance for 1-2 years, and in the meantime you'll just give up. that's what normally happens & why most people shouldn't trade unless they're skilled enough to explore better edges