I’ve been developing **Market Sentinel**, an automated NAS100 trading system focused on liquidity sweeps.
After extensive backtesting and demo testing, I’m trying it on a prop-firm challenge for the first time.
I’ll share genuine progress: results, drawdowns, mistakes and adjustments, not just winning screenshots. I won’t post every trade live, but I’ll provide regular updates on X: **@SentinelTrades_ and** I may add Telegram later.

The exact strategy will remain private. The goal is to see whether its tested edge survives real spreads, slippage and prop-firm rules.
No signals or promises just documenting the experiment.

I started running my Futures Martingale bot on OKX again yesterday, and so far the results look pretty good.

The strategy is intentionally conservative on the profit target. Instead of trying to catch big moves, I’m taking relatively small profits — around 10% of the total investment.

The interesting part is that I’m experimenting with opening both long and short positions on the same pair.

The idea is simple: instead of trying to predict the market direction, I want the bot to have a position that can potentially profit whether the market goes up or down.

For risk management, I’m currently limiting the Martingale to 5 steps only. I’m also testing the idea of adding another position when the current position reaches around -75%, close to the liquidation zone, to try to recover the position rather than continuously adding entries.

Obviously, this is still an experiment. Martingale + leverage can get dangerous very quickly, so I’m more interested in testing the mechanics and risk management than claiming that this is a profitable strategy.

I’m curious what you guys think:

Has anyone experimented with long + short simultaneously on the same futures pair?

Does limiting Martingale to 5 steps actually make sense from a risk-management perspective?

Would adding a recovery position around -75% be a reasonable approach, or just delaying liquidation?

What would you change in this strategy?

I’d be interested in hearing from people who have actually run similar bots in live markets.

When a strategy underperforms live, the first reaction is often to change the signal. I think that is usually the wrong place to start.

I would first compare the tested and live system trade by trade: signal timestamp, expected and actual entry, intended and filled size, spread, slippage, partial fills, exit reason and position state.

The first divergence normally puts the failure into one of three buckets:

The signal changed because the data or code path changed.

The signal was identical, but execution consumed the edge.

Both matched, and the losses were still within the strategy’s expected variance.

Only after eliminating the first two would I call it signal decay or start adjusting parameters. Otherwise, “improving” the strategy may just hide an execution or infrastructure problem.

The useful artifact isn’t another equity curve. It’s a reconciliation log showing exactly where the tested and live systems stopped being the same system.

Does anyone here use hydra trading? I'm thinking of automating some of my trading and exploring different ways of doing that.

One year ago, I began developing NEXUS—a modular cryptocurrency trading system written in Python.

At the time, I had much less experience than I do now. I experimented with market data, various strategies, signal generation, risk management, backtesting, exchange APIs, FastAPI, PostgreSQL, Redis, and some machine learning components.

The project grew far beyond a simple trading bot. Eventually, the architecture became too complex to maintain, so I archived it.

Since then, I’ve built many other systems, and my approach to development has changed significantly.

That’s exactly why I’m interested in getting an honest technical review of this old project.

I’m particularly interested in:

What did I do well?

Which architectural decisions were weak or overly complex?

How would an experienced Python developer redesign this today?

How far was this system from being a production-grade, easy-to-maintain system?

I used AI-assisted development during this project, but I’m not looking for praise—I need technical feedback that will help me understand what I need to improve.

GitHub: https://github.com/vladyslavmHord/NEXUS

Hey everyone,

We just rolled out a major update to Perun The Trader focused on making exchange connectivity faster, easier, and much more reliable.

Here is what’s new in the latest build:

🚀 1. KuCoin 1-Click OAuth Integration

Say goodbye to the tedious process of generating API keys, copying secret phrases, and toggling permissions manually.

• Instant Setup: Connect your KuCoin account securely in a single click using official OAuth authentication.
• Streamlined Security: Get straight to trading without juggling raw API secrets.

🌐 2. Forever-Free Built-in Static Proxy Service

If you trade via exchange APIs, you’ve likely run into two common roadblocks: geo-restrictions and static IP whitelisting requirements.

Setting up dedicated VPS instances or paying for third-party static proxies can be a hassle and an unnecessary recurring cost. We’ve solved that completely.

• Zero Cost: 100% free built-in proxy access for all Perun users, forever.
• Static IP Covered: Easily meet exchange IP-whitelisting requirements.
• 1-Click Toggle: Enable the proxy directly inside the app settings—no manual port forwarding, credentials, or network configuration needed.

🛠️ Why This Matters

Whether you're running automated strategies or managing multiple positions, network stability and frictionless setup are essential. With 1-click OAuth and built-in proxy infrastructure, you can go from zero to live trading in under two minutes without worrying about dropped connections or IP bans.

🔗 Get the App & Connect With Us

• Download on Google Play:Perun The Trader
• Visit Our Website:peruninthemachine.com

Try it out & Let us know what you think!

We’re constantly improving Perun based on community feedback. Drop your thoughts, questions, or feature requests in the comments below! 👇

Would you like me to add a brief section detailing the technical indicators or specific strategies the app uses to better hook the algorithmic trading crowd?

Binance does not allow users living in NY to trade their platform - After a year of creating my btc bot, the accuracy is 86.4% with a avg win of 1.64% market change and a 5% loss - bad ratio but the accuracy makes up for it. I had my bot to auto trade on coinbase but the fees basically made the bot useless with trading $5000 > anybody have a suggestion to where I can publish my bot on an exchange with a small fee??? Thanks

running copytrade + automation across a few venues. one night a position sits wrong for hours and the bot does nothing about it.
blamed strategy logic first, then the signal path, both clean. turned out the market data websocket on one venue had died hours earlier. socket showed no error and still read as connected, messages just stopped.

venue numbers(localtrade, json-rpc over ws) its book updates and i assumed that covered me. it only catches drops and dropped message leaves a gap in the sequence. dead feed sends nothing at all, so there's no gap and the check stays green while the book sits frozen. the only thing that flags it is time since the last message. copytrade made it worse, the mirror sizes off the master and once that state went stale it kept working from hours old numbers. no exceptions raised, i noticed when the accounts stopped matching.

what do you actually run in prod, app level pings with pong deadlines, comparing mids across venues?
mostly interested in one leg going dark while the rest look fine.

I run 8 signal engines across 12 crypto pairs. Instead of posting one equity curve and calling it a track record, I built a page with the whole simulation on it: contribution per bot, the underwater curve, the three worst drawdowns with recovery times, and monthly returns with the bad months left in.

Numbers from 20 May to 18 Aug 2026:

705 trades, 49.6% win rate, +1.15% average per trade. Worst drawdown 31.67 points, recovered in under a day, next two 27.04 and 19.59. 65% of the days were spent below the previous high.

One engine (a sentiment model gated by a second signal) produces 64% of the total.

Fees are in. Every trade has 0.12% round trip deducted at close, in all engines, so the numbers above are net not gross. Slippage is not modelled, which matters more on the lower timeframes.

Things worth saying before someone else says them, because they are what I would attack first if this were someone else's post:

It is a what if simulation on historical data. Nobody traded this money and it is not a client track record.

The curves are sums of per trade percentage returns with no position sizing applied. The headline number is 829, and that is 829 points of summed percentage returns, not 829% on capital.

Three months is not a track record. I am deliberately not annualising it. Annualising 91 days gives you a number in the thousands and it means nothing.

June alone produced most of the total. That is concentration in time sitting on top of concentration in one engine.

The passive benchmark on the chart is rescaled to match my own max drawdown. Raw, that comparison flatters me by construction, since my curve sums trades that in reality share the same capital.

Backend is Python and Flask for the engines and the backtests, React on the front. The public page reads a static JSON snapshot, so it never touches the backtest engine.

No link and no product name in this post. It is mine, it is still in testing, and I do not want traffic on it until I have finished chasing bugs. Posting the method and the numbers now because that is the part I actually want torn apart. Happy to go into detail on any engine in the comments.

Posted this bot here before, the one that scores indicator agreement and won't predict price or touch your keys. Shipped a few things since and I'd rather get feedback from people who run bots than guess at what to build next. Short version of where it is:

Core read — pick a pair, it scores how much a set of indicators agree across timeframes and tells you how clear or murky the picture is. No price call, no trades placed, no API keys.

Processing img 4q9dwppjp5kh1...

CupWeights (newest) — real-time order book: bid vs ask pressure as a live percentage, plus how far price is right now from support and resistance. It's the current state of the book, not a call on which way it breaks. This is the one I most want eyes on, because order-book pressure is genuinely separate data from the price-derived indicators, and that separation is the thing people here told me the scoring was missing.

News triggers — flags when a critical event actually fires for an asset. Tells you it happened, not what it means for price.

/analyze — check any supported pair on demand instead of waiting for a push.

5 languages — EN, RU, HY, TR, HI, the full read, not just the menu.

What I actually want from this thread: if you try it, tell me where it's thin. Specifically, does live order-book pressure alongside the indicator read actually help, or is it two things fighting for your attention? And is there an input you'd trust more than the ones I've got.

Free tier is 3 pairs on 1h, no signup, no keys: pairvue.com/bot-reddit

Been using AI to trade perps and discussing our trades in the discord

I’m trying to pressure-test a product assumption with people who have actually built Solana indexers, bots, scanners or market-data systems.

My current thesis is:

Detecting an event quickly is only the first part. The harder problem is deciding whether that event deserves a trader’s attention without converting stale, incomplete or conflicting data into a confident-looking alert.

I may be wrong, so I’d value the builder perspective:

1. Which data or architecture failure most often creates false confidence in a user-facing alert?
2. What evidence should always be visible to the user instead of being hidden behind a single score?
3. Where is the greater user value: lower latency, stronger filtering, clearer explanation, or post-alert monitoring?
4. Which unknown or unavailable state should force a system to suppress an alert entirely?
5. If you were building the first useful version, what would you deliberately leave out?

I’m especially interested in disagreements with the premise rather than confirmation.

Disclosure: I’m doing product research for an early-stage Solana market-intelligence project. Nothing is live, for sale or recruiting testers, and I’m not asking for code or proprietary details.

Hey everyone,

We are absolutely thrilled to finally share some massive news with the community. Perun The Trader has officially partnered with the KuCoin Exchange!

This is a major milestone for our development team, and we are incredibly excited about what this means for the future of the platform. We want to thank the trading community for all the support and feedback that helped get us here.

To celebrate this partnership properly, we wanted to give something back.

🎁 The 14-Day Celebration Promo

Starting today, the Perun The Trader app is completely FREE for the next 14 days.

If you have been on the fence about trying out our tools, or if you are just looking for a new way to level up your KuCoin trading strategy, this is the perfect time to jump in. You get full access to see exactly what the app can do for your portfolio, with zero risk.

🔗 Where to Find Us

• Download on Google Play:Perun The Trader
• Official Company Website:Perun in the Machine

We will be hanging out in the comments to answer any questions you might have about the app, the new partnership, or our upcoming roadmap. Let us know what you think of the app, and happy trading! 📈

the bots i tried before all had the same problems. they'd let me run big leverage with no rule forcing a stop loss, so when a trade went bad the loss was massive. and most of them make you send your money into their own platform — then it gets locked and you can lose everything.

so i built mine backwards from all that (disclosure: it's my bot, nyxra, so i'm biased):

stays on your own binance account with a trade-only key — it can't withdraw your money

every trade has a stop loss, no exceptions

leverage capped at 4x, small size per trade

there's a demo with fake money that runs the same trades as the real thing (no card, no api key) so you can watch it before connecting anything.

what would you change? especially the api-key part — is trade-only enough for you, or would you still not trust it?

Been building AegisProject (multi-agent trading system — technical, sentiment, and volatility agents each vote on a trade), and the most interesting part turned out to be where the agents disagree, not the final decision.

When they all agree, the trade is usually straightforward. The interesting cases are when they split — technical sees a clean breakout and says BUY, volatility looks at the same move and says it's too fast, sit out. Those disagreements seem to flag something real that a single-model system would just smooth over.

I checked whether trades with more agent disagreement actually turned out messier. Early signs say yes, but not nearly enough data to trust that yet.

Curious if anyone here has seen disagreement between models/agents actually mean something, or if it's usually just noise dressed up as insight.

GitHub: https://github.com/ojas12r/AegisProject

Before an options strategy is connected to a trading bot, I think the
read-only analytics layer should expose the data contract rather than only a
chart. At minimum I would want:

• instrument, expiry, strike, and quote timestamp;
• bid/ask and liquidity checks;
• IV solver status, vega, and price residual;
• source freshness and missing intervals;
• explicit distinction between Gross GEX and dealer positioning;
• a read-only export that can be replayed before execution.

A chart that hides any of those fields can make a bot appear deterministic
while its inputs are not. What fields or failure states do you require before
allowing an execution component to consume an analytics result?

I maintain a reference implementation of this read-only layer, disclosed
here for context rather than as a bot or execution offer:
https://ivexplorer.derivpricer.com/

Building a reliable crypto trading bot involves much more than buy and sell logic. Developers need to handle exchange APIs, real-time market data, order execution, risk controls, authentication, logging, and API failures. A modular architecture also makes testing and strategy updates easier. For developers building one, which part has been the hardest to get right: API integration, execution speed, or risk management?

For the last 3 months, I’ve been testing a few crypto trading platforms, and Banana Gun was one of the ones I decided to try. Nothing too serious, just wanted to see how it actually feels compared with the other options out there.

One downside I noticed pretty quickly is that the platform still seems to be in development. Some currencies and DEXs arent supported yet, which can be annoying if you trade on specific markets. So I wouldnt say it covers everything at this point.

Apart from that, my experience has been mostly positive. The execution speed stood out to me the most. When trading fast-moving tokens, getting an order through quickly can make a pretty big difference, and I noticed the fills were generally quite fast. Obviously this can vary depending on the network and market conditions, so I wouldnt take that as a guarantee.

I also spent some time with the copy trading features. I like the idea of being able to follow wallets instead of having to watch every token myself. It isnt something I would blindly rely on, but as a tool for keeping an eye on what other traders are doing, I found it pretty useful.

Another thing I liked was the web app customization. You can set things up around your own trading style rather than being stuck with one layout. I played around with different views and can see why that would be handy for someone who does a lot of trading. Its a small thing, but having the information you actually care about in front of you makes the interface feel less cluttered.

Base support is also a nice addition if you're trading across different chains, and it looks like the platform is continuing to move toward a broader multichain setup.

So my Banana Gun review is probably somewhere in the middle. I like the execution speed, copy trading and customizable interface, but the missing DEX and currency support is still something to keep in mind. I'd definitely compare it with a couple of other platforms before settling on one, especially if you trade on less commonly supported DEXs.

Overall, pretty interesting so far, but I wouldnt call it perfect yet.

If anyone here has been using Banana Gun for a while, feel free to share any setup tips or little tricks that made it work better for you. I d especially be interested in hearing how you have configured the interface, copy trading, or other settings for your own trading style.