Ascendant Traders

Overview

Ascendant Traders is a crypto signals product I built across two repositories: ascendant-web for the public website and signal-crypto-bot for the always-on runtime behind the signals, tracking, and publishing workflow.

The split was intentional. I wanted the website to stay static, fast, and easy to deploy while the backend handled the stateful parts of the business: market analysis, trade lifecycle management, channel publishing, chart generation, and operational tooling. The result was less of a single app and more of a coordinated product system spanning acquisition, conversion, delivery, and reporting.

Product Scope

The public-facing side covered the entire top of funnel:

• landing page and brand positioning
• free signal preview page
• VIP pricing and comparison tables
• affiliate and Whop conversion flows
• blog infrastructure for SEO content
• about, education, and disclaimer pages

The runtime side handled the operational core:

• Discord signal publishing and tracker updates
• Telegram mirroring
• market-data ingestion and signal scoring
• SQLite-backed signal and trade state
• public feed endpoints for the website
• chart rendering for branded signal attachments

Core Architecture

Static-first website

The Astro site is intentionally static. Signal examples, pricing content, and blog pages all build ahead of time, which keeps the deployment simple and the site reliable. At the same time, I exposed optional browser-side upgrades through public JSON feeds so the homepage ticker, featured signal card, recent examples, and monthly summary can refresh from live backend data without converting the site into a server-rendered app.

That contract matters. If /public/market-feed or /public/signal-feed is unavailable, the frontend falls back to repo-backed data and still works. That let me keep the marketing site independent from backend uptime while still supporting live-looking product surfaces.

Signal engine and trade lifecycle

The Node runtime analyzes BTCUSDT, ETHUSDT, and SOLUSDT using Blofin candles and ticker data as the source of truth. On top of that I added CoinGecko as a soft confirmation layer and computed local confluence using RSI, MACD, EMA20, EMA50, VWAP, ATR, ADX, and quote-volume checks.

For the scanner flow, I tightened the qualification logic further. Instead of posting every possible setup, the scanner looks for a primary 1H opportunity, then requires 4H and 1D confirmation plus SMC-style checks like structure break, liquidity sweep, displacement, fair value gap retest, and location validation before surfacing a signal.

One of the most important modeling decisions was separating posted signals from activated trades. A setup can be published to the signal channel first and only become a tracked trade when it is explicitly activated, or auto-activated if the environment is configured that way. That kept open-trade reporting, close notifications, and monthly recaps tied to actual tracked positions instead of treating every published idea as if it were taken.

Distribution and observability

The publishing flow was built around operational clarity rather than just message output. Signal posts and tracker events can go to different Discord channels, and the system exposes read commands and debug endpoints for open trades, monthly recaps, signal state, trade history, and scanner diagnostics.

That meant the product had multiple consumers:

• traders reading signal posts
• operators activating and auditing trades
• the website consuming browser-safe public feeds
• admins checking diagnostics without opening SQLite directly

Telegram mirroring was built to fail open so messaging issues would never block Discord posting or tracker state changes. On the frontend side, I also designed the product and information architecture around an eight-language rollout, with translated signal presentation on the site and channel structure ready for broader multilingual delivery expansion.

Media and deployment

Instead of generating chart images inside the bot process, I split media rendering into its own service. The bot can request a branded chart card for a single actionable signal, receive a PNG response, and attach it to Discord or Telegram without taking on SVG and image-rendering concerns in the main command runtime.

Infrastructure stayed deliberately lean:

• Dockerized services for the bot and media renderer
• Coolify deployment on a Hetzner VPS
• SQLite persistence mounted as durable storage
• internal service-to-service networking between bot and renderer

That setup was simple enough to run cheaply on one box while still preserving clean runtime boundaries.

Key Product Decisions

This project reinforced a few decisions that made the whole system easier to evolve:

1. Keep marketing and runtime separate. The site can ship copy, design, SEO, and pricing changes without disturbing the signal engine.
2. Use feed contracts instead of direct app coupling. The website only needs stable JSON, not awareness of bot internals.
3. Model state transitions explicitly. In this kind of product, posted, activated, open, tp_hit, and sl_hit are the real business objects.
4. Treat observability as a feature. Debug routes, recap endpoints, and scanner logs are part of the product, not just internal developer tooling.

Discord Message Examples

One part of the product that mattered more than I expected was message design. The bot is not just generating trade ideas; it is publishing operationally useful updates that need to be scannable in fast-moving channels.

Here are representative examples from the actual formatter layer.

Signal post

Signal 12 | April 2026

BTCUSDT
Trade direction: Long 🟢
Market entry @ 84250
TP @ 85400
SL @ 83800
Recomended Leverage 50x | Max risk 0.5% - 2%
Live read: 3:39pm Peru / 20:39 UTC | Price ~$84,250 | 24h 🟢 +2.34%
Confluence: EMA50 🟢 above | VWAP 🟢 above | MACD 🟢 bull | RSI 🟢 58.14 | Vol 🟢 above avg | CG 🟢 +2.12%
Score: Blofin Signal L5/S1 | Extra Confirmation L3/S0
Why we take it: The bullish read is aligned enough to pass the trigger, with price above EMA50 and VWAP, ADX at 24.70 confirming trend strength, and coingecko agrees with +2.12% over 24h.

Sources: Blofin 1H candles, Blofin live ticker, Blofin mark price, CoinGecko spot context when available
[Join this BTC Trade with us →](https://blofin.com/futures/en/BTC-USDT)
[Fuel the squad on Blofin →](https://partner.blofin.com/d/asc2454)
@everyone

Activation post

BTC Signal #12 activated
📍 BTC Long | Entry 84250 | TP 85400 | SL 83800

Close post

That one did what it needed to do.
ETH closed by TP
🟢 ETH Signal #13 | +47.17%

Monthly recap

Month recap so far:

🔴 SOL Signal #10 | -14.11%
📈 BTC Signal #12 | Open
Open for: 1h 24m | Price: 84610 | TP: 0.93% away | SL: 0.96% away
Projected resolution window: 1-4h (Volatility-based estimate, not a guaranteed close time)
🟢 ETH Signal #13 | +47.17%

Winrate:
1 win / 2 closed = 50.00%

Total PnL:
Percent: +33.06%
USDT: +330.60

The short lead lines on signal and close posts come from a controlled phrase bank, so the exact first sentence can vary without changing the structural layout of the message.

Outcome

By the end of the project I had a complete product stack rather than just a signal bot: a branded website, free preview experience, VIP conversion flow, SEO content engine, signal scoring runtime, persistent tracker, chart media service, and deployable infrastructure that connected all of it together.

The main lesson was that the signal algorithm is only one slice of the problem. The real work is in the contracts between systems, the honesty of the reporting layer, and the reliability of the publishing workflow that traders actually see.