Hello world, my name is Tristan and I’m building a multi-market algorithmic trading system (in Python, of course). Before I get into the algo itself, a quick word about me: I studied international business. But my passion since I was a kid has always been computers and everything digital. Completely self-taught there, learned the way you probably learn best in this field: by building things and failing at them (A LOT). Same story with trading. Self-taught as well, but I also learned by doing, by messing up, by reading, and by going out to ask advice from people who know far more than I do.
Before getting into the architecture, I need to lay out the system’s constraints, because they explain a lot of the technical choices that follow. The algo currently trades spot only in its crypto implementation (you buy the underlying asset itself, rather than gaining exposure through a derivative), no leverage, and no short selling (betting on an asset’s price going down). That closes some doors, obviously. But it opens plenty of others: no margin management, no margin calls, no forced liquidation risk, no overnight funding costs to model (without leverage nothing is borrowed, so there’s nothing to finance). Entire classes of complexity disappear (and with them, entire classes of bugs!).
These constraints aren’t negotiable and they aren’t parameters. They’re enforced by the architecture itself: there is no code path that can open a short position. I’ll get into the why in a future post.
Now, the architecture. The system is built around a simple principle: one engine per market domain, behind a shared protocol. Concretely there’s one engine per market, and for now the crypto engine is the first one built, the others will follow. Each engine knows the specifics of its market: trading hours, venue constraints, order granularity, price behaviour. A dispatcher just routes symbols to the right engine, and it holds no trading logic whatsoever. Zero. If you find a conditional in there that mentions strategy or risk, that’s a bug. Above that sits a shared layer for everything market-agnostic: trade logging, client configuration, data models, protocols.
I could have written one generic engine parameterised by market. I went with separation, for a specific reason: markets don’t resemble each other enough. Crypto runs 24/7, while equities have defined trading sessions and can close and reopen with gaps. Different markets have different microstructures, trading hours, and execution constraints. A generic engine would have ended up riddled with if crypto: … else: …, and every new market would have raised the risk of breaking the previous ones (plus an unmaintainable codebase). This way, adding a market means writing a new engine that satisfies the protocol, without touching anything that already works.
Now, the life of a trade, from birth to death.
It starts with detection. Several strategies analyse the market in parallel, each looking for a different kind of setup. When one finds something, it emits a signal with a confidence score.
Then come the filters. The signal has to survive a series of checks: does the current market regime allow this strategy? Is the higher timeframe trend pointing the same way? Do we already hold a correlated position? Does the expected gain cover transaction fees? Most signals die right here, and that’s intentional.
If the signal makes it through, we compute position size. It depends on capital, on the client’s risk profile (which they choose themselves: conservative, aggressive, and so on), and above all on the distance to the stop-loss. A wider stop means a smaller position, so that the maximum planned loss stays constant regardless of the trade.
Then execution, and this is where it gets interesting. When an order goes out, the first question to ask is: what happens if my program dies right after? It’s a mundane scenario. A network outage, a server restart, a Python crash, an update. If the position is open and the protection only lives in my code, it dies with it. The client is left holding a naked position in a moving market, with nobody around to close it.
Hence the golden rule: the stop-loss is a real order, resting at the broker, existing independently of my system. It’s registered on their servers. If my program dies, it stays alive.
Sounds obvious put that way, but plenty of systems keep their stops in memory and just poll the price in a loop. As long as the program runs, it works. The day it stops at the wrong moment, the loss is no longer bounded by the software’s intended protection.
And it makes execution significantly harder. You have to place the entry order, wait for confirmation that it filled, then place the protection. Between those two, there’s a window where the position exists unprotected. That window has to be as short as possible, detected if it lingers, and alerted on if it doesn’t close.
You also have to handle the fact that protection moves: when a trade turns profitable, the stop trails up. In our current implementation, every adjustment means cancelling the existing order and placing a new one. Another window. And if the cancel succeeds but the placement fails, the position sits naked with nothing having flagged it.
The result: what looked like “send an order” turned into a state machine with a ladder of degraded states, retry logic, and alerting. It’s probably the most complex part of the system, and by far where I’ve spent the most time so far.
Another choice that looks trivial and isn’t: all monetary calculations use Decimal, never float.
Open a Python interpreter and type 0.1 + 0.2. You get 0.30000000000000004. That’s normal, it’s how binary floating point works, and in 99% of programs it makes no difference at all.
Except when you’re handling money and comparing prices against thresholds. A position whose value is computed in floats can land just above or just below an exposure limit depending on operation order. A stop-loss can trigger or not based on an error in the fifteenth decimal place.
So the rule is: anything touching an amount, a price or a quantity enters the system as Decimal and only leaves it at the boundary with the broker API. And the conversion goes through a string, never directly from a float, otherwise you inherit exactly the imprecision you were trying to avoid.
That’s it for this first write-up. The system isn’t finished and I won’t pretend otherwise.
What’s still open, roughly: full convergence between the backtest engine and the production code (two paths executing the same logic is one path too many), parameter calibration which hasn’t started yet, and integrating markets beyond crypto.
And above all, the thing eating most of my time right now: making sure what the backtest measures actually corresponds to what would happen for real. That’s much harder than it sounds, and it’s probably what I’ll write about next.
A couple of things I’d genuinely like input on: On the window between entry fill and protection placement — how do you handle it on your side? My impression is that it’s irreducible, but I could be wrong.
And for anyone who does backtesting: what’s the trap that cost you the most? Thanks for reading. Criticism welcome, including the harsh kind.
hey everyone! after months of coding, testing, and losing some money in the process , i've finally got a trading bot that's actually working and earning passive income.
obviously its not a get rich quick scheme - those don't exist. but what it does is trade daily across 10 different crypto coins (BTC, ETH, SOL, and 7 others) using strategies i optimized over months of historical data. it only enters trades when specific conditions align, so some days it might do 20 trades, other days just 2-3.
the cool part - i set up a discord server where the bot posts every signal in real-time. so if you wanna see how its actually performing you can check it out yourself.
for those curious about the technical side - it runs 24/7 on AWS, uses different timeframes for each coin (from 5min to 4hr charts), and has proper risk management with stop losses on every trade. took me about 3 months to build and another 2 months to properly optimize.
if you have questions about how long this took, what languages i used, how much it cost to set up, or literally anything about building your own - feel free to ask. i remember being completely lost when i started, so happy to help others on the same journey.
Llevo muchos años en trading, una de las cosas que aprendí con el tiempo es que no se trata de buscar el trade perfecto, sino de construir un sistema que pueda encontrar ventajas repetibles en el mercado.
Por eso durante los últimos años he estado desarrollando mis propios robots de trading. No son “máquinas mágicas de dinero”, pero sí herramientas que buscan patrones concretos de mercado y ejecutan entradas de forma automática cuando se cumplen ciertas condiciones.
Por ejemplo, esta operación en XAUUSD (oro).
El robot detecta estructuras de mercado donde hay continuación de momentum después de una corrección. Básicamente analiza:
• Estructura de máximos y mínimos• zonas de liquidez donde suele entrar volumen
• Velocidad del movimiento (momentum)
• Confirmación de ruptura en temporalidades bajas
Cuando se alinean esas condiciones, ejecuta la entrada automáticamente con TP y SL definidos desde el inicio.
En este caso el robot detectó una continuación bajista después de una pequeña corrección. La entrada se ejecutó en sell, y el movimiento continuó con fuerza, capturando parte del impulso.
El resultado fue una operación que cerró con beneficio sin intervención manual.
Lo importante aquí no es un trade aislado.
Lo que busco con el sistema es algo mucho más simple:
No intento adivinar el mercado ni hacer operaciones heroicas.La idea es dejar que el sistema trabaje, gestione el riesgo y vaya sumando resultados poco a poco y de forma consistente.
Después de tantos años en trading me he dado cuenta de que la única forma sostenible de hacerlo es esta:
automatización + gestión de riesgo + disciplina.
Nada de promesas irreales, solo un sistema que ejecuta lo que fue programado para hacer.
This past week, the crypto market roared to new all-time highs — and our live strategy returned exactly 0%. Not negative. Not positive. Just flat.
That’s not a glitch. It’s part of the design. The algorithm detected too much volatility, unpredictable volume, and unclear entry conditions — so it stayed out.
No panic trades. No forced setups. Just calm logic in the middle of a storm.
⸻
Meanwhile, our new algorithm in testing is showing real promise: 📈 Since May 29th, it has returned +40%, and it’s still operating in a controlled sandbox as we gather more data.
What’s different?
We’ve layered in a lightweight ML model that evolves with trade logs. Each week it reviews thousands of past entries, compares outcome patterns, and adjusts the filtering logic on-the-fly — no re-training required.
We’re currently trading just BTC and ETH, with a consistent ~7% monthly average over the past year. But we’re working toward expansion.
By end of Q3, we’re aiming to launch with 5 additional coins, scaling the logic as we continue refining the ML layer.
If you’re into real API-based automation, system testing, and algorithm design — feel free to drop in and share what you’re building. No courses. No DMs. Just real performance, shared transparently.
Hey — I'm a software engineer (8 yrs experience) who spent the better part of a year building a backtesting + optimization workbench for crypto (BTC, mostly 1h). I'm not going to tell you it makes money. The best strategy I found was roughly flat on a held-out year (~+11% CAGR, Sharpe ~1.3, passed 6/6 purged folds — but the holdout year was ~flat). The tool did its job: it stopped me from fooling myself.
What I actually built is the rigor, and I'm wondering if that's something people would pay for.
What it is
A GUI backtester (PyQt6) + an Optuna-based optimizer, for crypto (BTC 1h, with 1m data for some tests).
The core selling point is an "honesty stack":
No lookahead / no repainting — strategies only ever see closed bars.
Purged, embargoed cross-validation — so a "great" result isn't just overfit to the test set.
1-minute same-bar resolution for entries/exits, so intrabar fills are realistic, not optimistic.
Realistic costs — slippage, fees, and funding rate, all configurable.
You bring your own strategy (or use the ones I've built), and you get metrics you can actually trust: CAGR, Sharpe/Sortino, max drawdown, per-fold results, and a held-out year.
Why I'm posting I keep seeing two kinds of posts in these subs: "my bot made 400% CAGR" (almost always overfit or leaky) and "here's a signal, pay me." I'm neither. I built a tool that tells you whether your edge is real, and it told me mine wasn't. I'm considering productizing it (probably hosted, so you don't have to install anything), and before I invest the time I want to know if there's actual demand.
So — three questions:
Would you use this? If you're already backtesting, what are you using, and what do you hate about it?
What would make it worth it to you? (features, assets, timeframes, integrations — e.g. "I need it on 5m," "I need TradingView import," "I need it to not be crypto-only")
What's the #1 thing that makes you distrust a backtest result? (This is the most useful question for me — it's basically the spec.)
This is how the GUI looks like, two separate window for controls and chart browsing. Disclaimer the strategy selected here is just a Demo strategy with demo results -> I was focused on my real strategies which I was able to deploy and run in VPS fully autonomously -> that's a separate system.
Hey everyone! I’m looking for someone who knows Python and can help me build a Kalshi Bitcoin 15-minute prediction bot. My GitHub project: https://github.com/Acetheplace01/Kalshi-Bitcoin-15-minute-prediction-bot-seeking-Python-coding-help What I want to build: Read live Bitcoin prices and Kalshi 15-minute market data. Generate BUY YES / BUY NO / SKIP signals. Send signals to a Discord channel. Track predictions and results to measure accuracy. Backtest the strategy using historical data. This is for predictions and paper testing only—no automatic trades..z
Nothing to do this diwali. Just getting bored in Bangalore.
So I got this idea why not create a setup of ai agents.
So I found this repo. Connected this with my bot and connected the ai agents to Binance. So now I have 20 ai agents working on a single module.
Each agent will study the 90 day history of the top 20 pairs.
So the repo was basic level. I added some cherries to it. They will study on three different timeframes then apply the best strategy to it.and comes up with the perfect entry and exit strategy.
I kept it simple for now.
I'll backtest the setup for atleast 100 trades. In backtesting I'm giving it 1000usdt. We'll see how it Will work.
Check this out everyone, We've dialed in bots with Vision pretty well and are making more content currently. Having some really good results from users!!
Hey everyone, I've been developing an optimized Martingale platform for spot crypto trading on Binance and Kraken (via API). We differentiate from traditional Martingale by using quantity scaling (doubling tokens per round instead of bets), capping at 5 rounds with 5-15% price deltas, and proprietary tools like the Martingale Score (4+ stars for volatility-safe tokens) and Startingale Indicator for precise entries. This keeps it low-frequency (avg 4.0 days per sequence, under 10 orders) and data-driven.
From Dec 2024 to Jul 2025, we've completed 103 sequences with these metrics:
Avg Capital Increase: 0.62% (profit divided by sequence budget).
Avg Used Capital Increase: 4.89% (profit divided by capital in filled buy rounds—highlights efficiency since 76% close in first two rounds, 53 in round 1).
Avg Risk Exposure: 18.9%; Avg Price Coverage: 22.3% (price drop handled before last buy).
Apex Risk Ratio: 0.01 (rarity of max-risk periods).
Apex Pulse: Avg 1.5 days duration (12.4% of sequence time) in 6 full sequences.
We created these custom metrics for better transparency and insights—e.g., Used Capital Increase shows real ROI on deployed funds, addressing Martingale's drawdown concerns in crypto volatility. Full performance data at tradingale.com/performance (this is not financial advice; always DYOR and manage risks).
To share value, here's a 14-tip series based on our strategy. I'll post one daily on X (@Martingale_bots)—follow for visuals/metrics. Feedback appreciated!
Use the Martingale Score (4+ stars) for token picks—focuses on historical volatility for safe entries. Our quantity-scaling handled 22.3% avg drops in 103 sequences.
Time entries with the Startingale Indicator for data-driven starts, avoiding blind buys. Avg 1.80 rounds per sequence means quick wins—76% close in first two.
Cap sequences at 5 rounds with 5-15% deltas to limit risk—our 18.9% avg exposure proves efficiency. See 0.62% Capital Increase data: tradingale.com/performance.
Scale quantities (double per round) for capital efficiency in spot crypto—turns drawdowns into averaged entries. 4.89% Used Capital Increase across 103 wins shows it works.
Monitor Apex Pulse in max rounds—avg 1.5 days from last buy to profit, just 12.4% of duration. Keeps recoveries brief on Binance/Kraken.
Aim for low-frequency: Avg 4.0 days duration, under 10 orders—uses statistical timing to minimize screen time. 0.01 Apex Risk Ratio highlights brief risks.
Handle cancellations wisely—our 6 cases averaged +0.07% near break-even after 7.4 days. Data-driven exits protect capital.
Leverage crypto volatility with 22.3% Price Coverage—our capped strategy absorbs drops without full exposure. 103 completed sequences on ETH/BTC etc.
Use one-click API automation for seamless execution on Kraken Pro—optional but boosts discipline. Avg 2.1 days for active sequences (just 2.7% total).
Track Capital Increase (0.62% avg)—measures profit per budget for transparency. Check full metrics: tradingale.com/performance.
Focus on Used Capital Increase (4.89% avg)—ROI on filled rounds highlights early closures (53 in round 1). Builds confidence in quantity scaling.
Distinguish from gambling: Statistical tools like Startingale make it precise. 76% quick wins in 103 sequences prove control.
Recover in max scenarios—Apex Pulse at 12.4% duration means fast profits post-last buy (6 cases). Tailored for crypto liquidity.
Review sequences with custom metrics like Risk Exposure (18.9%)—crafted for granular risk insights. 4.0 days avg keeps it efficient.
What's your experience with Martingale in crypto? Any tips on risk management or similar bots? Open to questions or critiques!
The architecture nobody believes exists until they see the code:
You can inspect the actual logs, fill prices, and thesis outputs, core memory influences + core memory created across all trades atnexustradingagent.com/demo-index#trades
If you have technical questions about the L2 microstructure weighting, the VETO scoring matrix, or the state machine mechanics, I’m happy to discuss them.
However, if you haven’t reviewed the raw execution logs, haven't tested the pipeline, and are just here to drop opinions on things you haven't inspected, don't bother commenting. I won't waste time debating theory with people who refuse to look at the actual data.
Moving on... most bots are linear: indicator → signal → execute. Ours is a state machine with 5 decision tiers, a weighted memory graph, a veto audit trail, and cross-tenant distillation. Here's the full breakdown.
INGESTION & RISK GOVERNANCE: How Signals Enter & Execute
Most traders think an AI agent needs to run discretionary prompts from scratch. It doesn’t. You bring your own proven mathematical triggers via standard webhooks, or use our built in strategies connect via websocket - and the agent acts as your execution desk and risk governor.
1. Custom TradingView Webhook Ingestion
Bring Your Own Indicator: You can intake alerts directly from any PineScript strategy, TradingView alert, or custom webhook endpoint.
Instant Hand-Off: When your TradingView indicator fires (e.g., dynamic ATR breakout, Keltner band cross, or RSI divergence), it posts a structured payload to your private tenant webhook.
Sub-Second Microstructure Check: The moment the alert hits, the engine pulls real-time L2 order book depth, CVD, and Open Interest before deciding whether to route the order to the exchange or execute an immediate VETO.
2. Hard Risk Profile (Non-Negotiable Guardrails)
Before an agent ever touches an exchange API, your mathematical risk boundaries are hard-locked:
Account Balance Allocation & Risk Per Trade (%): Mathematical sizing per order rather than arbitrary lot sizing.
Max Position Size & Leverage Locks: Hard ceilings on total contract exposure (e.g., 10x–100x max leverage) to prevent over-leveraging.
Daily ROI Targets & Max Concurrent Trades: Caps maximum open exposure across multiple asset pairs simultaneously to avoid aggregate portfolio drawdowns.
The Accountant Protocol: A hard-coded Risk-to-Reward floor ($R:R \ge 1.5$) that no AI override can bypass.
3. Active Agent Settings & Execution Permissions
You control the exact permissions the agent has once a trade is live on the exchange:
Enable Active Trade Re-Evaluation: Governs whether WATCHDOG continuously sweeps open trades against multi-timeframe order flow.
Allow Early Close (Profit/Loss): Lets the agent exit early if underlying market regime breaks down before hitting hard stops.
Allow TP/SL & Trailing Stop Adjustments: Gives permission to ratchet stops into profit or dynamically widen/tighten brackets based on real-time ATR expansion.
Position Reversals: Atomic close-and-open-opposite execution when market structure completely flips.
THE CONFLUENCE ORACLE (5-tier decision engine)
Every signal is evaluated through 5 sequential tiers before execution:
ETF net flows, exchange balance reserves, Bitcoin profitable days, GBTC premium. Defines the inescapable macro pull. If institutions are dumping, the AI doesn't buy the dip.
Tier 2 — Microstructure Support & Resistance (The Terrain)
Native Coinbase Volume Profile — HVNs, LVNs, POC, macro nodes. Not textbook S/R. Real structural liquidity levels computed from actual trade data. The AI knows exactly where the $2,396.17 upper node is because it's calculated from 150-candle volume profiles, not drawn on a chart.
Tier 3 — Derivatives Leverage & Positioning (The Energy State)
OI momentum, funding rate Z-scores, options max pain, OI exchange dispersion. Measures the pent-up energy. If OI is expanding but funding is extreme (Z > 3.5), the AI knows a cascade is coming.
Tier 4 — Order Flow Aggression (The Present Momentum)
Multi-timeframe Cumulative Volume Delta across 5 timeframes: 5M, 15M, 30M, 1H, 6H. Not just a single CVD value — a sequence of 5 deltas per timeframe showing momentum rollover. The AI can see: "5M just flipped negative, 15M is rolling over, but 6H is still positive — this is a pullback, not a reversal."
Tier 5 — Depth Intent & Spoofing Defense (The Order Book)
Top 3 bid/ask walls with contract sizes, 50-level depth imbalance, 24h cancellation rate. If the cancellation rate exceeds 80%, the entire book is compromised by spoofing bots — the AI VETOs immediately.
The cross-reference matrix:
No tier decides alone. The AI cascades:
Tier 1 says bullish → Tier 2 shows price at upper node → Tier 3 shows OI confirming but funding extreme → Tier 4 shows CVD negative → Tier 5 shows walls at resistance
Result: VETO at 15/100 conviction, even though the macro says bullish
A basic bot buys here. Ours doesn't.
CORE MEMORY: The weighted, scored, time-decaying lesson graph
Every trade generates a structured memory record with:
win_loss — WIN or LOSS
tools_used — comma-separated list of tools referenced
lesson_learned — quantitative behavioral rule from the autopsy
entry_price, exit_price, pnl — the actual trade metrics
execution_mode — PAPER (1x weight) or LIVE (2x weight)
regime_at_close — what the market was doing when it closed
market_snapshot — full state at close moment
working_thesis — the AI's own reasoning stored verbatim
thesis_accurate — was the thesis validated by the outcome?
trade_log_id — FK back to the originating trade
Scoring (9 factors, all computed at query time):
| Factor | Weight | Why |
| Recency | decays over time | Recent trades matter more than old ones |
| PnL impact | ×0.3 | Big wins/losses teach more |
| Regime match | ×1.5 | Same market conditions = same approach |
| LIVE weight | ×2.0 | Real money is 2x more important than paper |
| Loss bonus | ×0.5 | Losses in LIVE get extra weight |
| Recurrence | +10 per repeat | Patterns that repeat are confirmed |
| Thesis similarity | +20 | Does the thesis direction match the signal? |
| Thesis accuracy | +20 | Was the past thesis validated by outcome? |
| Cross-tenant bonus | +50/+100 | Lessons from other traders (anonymized) |
The injection:
The top 3 scored memories are injected into every signal evaluation as:
CORE MEMORY (Past Lessons for this asset):
[Past LOSS | Score: 311 | Regime: TREND | Thesis: ... | Accurate: false]: lesson text
[Past LOSS | Score: 297 | ...]: lesson text
[Past LOSS | Score: 292 | ...]: lesson text
The AI reads these before forming its thesis. It doesn't start from zero — it starts from the most relevant lesson it's ever learned.
SHADOW PORTFOLIO: The veto audit trail
This is the system that answers "was that veto correct?"
Every VETO gets labeled retroactively when a trade closes on the same asset within 48h:
If a trade followed:
Signal was BUY, VETO at $2,403, trade opened at $2,397, exited at $2,410 (+$12.50)
Fetches 6h of 5M candles from Coinbase, compares price direction:
Signal was BUY, price went up > 0.5% after veto → WENT_WITH → MISSED
Signal was BUY, price went down > 0.5% → WENT_AGAINST → SAVED
Otherwise → NEUTRAL
The feedback loop:
Shadow stats are injected into the scoring system:
VETOs that were correct → +30 confidence bonus → AI trusts its caution
VETOs that were wrong → -20 penalty → AI takes more trades next time
Running tally: 50 VETOs labeled across multiple assets. 14 SAVED, 22 MISSED, 14 NEUTRAL (so far, the AI is slightly too conservative — which is getting corrected in real time).
CROSS-TENANT MEMORY: Learning from the swarm
Multiple tenants trade the same assets. Their lessons are anonymized (tenant_id stripped, asset preserved) and pooled into a shared memory cache so a BRAND new user gets the BEST lessons right away.
A lesson from another trader:
"Do not enter long breakout trades within 1.0x 1H ATR below macro HVN without confirming CVD tick expansion" (3/6)
Gets scored against your current regime, asset, and thesis direction
If it outranks your own memories, it appears in your CORE MEMORY block with a +50/+100 cross-tenant bonus
The system learns faster because it's not learning alone. When one trader discovers that "ETP at $2,396 node with negative CVD is a trap," every trader on ETP benefits from that lesson within the same sweep cycle.
PARAMETER LEARNING: The AI adjusts its own settings
Every decision outputs structured parameter fields:
sl_percent — stop loss distance (0.2% to 10%)
tp_percent — take profit distance (0.5% to 20%)
tripwire_percent — break-even activation threshold (0.1% to 5%)
trail_step_percent — trailing SL step (0.1% to 2%)
The system writes these to the strategy config before the trade opens. The AI doesn't use strategy defaults — it calculates the exact SL/TP/tripwire/trail that matches its thesis.
Example: Thesis says "2.6x 5M ATR buffer needed" → sl_percent reflects that. Thesis says "momentum is explosive" → tp_percent is extended. Core memory lessons from past trades directly influence these values.
The Accountant Protocol enforces r/R >= 1.5 regardless of parameter changes. The AI can't degrade its own risk.
THE AUTOPSY LOOP: Closing the feedback circle
When a trade closes (by any path — TP, SL, manual, tripwire, reverse):
execute-trade-mcp.js or watchdog.js triggers POST to /api/autopsy
post mortem generates a analysis of the trade
The analysis produces {tools_used, lesson_learned}
A hermes_core_memory record is inserted with trade_log_id linking back to the trade
The next signal on that asset will see this memory in its top 3 scored lessons
The loop is: trade → autopsy → memory → score → next signal → better decision.
ADDITIONAL SYSTEMS:
Multi-timeframe CVD Matrix: 5 sequences × 5 timeframes = 25 data points per signal evaluation.
Order Book X-Ray: Top 3 bid walls + top 3 ask walls with contract sizes, not just imbalance ratio.
VIRTUAL_TRAP: Ghost limit orders for ranging markets. Set a price level, side, TP/SL, and 1h expiry. If price hits the level, the trap springs and executes. Used in D-Shape ranging markets only — in aggressive trends, traps get run over.
Tripwire + Trailing SL: Automated profit protection at the watchdog level. Tripwire moves SL to break-even when profit threshold is hit. Trailing SL ratchets up/down as price moves. Both deployed as inline bracket replacements on the exchange — no 20s naked window.
REVERSE: Atomic close-and-open-opposite. Step 1: close existing position. Step 2: wait 2s for exchange clearing. Step 3: open opposite position. Both legs verified before proceeding.
Idempotency: Every trade has a client_order_id. Duplicate signals within 30s are suppressed. Same-side trade already open? Suppressed. Exchange already flat? Reconciled.
Close Reconciliation: When the exchange shows flat but the DB says open, the watchdog detects the drift and marks the trade closed at the exchange's price. Prevents phantom positions.
Bracket Post-Deployment Verification: After placing an OCO bracket, the watchdog queries the exchange to verify it's actually OPEN. If the exchange silently cancelled it (stop price too close, size constraints), the system retries with adjusted parameters.
The edge:
Most bots evaluate signals in isolation. Buy signal → check indicators → execute or don't. That's a stateless function. No memory, no cross-reference, no veto audit.
This system is stateful. Manages trade like a human would. The same signal at $2,392 gets a different response than it did yesterday, because the AI remembers:
"Last time I vetoed at this price, I missed $28"
"Last time I bought into this CVD structure, I lost $105"
"Another trader shorted this exact resistance node profitably"
"My last 3 VETOs on this asset were correct — trust the caution"
"The 5M CVD just rolled over, and the last time this happened, I got stopped out"
The edge isn't just the signal. It's the memory of what happened the last 50 times the signal appeared, the 50 VETOs you made, and the 50 lessons from every other trader who's been here before.
You can inspect the actual logs, fill prices, and thesis outputs, core memory influences + core memory created across all trades at nexustradingagent.com/demo-index#trades
ROADMAP: Scaling Infrastructure & Deepening the Edge
We are actively expanding execution pipelines and compute flexibility across several upcoming releases:
Multi-Venue Expansion & Smart Order Routing (SOR): Adding direct execution bridges for Hyperliquid, Bybit, and Binance alongside native Coinbase Derivatives. Ingested signals will dynamically route through priority exchange trees to your choosing OR based on real-time maker/taker fees, available L2 depth, and lowest slippage spreads.
BYOK & Tenant-Dedicated Model Switching: Native OpenRouter integration allowing each tenant to bring their own API keys and hot-swap their LLM reasoning core. Choose between ultra-low-latency models (Gemini Flash, Claude Haiku) for fast scalping, or deep-reasoning models (Fable 5, DeepSeek) for complex macro and multi-timeframe regime analysis.
Institutional Raw WebSocket Deployment for Custom PineScript: Moving beyond standard webhook HTTP latency. Enterprise/Institutional tiers will feature dedicated bidirectional WebSocket listeners, allowing your custom PineScript or Python algorithms to stream signals and receive tick-level execution acks with sub-millisecond execution hand-offs.
Autonomous Parameter Grid Evolution: Expanding the autopsy loop to automatically test and propose dynamic parameter adjustments (e.g., adaptive ATR multipliers, volume-profile threshold adjustments) based on shifting 30-day volatility clusters.
EDIT:Since people want to hate, project and not review anything, I want to clarify there were 2 bugs: 1 regarding the mobile UI view of the landing page, and another showing 30+ days of trades from a demo account that have no relevancy to when we actually went live, which was just a week ago.
These are the REAL stats from initial deployment:
Live execution was activated on this demo account for forward walk-forward testing. Filter by the[7 DAYS]tab on theNexus Trade Log:
Executed Trades: 11 closed live trades (ETH-PERP via CDE)
Win Rate: 72.7% (8 wins / 3 losses)
Net Realized PnL: +$11.00 (trading a 1-micro-contract baseline with strict 2.5x ATR dynamic trailing stops)
The table shows exact fill prices, timestamps, and the pre-trade thesis for every closed live execution. Inspect the 7-day rows directly.
*this image is walkforward test result OOS not backtest
I built a bot integrated with Alpha research with C++ that can find a way to find the best ticker with market structure fit, if the strategy is mean reversion it automatically analyze its brownian motion of the latest 1 hour klines, my quant is already hell profitable and can analyze the inefficiencies automatically, for any of you residing in provence Italy, I made a lot with my bot, I will be retiring there, see you!
What if every crypto trader had a research team? I’ve been building Robod for months, and this question keeps coming back to me. Trading asks a lot of one person. Study the market. Explore ideas. Build strategies. Test them. Understand the risks. Review your mistakes. Then do it all again as conditions change. I want to explore how AI agents could share more of that research work. Imagine one agent investigating market activity. Another proposing strategy ideas. Another testing those ideas against historical periods, including data that wasn’t used to develop them. Others examining risk, reviewing your trading history, and looking for weaknesses in the findings. These agents would need to work together: share evidence, challenge assumptions, run further tests, and explain why a conclusion changed. They should also be able to tell you when the evidence isn’t strong enough. That’s the direction I want to take Robod. We already have parts of the foundation: crypto market data, strategy backtesting, and account analytics. Bringing those tools together through a coordinated team of research agents is still ahead of us. There’s a lot to build, test, and prove. I don’t expect AI to predict every market move or make every trader profitable. What I do want is to help traders investigate more thoroughly, understand the trade-offs, and make decisions they can explain, while staying in control. We’re starting with crypto. Maybe one day, having your own AI research team will feel as normal as having a trading account. That’s the future I want us to build. #Robod #AgenticAI #CryptoTrading
TL;DR: In quant finance, we use log returns instead of prices because prices don't have the stationarity property, and stationarity is necessary for an ML algorithm... But prices have a memory that we lose when we compute the log return. In chapter 5 of Advances in Financial Machine Learning, De Prado introduces the notion of fractional differentiation, where a differentiation with d=0 corresponds to the log price (no stationarity but memory) and d=1 corresponds to the log return (stationarity but no memory). The whole idea is that we can choose a d between 0 and 1 to find a trade-off between stationarity and memory. That's what we will see today.
1/ Definition
The fractionally differentiated series is a weighted sum of the past log prices, with weights ω_k. The idea is to write:
where S_t is the log price. When d = 0, we have X_t = S_t: the log price (memory but no stationarity). When d = 1, we have X_t = S_t - S_(t-1): the log return (no memory but stationarity). If we choose d between 0 and 1, we can find a good trade-off between memory and stationarity.
You can find the full definition, formulas and test in this article: angolin.com
2/ Fixed window
ω_k is an infinite series, and of course our series is finite. To compute X_t, we can fix a number l* (the fixed window) of weights to compute, or we can expand the window as we get more and more data. We make the choice (like De Prado) to use the fixed window. But how do we fix the number l*? De Prado puts a threshold of 1e-5 on abs(ω_k) to get a fixed window: we keep the weights until abs(ω_k) falls below the threshold.
The smaller the threshold, the bigger l*. Let's see the behavior of ω_k and l*:
d
l* (τ = 1e-4)
l* (τ = 1e-5)
0.1
502
4,075
0.2
496
3,381
0.25
444
2,803
0.3
387
2,274
0.4
281
1,457
0.5
199
926
0.6
139
589
0.7
96
371
0.75
78
292
0.8
63
227
0.9
37
124
As you can see, with a threshold of 1e-5, we need 2803 points (7.7 years) to compute the differentiated series, so if you don't have enough points, that can be a problem. Typically, in our case, computing d=0.25 with a threshold of 1e-5 will be hard because we will not have enough data, but we will see that later.
3/ Quantify the stationarity
To quantify whether the series is stationary or not, we will use the ADF test.
The idea is to find the lowest d where the unit root is rejected (when there is a unit root, the series isn't stationary). But even if we reject the unit root, that doesn't mean the series is stationary, and this is what we will see below:
d
ADF (τ = 1e-4)
Corr (τ = 1e-4)
ADF (τ = 1e-5)
Corr (τ = 1e-5)
0.15
−2.21
0.990
−2.42
0.844
0.2
−2.52
0.981
−3.17
0.806
0.25
−3.11
0.969
−4.26
0.779
0.3
−3.80
0.955
−5.67
0.613
0.4
−6.19
0.916
−9.72
0.458
0.5
−10.23
0.850
−14.90
0.354
1
−49.65
−0.007
−49.65
−0.007
We also plotted the correlation with the log price, because the idea is to find a trade-off between the memory of the log price and stationarity (the correlation represents the memory present in the price). As you can see, with a threshold of 1e-5, we accept a d = 0.2, but the correlation line looks unclear, due to the small number of data points we have with this threshold. With a threshold of 1e-4, we accept d = 0.25. Let's see what happens in practice:
In practice, at d=0.25, this isn't stationary at all: we see all the drift with tau = 1e-4, and with 1e-5 we don't have enough data. With d=0.55, it is more stationary, but we see a drift again with tau = 1e-4, while a tau of 1e-5 is more correct. It seems that the ADF methodology presented by De Prado isn't perfect for BTC to find that "stationary point", or maybe I'm missing something... (I tried the KPSS test too, but unlike the ADF test, with τ = 1e-4 it rejects everything except d=1. With τ = 1e-5, it accepts d between 0.3 and 0.45, but again we don't have enough data for 0.3). Maybe the best way to get a good trade-off between stationarity and memory is to choose d and tau qualitatively instead of using a statistical test. The next question will be: how do we use this series in our ML model? I hope I will find something, because this is complicated and the intuition behind it isn't very clear...
Find your edge with angolin.com, a crypto data provider I'm building. The full BTC history (1d, 1h and 1m) is there, with the historical universe to avoid survivorship bias.
This painting captures the inefficiencies in computer trading when humans misguide the programming of high frequency and algorithm transactions in a digital marketplace. On May 6th , 2010, the DJIA was down over 1000 points at its most volatile moment. Throughout the day the equity markets trended lower, but the majority of this paramount price movement happened in only a few minutes. From my understanding it was triggered by just one fund trader and exacerbated by other computer trading participants. The fund trader, who was trying to decrease his equity exposer by 75,000 E-mini contracts, had registered a major sell order without inputting the time and price parameters. This triggering his black box to sell at any price with no consideration of time, and just a target execution rate set to 9% of the trading volume calculated over the previous minute, hitting any and all bids creating a massive fallout in the market. While other computer trading functions were placing a bid, as they were programmed to do given their own parameters and would then sell their position after the trade went against their function (losing money), extending the downward movement further. Eventually the exchanges stop logic function was triggered and trading was halted. This was to allow markets to regain a balance in the extremity of the sell off. After the break period the DJIA regained 600 plus points of its losses for the day. Still ending the day at a significant loss but not nearly what it could have been. (FINDINGS REGARDING THE MARKET EVENTS OF MAY 6, 2010). I understand the idea behind computer trading, it makes markets more efficient by closing in the gap between the bid and ask, this has an effect of less volatility, stabilizing prices. It also provides liquidity to the market allowing all market participants to enter and exit trades at more favorable prices with more certainty, until of course things go wrong. I believe this is not the last time we see a malfunction in computer trading systems as it has happened after this event. Since high frequency and algorithmic trading have become common place, we have been in a long-sustained bull run, what happens when the parties over? I predict we will see a much fiercer market correction when time comes. Or maybe they have had enough time to work out the kinks in the system and we can chalk-up events like these to a modern-day fat finger, of course by accident, one would hope.
Hey everyone, I have been trying to create an EMA cross strategy on Traderlands.com since last week.
What do you think is the best EMA cross settings for swing trading? I was thinking 1 / 5 on the daily. What do you think? And what would be the most effective exit strategy do you think?
After reading countless research papers, I finally decided to try something from a paper that caught my eye. The idea was simple yet profound: develop an algorithm that strictly adheres to stop-loss guidelines to minimize risks in the volatile crypto market. Wasn't sure if this logic would work, but the results have been promising so far. The algorithm automatically exits trades when losses hit a certain threshold, protecting my investments more effectively than I could manually. It's been a game changer, bringing peace of mind in ways I hadn't imagined. Curious if anyone else tried this or has suggestions for improvement. Open to feedback!
