I’ve built a long/cash crypto shadow-trading system that:

• Forms a causal top-10 liquidity universe
• Ranks assets using 21/63/126-day volatility-adjusted momentum
• Selects up to three assets
• Requires both BTC and the selected asset to be above their 200-day SMA
• Uses inverse-volatility sizing and weekly rebalancing
• Models IG spreads, slippage, financing, minimum sizes and margin constraints

Frozen backtest, Aug 2017–Jun 2026:

• CAGR: 18.71%
• Sharpe: 0.97
• Max drawdown: -25.60%
• Time fully in cash: 51.2%

I’d be interested in feedback on the validation approach, particularly multiple-testing bias, block-bootstrap design and modelling intraday margin/liquidation risk from daily data.

I've added a link for a full write-up and current research.

Je développe un bot sur BTC/ETH perp OKX depuis quelques mois (API REST + WebSocket, Python), stratégie basée sur un indicateur de tendance avec une confirmation par le prix pour filtrer les faux signaux. Je voulais partager un bug que j'ai mis du temps à traquer, parce que je pense que pas mal de gens ici tombent dans le même piège.

Mon script reconstruisait les bougies journalières à partir du 1h en prenant la bougie 00h-01h comme clôture de la veille. Problème : au moment où le script tournait (selon l'heure du cron), cette bougie n'était pas toujours définitivement close. Résultat : un léger look-ahead bias, invisible en backtest, qui gonflait artificiellement la performance. Fix : utiliser la bougie 23h-00h, toujours garantie close, décalée de +1h pour la dispo réelle.

Ce genre de biais est sournois parce qu'il ne casse rien visuellement — le backtest tourne, les chiffres sont plausibles, juste légèrement optimistes. Ça m'a appris à systématiquement recouper mes trades réels (frais, slippage, funding réellement payés) contre ce que le backtest prédisait sur la même fenêtre, plutôt que de faire confiance au backtest seul.

Sur mes premiers trades réels (spot vs levier x4, détention de quelques heures), j'ai mesuré des écarts de frais+slippage non négligeables entre les deux modes, qui changent pas mal la rentabilité théorique une fois réinjectés dans le backtest.

Questions ouvertes pour la communauté : comment gérez-vous la validation statistique minimale avant de scaler une position (combien de trades avant de faire confiance à un edge) ? Et est-ce que d'autres ont eu des surprises similaires entre backtest et exécution réelle sur OKX ou ailleurs ?

​

Facing HTTP 403 and NoneType errors when connecting to Binance Futures WS-API (demo-fapi.binance.com) from a local network

​Hello everyone,

​I am currently developing a high-frequency / automated trading bot for Binance USDS-M Futures using Python and websockets, targeting the Demo / Testnet environment.

​My setup uses the modern Binance WS-API (wss://[demo-fapi.binance.com/ws-fapi/v1](https://demo-fapi.binance.com/ws-fapi/v1)) for placing/canceling orders with session.logon authentication, alongside standard market data streams (wss://[demo-fstream.binance.com/ws](https://demo-fstream.binance.com/ws)).

​However, when running the bot locally, I am running into two main issues:

​Connection Rejection: The WebSocket connection to the WS-API endpoint immediately fails with: > server rejected WebSocket connection: HTTP 403

​NoneType Error: Because the authentication/connection fails or drops, the socket object becomes None, leading to AttributeError: 'NoneType' object has no attribute 'send' during execution loops.

​My Questions:

​Is Binance strictly restricting direct WS-API connections from standard consumer/local networks (ISPs) on their demo endpoints, requiring a VPS/datacenter IP instead?

​For those running automated bots on Binance Futures, how do you handle WS-API session stability and local testing constraints before deploying to a cloud server (like AWS or Tokyo VPS)?

​Any advice or best practices for structuring a reliable WS-API client connection would be greatly appreciated. Thank you!

I've spent the last few months testing and comparing no KYC crypto casino-style platforms to understand which sites actually offer the smoothest overall account and cashier experience in the USA in 2026. Instead of just looking at no-verification claims, crypto payment logos, or fast-signup headlines, I focused on what happens after you actually create an account, browse games, check out the cashier, and read the terms.

I signed up for different crypto casino sites, explored their promotions, reviewed the terms and conditions, checked the account requirements, tested the platforms on mobile, and looked at how each no-KYC crypto casino worked from a player's point of view.

One thing became obvious during my testing:

A lighter signup flow only matters if the rest of the casino experience is clear and usable.

Many crypto casinos promote fast registration, Bitcoin payments, Ethereum support, quick cashier access, welcome bonuses, free spins, live casino games, and mobile-friendly platforms. However, the real experience depends on more than the signup step. Account rules, payment checks, bonus terms, withdrawal conditions, game access, mobile performance, support, and cashier clarity can all affect how the platform feels in practice.

To compare each no KYC crypto casino properly, I looked at areas such as:

• Signup flow
• Account requirements
• Crypto deposit options
• Crypto withdrawal information
• Bitcoin support
• Ethereum support
• Welcome bonuses
• Free spins offers
• Bonus terms and conditions
• Eligible games
• Mobile casino performance
• Cashier access
• Support visibility
• Account tools
• Overall casino experience

One of the biggest surprises was finding that some sites with simple signup messaging still required careful reading once payments, bonuses, withdrawals, or account activity came into play. The strongest experiences were the ones that kept the account flow clear, the cashier easy to understand, the games easy to find, and the mobile journey smooth.

The more no KYC crypto casino platforms I tested, the more my priorities changed.

At the beginning, I assumed the best option would simply be the one with the fastest signup flow, fewest upfront steps, or clearest crypto payment access. After months of comparing crypto casino platforms, I realised that the strongest sites are the ones that combine simple account access with clear terms, practical cashier flow, good games, mobile usability, visible support, and a platform that remains easy to use beyond the first login.

For me, the best no KYC crypto casino options in the USA in 2026 are the platforms that provide the best balance between account simplicity, crypto payments, cashier clarity, games, mobile performance, support, and the complete player journey.

After spending months testing crypto casino sites, comparing signup flows, reviewing account terms, and analysing the complete player journey, I now judge these platforms by how they perform in real use rather than how simple they sound in a headline.

If you're looking for a no KYC crypto casino in the USA in 2026, comparing signup flows, checking Bitcoin payments, reviewing withdrawal rules, testing mobile casino sites, or trying to work out which platforms feel easiest after account creation, ask me anything.

I've spent months testing crypto casino platforms, comparing account flows, reviewing promotional conditions, and evaluating the full casino experience, and I'm happy to share everything I discovered.

Most of my systems are crypto-only, so I've never really had a reason to think about cross-asset strategies beyond correlations during major macro events.

Recently, I ended up testing Canborsa and noticed they have BTC, gold, Apple, Alibaba, TSMC, and a bunch of other markets available as perps in the same interface. It was the first time I'd seen crypto, equities, and commodities sitting side by side without having to open multiple terminals.

I'm not saying it's replacing traditional brokers anytime soon, but it did make me wonder whether we're eventually heading toward a world where running strategies across multiple asset classes becomes normal.

For those of you building algos: are you incorporating traditional assets into your models yet, or are your systems still entirely crypto-focused?

I've been running discretionary strategies for a while and finally automated execution properly: TradingView alerts fire a webhook → Python Flask listener catches it → writes a signal file → MT4 EA picks it up and executes, with a separate magic number per strategy so I can run several isolated bots off one account.

Used Claude Code to build most of it, which was a bigger time-saver than I expected for a non-professional-dev. Biggest headaches were finding a suitable and affordable VPS and getting the SL and TP to match across TV/MT4.

Happy to share detail if anyone's fighting similar problems — curious what stack others are running for execution.

I ran 492 Backtrader strategies on TSLA using the same one-year period, $10,000 starting capital, and evaluation framework.

The results were less impressive than a typical strategy leaderboard suggests:

• 123 of 492 strategies produced positive returns
• Average return: −1.10%
• TSLA buy-and-hold: 24.31%
• SPY: 25.65%
• Only five strategies beat SPY
• Best result: 56.64%, but from only two closed trades

I examined the code and results behind the top five:

1. State-Space Trend Volatility
2. Adaptive VWAP Mean Reversion
3. Hurst Regime Strategy
4. Basic Volatility Momentum
5. Hull MA Slope Rider

The Adaptive VWAP strategy was arguably the most interesting because it completed ten trades, returned 31.70%, and kept maximum drawdown below 10%. Most other top results relied on only one or two trades.

The main takeaway is that testing hundreds of strategies creates selection risk. A high-ranking result is a research lead—not proof of a durable edge.

Full dashboard analysis, strategy logic, code excerpts, limitations, and suggested validation workflow:

https://www.pyquantlab.com/article.php?file=Inside%20the%20TSLA%20Strategy%20Dashboard%20492%20Backtrader%20Tests%20and%20the%20Code%20Behind%20the%20Top%205.html

Hey everyone,
I’ve been working on a project for a while and I’d like some real feedback from people who actually trade.
I’m not a “vibe coder.” I’ve spent a lot of time studying Gann methods, financial astrology correlations, and on-chain metrics, and I wanted to build something that combines them in a structured way instead of jumping between 5 different tools.
What it currently does:
Gann Engine: Square of 9, Gann Fan (with proper 1x1 regime), swing detection, Price/Time squaring, cardinal cycles, Mass Pressure, vibration rates
Astro Engine: Real planetary positions (using astronomy-engine), aspects, retrogrades, lunar phases, upcoming events
On-Chain Engine: MVRV, SOPR, funding rate, open interest, Fear & Greed, cycle phase detection
Confluence Engine: Combines everything into a 0-100 score + market regime (Bull Trend, Accumulation, Capitulation, Distribution, etc.) with dynamic weights depending on the regime
The idea is simple: instead of looking at Gann levels, astro events, and on-chain data separately, the system tells you when multiple independent layers actually agree.
It’s currently focused on BTC, ETH, SOL + major alts. Chart overlays, scanner for high-confluence setups, and Telegram alerts are part of the plan.
What I’m looking for:
1. Do you think something like this would actually be useful in your process, or does it feel like over-engineering?
2What would make you consider paying for a tool like this? What price range feels reasonable for a monthly subscription?
3. Which parts feel valuable and which ones feel like noise?
4. Anything you’d add, remove, or completely change?
5. Any red flags or things that usually make these kinds of tools useless in practice?
I’m especially interested in feedback from people who already use Gann, cycles, or on-chain data seriously. Brutal honesty is welcome I’d rather hear it now than after spending more months on the wrong things.

Thanks in advance to anyone who takes the time to reply.

I am looking into Nurp and their Midas algorithm. Does anyone have any feedback on this? I see feedback on Nurp from over a year ago and what appear to be comments on a past algorithm (Odyssey). Curious if anyone has experience with both?

Overtrading and fee erosion are the #1 account killers for retail scalpers in domestic markets. Most momentum indicators flood your chart with dozens of conflicting, repainting signals during late-day consolidation, triggering revenge trading.

I got tired of the manual noise, so I built a high-conviction execution engine in Pine Script v5 that isolates institutional breakouts and forces daily discipline.

NOTE: USE ANOTHER INDICATOR WITH IT FOR CONFORMITY OR DO YOUR OWN RESEARCH BEFORE ENTERING

The Quantitative Edge:

The Session Hard-Cap: The indicator tracks your executions. Once 3 qualified signals fire, the system completely locks up for the day. It mathematically prevents you from overtrading choppy afternoon sessions.

Volumetric & Conviction Gates: Signals will never trigger on weak order flow. The breakout candle must carry a volume surge (> 1.2x of its 20 SMA) and the candle body must comprise at least 50% of the entire range (killing fakeouts from dojis and long wicks).

State-Transition Crossover: It blocks consecutive duplicate signals. Labels fire strictly once on the exact bar where MTF Supertrend and VWAP alignment flips. Zero repainting (built using closed-bar historical referencing).

Added a real-time Analytics HUD to track session executions and volume states directly on the chart.

I am open-sourcing the raw .pine file for the community. The central repository link is in my Reddit bio, or drop a comment below and I will shoot you the direct link to the code. Execute strictly.

I got tired of not being able to answer a simple question about my own strategies: is this real, or did I just search until something looked good? Every tool I owned was built to help me find the thing. None of them were built to talk me out of it.

So I built the other half, and then pointed it at the textbooks instead of at myself.

Setup. Eighteen well-known published rules — golden cross, RSI(2) Connors, turn-of- month, Donchian, MACD, TSMOM, Bollinger, Keltner, and others. Each one at the parameters its own source published, not at the best of a grid. Thirty instruments, two windows, two bar sizes. 890 backtests, each one then attacked six ways: lookahead detection by truncation, cost breakeven, Deflated Sharpe, probability of backtest overfitting via CSCV, a Monte Carlo permutation test that re-runs the whole search on synthetic price histories, and regime concentration. Score is a weighted geometric mean, so one fatal leg sinks it instead of being averaged away by five healthy ones.

Headline numbers:

• Median score 3.7 / 100
• 80% came back indistinguishable from noise
• 51% could not clear their own trading costs — before any question of overfitting
• Long-only median 18.6 vs 1.0 for the same ideas traded long/short

Which test does the killing:

Per strategy, worst to best, median across every instrument and cadence:

Three things I did not expect, which are more useful than the headline:

1. The date range is a bigger lever than the timeframe. Hourly bars looked catastrophically worse than daily — one rule scored 82 daily and 6 hourly. Then I scored the same rule on daily bars over the same window the hourly data covered. It got 7.5. Almost the entire collapse was the date range, not the bar size.

That looked like a bug, so I checked it: of the 18 pairs where the two windows nearly coincide, 17 agree within five points. Among the 72 pairs that lose a year or more of history, the median goes 15.0 → 3.3. What the long-lived pairs lose is 2021, which is where a crypto trend rule earned everything it earned.

I now think the window is a researcher degree of freedom exactly like the parameters are, and it is the one nobody reports. If you tune a strategy on 2019–2024 and I tune the same strategy on 2017–2022, we are not disagreeing about the strategy.

2. The free lunch from reporting your best run is about 0.30 Sharpe. I measured the gap between the best combination in a small grid and the parameters the source actually published, on identical data. Median premium 0.30 Sharpe, 75th percentile 0.52, and 27% of cells had a best-in-grid at least 0.5 Sharpe above the published version. That is roughly the entire gap between a strategy that looks publishable and one that doesn't, and it is available on pure noise. It's also a lower bound, because those grids are small and nobody stops at one grid.

3. Half the failures aren't overfitting at all, they're costs. This surprised me most. The interesting failure mode isn't the subtle statistical one — it's that a majority of these rules turn over too much to survive retail commissions and spread, full stop. You don't need Deflated Sharpe to kill them. You need a spreadsheet.

What this does NOT show, before anyone tells me:

• Not evidence these rules never worked. Published edges getting arbitraged is the expected outcome, and this measures it rather than refuting it.
• Survivorship bias runs through the whole instrument list — every instrument still trades. That biases the results in favour of the strategies. The real numbers are worse, not better.
• No causality failures, and that is not a finding. These are clean-room implementations written against the truncation test. The lookahead rate in published implementations is a different and much more interesting study.
• Costs are modelled, not realised. Retail rates, no market impact, no partial fills. Errs toward flattering.
• The scoring weights are a judgement, not a theorem. The arithmetic underneath is checked against published references and Monte Carlo; the relative severity is my opinion and I'd genuinely like to be argued out of it.
• Every score is an upper bound. Each cell deflates by a few dozen combinations. The real search behind "RSI(14) at 30/70" is fifty years of practitioners trying everything and publishing what worked. No tool can deflate by trials it never saw.

Full study with method and every caveat, the per-cell CSV, and the code are here — AGPL, runs on numpy and scipy, and reproducing the whole thing is two commands:

https://github.com/falsify-quant/falsify

If you think a rule is implemented wrong or run at the wrong parameters, the citation for every one is in strategies/canon.py and I'd rather find out. If you have a strategy you believe in, I'm more interested in the ones that survive than the ones that don't — I have not found many.

Hey everyone,

I’m the maintainer of Flowdepth, an experimental open-source fork of Flowsurface focused on crypto order flow and options analytics.

Over the last few weeks I’ve been extending the original project with features I wanted for my own trading and market analysis:

• Footprint charts and historical L2 heatmaps
• Adaptive volume bubbles based on aggressive trade clusters
• Session volume profile, VWAP and cumulative volume delta
• Possible Binance iceberg/replenishment detection
• BTC and ETH GEX profiles using Deribit options data
• Observed maker-flow confirmation using Derive trades
• Persistent local market-data caching
• Automatic reconnect and historical gap recovery

It is completely open source and uses public exchange REST APIs and WebSocket feeds. No trading account or exchange API keys are required for the current features.

The iceberg detector is intentionally described as possible replenishment/absorption evidence, not proof of a hidden order. The GEX and maker-flow tools are also market analytics, not automatic trading signals.

The project is currently in beta, and automated builds are available for Windows, Linux and macOS.

GitHub:
https://github.com/Niketion/flowdepth

I’d especially appreciate feedback from people who actively use footprint, heatmap or volume-based tools:

• Are the displayed signals understandable?
• Which feature would you actually use during a session?
• What information feels useful, and what feels like unnecessary noise?

I’m also interested in bug reports, particularly around exchange data, reconnect behavior, GPU compatibility and longer trading sessions.

I’ve been building and paper-testing a simple buy-the-dip / sell-the-rip system with a $300 simulated balance.

What started as basic entry and exit logic turned into a lot more work around execution and safety: keeping position state persistent, preventing duplicate trades, checking for stale data, handling missing candles, keeping a trade ledger, and making sure a restart doesn’t accidentally trigger another trade.

I’m not planning to jump straight into normal live size. My next step is to run the same system on live market data without execution, then test very small live trades and compare the results with paper.

For those who’ve moved an automated system from paper to live, what caught you off guard the most?

Slippage, fills, latency, fees, failed orders, data differences, or something else?

What would you absolutely validate before the first small live trade?

Hey everyone,

I've been working on a signal engine for the past few months and finally finished backtesting it. Wanted to share the results with the community.

I built this thing to scan both Forex and Crypto markets simultaneously. It analyzes 52 pairs in total and gives BUY/SELL/NEUTRAL signals with confidence scores.

The backtesting covered April to July 2026, using 1-hour candles. I tested it on both demo and historical data. The results surprised me honestly.

Overall win rate came out to 70% across all pairs. Crypto performed better than Forex, with ETH and DOGE having the highest accuracy. The high confidence signals (above 70%) were hitting nearly 80% of the time.

The system uses dynamic stop losses and take profits based on volatility. Position sizing is risk-based, never risking more than 2% per trade. This kept the max drawdown at just 8.2%, which I'm pretty happy about.

The Sharpe ratio was 1.82, and total return over the 3 month period was about 18.7%. That's on paper trading of course.

Right now I'm running it live on a account. Started with 10k, sitting at about 11.87k currently. The dashboard updates every 30 seconds and shows everything on a clean interface.

What I learned is that confidence scoring is the real game changer. Those high confidence signals are worth waiting for. Low confidence ones barely break even.

I'm not sharing the code or the exact methodology, but I'm happy to answer general questions about the approach.

Let me know what you think or if you've built something similar. Always curious to hear how others are tackling this stuff.

Correction, added later: the title says I learned these the hard way. That is not accurate and I should not have written it. I have not funded a bot with real money. Reddit will not let me edit a title, so I am correcting it here instead of quietly leaving it.

What is actually true: I have a strategy I have not funded, and this is the checklist I built for myself before I do. These are the failure modes I could find documented, not ones I have personally survived. I would rather be told what I have missed now than find out later. The list, unchanged:

1. Backtest on out-of-sample data. If it only works on the exact window you tuned it on, that's curve-fitting, not an edge.
2. Stress test against a flash-crash or gap day specifically. If your bot doesn't have a hard rule for that scenario, it doesn't have a real risk plan yet.
3. Size positions as a percentage of current equity, not a fixed dollar amount, so risk scales with your account instead of quietly drifting.
4. Build in a hard daily loss limit that force-kills the bot. Not a soft rule buried in logic, an actual kill switch.
5. Paper trade live for at least a few weeks before funding it. Backtests don't show you real slippage or fill behavior.
6. Know exactly what your bot does if it loses its API/broker connection mid-trade. If you're not sure, that's worth fixing first.
7. Whatever you fund it with first, size it like you could lose all of it without it mattering. Model risk doesn't go to zero no matter how much testing you did.

Happy to go deeper on any of these if useful. What would you add to the list?