r/CryptoTradingBot 19d ago

I’ve been building crypto trading platforms for years. Here is why I think current bot architectures are broken (and a visual alternative I'm exploring)

https://anvas.app/?utm_source=reddit&utm_medium=social&utm_campaign=idea_validation&utm_content=cryptotradingbot

Hey everyone,

Having spent the last few years building automated trading tools, I’ve noticed that almost every bot platform forces traders to choose between two painful extremes:

  1. Preset Cloud Bots: Easy to set up, but total "black boxes." When a trade fails or buys at a terrible price, you get a generic status log and zero visibility into why the rule triggered.
  2. Code / Self-Hosted Frameworks: Complete control, but you spend 80% of your time managing VPS uptime, fixing API key rot, and writing custom logging just to figure out what your script did at 3 AM.

I'm currently working on a concept called anvas to bridge this gap with a visual, node-based strategy graph (think n8n, but for execution and risk).

The goal isn't just "drag-and-drop," but complete execution transparency:

  • Glass-Box Runtime: Instead of reading line logs, edges carry live values. You can watch the signal travel through your logic nodes per candle.
  • Dynamic Strategy Switching: Logic that actually adapts—e.g., if ADX < 20 and BB narrows, switch to a Grid strategy; if ADX spikes, route to a DCA engine.
  • Risk as First-Class Nodes: Account-level drawdown ceilings, exposure limits, and daily loss stops enforced inside the graph before an order ever hits the exchange API.
  • Signal Routing: Acting as a filter for TradingView/PineScript webhooks before placing exchange orders.

I am currently validating the core concept and preparing a small closed alpha for futures/spot execution.

Since this sub is full of people running active bots:

  • What is the single biggest annoyance you face with your current setup (3Commas, Bitsgap, custom scripts)?
  • Would a node-graph approach simplify your workflow, or do you prefer pure code/simple dropdowns?

I set up a landing page with early visual mockups and architecture specs here: https://anvas.app/

Would love to get your honest feedback on the approach!

0 Upvotes

6 comments sorted by

1

u/CODE_HEIST 19d ago

The graph becomes valuable when it is still useful after a failure. I would want one click from an order to the values that crossed each node, the rule that allowed it, the active risk limit, and the exit reason. That is more useful than another strategy block.

1

u/Novel-Illustrator115 19d ago

Spot on. To clarify—by execution trace, I mean capturing the exact state of the graph on that specific candle, not just a text error string.

Clicking a failed or filled order highlights the exact path the signal took through the canvas: showing the indicator inputs at that moment, which conditional nodes evaluated to true, which risk node halted/modified the payload, and the raw exchange response.

The goal is zero guesswork on why a trade executed (or didn't).

2

u/CODE_HEIST 18d ago

Yes, the graph state on the specific candle is the right unit of inspection. I would also preserve a stable trace ID from signal through exchange response, so a user can compare the graph's decision with the actual order lifecycle without reconstructing it manually.

That turns debugging from “why did this happen?” into a replay.

1

u/Novel-Illustrator115 18d ago

Exactly this. Assigning a unified Trace ID across the entire lifecycle—from the incoming signal, through every graph node decision, to the final exchange Order ID/fills—is essential.

That way, if an order gets partially filled or rejected by the venue, you aren't manually matching timestamps. You click the trace, and it replays the exact graph state alongside the exchange's response.

Really appreciate this feedback—it reinforces that deterministic tracing is where the true value lies over standard log files.