DEV Community: maymay5692

I Killed My Crypto Signal Service Before Launching It — Walk-Forward Said Every Strategy Failed

maymay5692 — Wed, 08 Apr 2026 22:44:43 +0000

Disclaimer: This article is for educational purposes only. It is not investment advice. Crypto trading carries significant risk. Do your own research and comply with your local regulations.

I was about to launch a paid crypto signal service. Three strategies, Telegram delivery, the whole thing.

I killed it. Here's why.

The Plan

I'd been writing publicly about a "3-strategy consensus" bot for months. The idea was simple. Pick three strategies with solid individual Sharpe ratios, fire a signal only when at least two agree, push that to a paid Telegram channel. Clean, conservative, explainable.

The three strategies:

Strategy	Sharpe	What it does
EMA Crossover (12/26)	1.30	Trend following
Parabolic SAR	1.25	Trend reversal
MACD (12/26/9)	1.17	Momentum

All three numbers came from three years of BTC/USDT daily backtests. Paid launch was scheduled. Infrastructure was ready. I was maybe a week away from flipping a switch.

The First Red Flag

From April 1 to April 8, I watched the free channel to sanity-check the signals. Three pairs (BTC, ETH, SOL) times eight days equals 24 opportunities.

Buy: 0. Sell: 0. Hold: 24.

Eight straight days of nothing. Not a single signal across three pairs.

I assumed quiet markets. Checked the code. It was working as designed. Each strategy only fires on the exact day a crossover happens, and requiring two strategies to cross on the same day turns out to be statistically rare — roughly once or twice per quarter. Not a market issue. A design issue.

That was the moment I stopped and asked a harder question.

The Question I Should Have Asked Earlier

I had individual backtests for each of the three strategies. I had never actually backtested the consensus rule itself. "Two strategies agreeing" is a new composite strategy, and I had no out-of-sample evidence that it worked.

So I ran Walk-Forward Optimization.

Walk-Forward Setup

Rolling windows, 365-day in-sample, 90-day out-of-sample, 90-day step. Three pairs (BTC/USDT, ETH/USDT, SOL/USDT). Three candidate strategies:

Current consensus — fire when buy_count >= 2
Variant A: EMA only — drop the consensus, use the best individual strategy
Variant B: Sharpe-weighted — weight each strategy by its historical Sharpe, threshold ±1.0

Data: Binance daily, Jan 2023 to Mar 2026. About 1,100+ bars per pair.

For significance I used the Deflated Sharpe Ratio (Bailey & López de Prado, 2014). DSR corrects for the selection bias that happens when you try multiple strategies and pick the best one. My threshold was DSR ≥ 0.95.

Here's the WFO config, in case it's useful:

from dataclasses import dataclass

@dataclass(frozen=True)
class WfoConfig:
    in_sample_days: int = 365
    out_of_sample_days: int = 90
    rolling_step_days: int = 90
    data_start: str = "2023-01-01"
    data_end: str = "2026-03-21"

Pretty standard. Nothing clever.

The Results

I'm going to show all nine cells. No cherry-picking.

Strategy	Pair	OOS Sharpe	Trades	DSR	IS→OOS Decay	Verdict
Current consensus	BTC	-0.812	14	0.005	2.05x	FAIL
Current consensus	ETH	-1.736	11	0.000	1.89x	FAIL
Current consensus	SOL	-1.974	10	0.000	3.12x	FAIL
Variant A: EMA	BTC	-10.409	18	0.000	11.38x	FAIL-FAIL
Variant A: EMA	ETH	-0.029	15	0.064	0.40x	FAIL
Variant A: EMA	SOL	-2.157	16	0.000	2.91x	FAIL
Variant B: Sharpe-weighted	BTC	0.066	42	0.082	0.69x	MARGINAL
Variant B: Sharpe-weighted	ETH	-1.599	38	0.000	1.92x	FAIL
Variant B: Sharpe-weighted	SOL	0.612	37	0.279	0.57x	MARGINAL

Seven out of nine cells have negative out-of-sample Sharpe. The two positive cells don't clear the DSR significance threshold. Zero cells pass.

The worst cell is Variant A EMA on BTC: OOS Sharpe of -10.409 with an IS→OOS decay of 11.38x. That's the textbook shape of "the model memorized the in-sample period and the out-of-sample period walked directly into the opposite wall."

The Gate Review

I have a tool called gate-reviewer that runs a 4-Pitfall / 3-Gate framework against strategy results. I ran this one through it. The 3-Gate summary:

Gate 1 (Explainability):      FAIL
  "Multiple indicators agreeing = signal" is not empirically justified.
  There is no structural reason the edge should exist.

Gate 2 (Tail Safety):         FAIL
  Max drawdown threshold is 15%. Estimated DD across variants: -25% to -70%.
  No strategy-level circuit breaker.

Gate 3 (OOS Reproducibility): FAIL
  Sharpe min > 0: 7 out of 9 cells negative.
  Trade count per window: 10-42. Sample too small.

TOTAL VERDICT: DISCARD

All three gates fail. The verdict is blunt: discard the strategy.

Why This Failed (Honest Post-Mortem)

Four things, in rough order of blame.

1. The data window was a bull market.
2023 through early 2026 was a structurally bullish period for BTC. All three strategies are trend-following. You'd expect them to look fine in-sample. The second the walk-forward window shifts to even a modestly choppier period, the model collapses. That's the signature of regime dependence.

2. The three strategies were not independent.
EMA, SAR, and MACD are all moving-average / momentum family. They see similar information. "Three strategies agreeing" sounded like three independent votes. It was closer to the same vote counted three times. There was no real ensemble diversity.

3. Design fires only on crossover instants.
Signals only trigger on the exact day a crossover happens, so the bot is constantly hunting for trend starting points. When the starting point turns out to be a reversal, the bot takes the wrong side. Inside a sustained trend, it fires nothing.

4. I ignored my own multiple-testing warning.
I wrote a whole article about the Deflated Sharpe Ratio and how trying N strategies and picking the best one inflates the apparent edge. Then I built a signal service that tries three strategies and picks the best-looking combination. I did not apply DSR correction to my own design. I wrote the warning label and then ate the poison.

That last one is the one that actually bothers me.

What I'm Doing Instead

Three options were on the table:

A. Rebuild strategies, rerun Phase 0.
B. Kill the signal service. Sell the verification process instead.
C. Shut the whole thing down.

I ran this through an internal AI council I use for hard calls (three personas judging independently). Unanimous for B.

My own reasoning landed in the same place. Option A would be me rerunning the same multiple-testing loop I just failed, which is exactly the trap DSR exists to warn you about. Option C wastes a working backtest engine, a Telegram audience, and a 13-article public trail. Option B converts the Phase 0 failure from a dead end into the most honest piece of content I've ever written.

So from now on, I'm publishing:

A weekly "verification journal" on the free Telegram channel — every new strategy I test, pass or fail, with the numbers attached.
Technical deep-dives on Walk-Forward Optimization and DSR.
A paid report ("Phase 0: The Discard Record") covering the full WFO logs, all gate-reviewer outputs, and every reason the strategies failed. Coming soon.

Selling process instead of signals. Process is the thing I actually have.

What You Can Take From This

If you're building a signal service or any paid quantitative product, three takeaways.

Walk-forward your composite rules, not just your components. A consensus of good strategies is not automatically a good strategy. The composition has its own degrees of freedom and needs its own out-of-sample test.

Use DSR even for small N. Three strategies is already enough for selection bias to inflate your apparent Sharpe. Apply the correction. It takes ten lines of Python.

Ship the failure. A public "here's the strategy I was going to sell and here's why I didn't" is worth more than another confident-sounding bot tutorial. There are a lot of the second kind. There are almost zero of the first.

I'll take "honest" over "impressive" every time now. Especially after this.

Links

GitHub @maymay5692 — backtest engine and WFO analysis scripts
Telegram Free Channel — weekly verification journal going forward
MEXC Signup — affiliate link, supports my research if you use it

Reference

Bailey, D. H., & López de Prado, M. (2014). The Deflated Sharpe Ratio: Correcting for Selection Bias, Backtest Overfitting and Non-Normality. Journal of Portfolio Management.

The Real Goal of Building a Trading Bot: Removing Yourself from the Loop

maymay5692 — Thu, 02 Apr 2026 22:37:11 +0000

The Real Goal of Building a Trading Bot: Removing Yourself from the Loop

Disclaimer: Not financial advice. I trade with small amounts and have lost money. This article discusses behavioral finance concepts, not guaranteed strategies.

I built a crypto trading bot to make money. After months of running it, I've realized the money is almost beside the point. The real value is something I didn't expect: the bot removes me from the decision-making loop, and that turns out to be worth more than any prediction algorithm.

Here's what I mean.

The 8-Loss Streak

Week one of live trading. Eight consecutive losing trades. Every single one closed red.

At $33 in capital, the financial damage was a few cents per trade. But here's what happened inside my head:

Trade 5 (loss): "Maybe I should switch strategies."

Trade 6 (loss): "The backtest was probably overfitting."

Trade 7 (loss): "What if I manually override just this one trade?"

Trade 8 (loss): "I should double the position size on the next one to make it back."

That last impulse — doubling down after losses — has a name. It's called revenge trading. And it's one of the three things that kill trading accounts.

I didn't act on any of those impulses. Not because I'm disciplined. Because the bot doesn't have an input field for "I'm frustrated, let's go bigger." The bot checked the moving averages, saw no buy signal, and did nothing. It didn't know about my losing streak. It didn't care.

The streak ended when a trend finally emerged. Trade 9 was a winner that covered all eight losses and then some. Exactly how a trend-following strategy with a 35% win rate is supposed to work.

If I had been trading manually, I probably would have revenge-traded on trade 6, oversized on trade 7, and been done before trade 9 ever happened.

The Three Killers

Behavioral finance research has cataloged dozens of cognitive biases that affect trading. But in practice, three of them do most of the damage:

1. The Disposition Effect — Selling Winners, Holding Losers

Kahneman and Tversky showed that people feel losses about 2.5 times more intensely than equivalent gains. In trading, this manifests as:

Selling winners too early — A trade goes up 2% and you grab the profit because you're afraid of giving it back.
Holding losers too long — A trade is down 3% and you refuse to sell because "it might come back."

The result: your winners are small and your losers are big. The exact opposite of what a profitable strategy needs.

My EMA Crossover bot has a 35% win rate but a 3.2:1 risk-reward ratio. The average win is +3.5%, the average loss is -1.1%. That only works if you let winners run and cut losers fast. A human doing this manually would have to fight the Disposition Effect on every single trade.

The bot doesn't fight it. It doesn't have it. When the moving averages cross, it exits. No internal debate about "maybe it'll come back."

2. Revenge Trading — Chasing Losses

After a loss, the emotional impulse is to "make it back" on the next trade. This usually means:

Increasing position size
Taking trades that don't meet your criteria
Switching strategies mid-stream

Research from Barber and Odean found that retail traders who traded most frequently earned annual returns 6.5 percentage points lower than those who traded least. The frequent traders weren't finding more opportunities — they were revenge trading.

The bot trades the same size every time. It doesn't know whether the last trade won or lost. It evaluates the current signal with zero memory of past pain.

3. The Freeze — Doing Nothing When You Should Act

The flip side of revenge trading. After a painful loss, some traders freeze. They see a perfectly valid signal, hesitate, and miss it. Then the missed trade turns out to be the big winner that would have covered everything.

This happened to me before I had the bot. I'd see a setup, remember the last loss, and think "I'll wait for a better one." The better one never came, or I hesitated on that one too.

The bot doesn't hesitate. Signal fires, order executes. No gap between analysis and action.

What the Research Says

The impact of behavioral biases on trading performance isn't theoretical. Some numbers:

Disposition Effect cost: Odean (1998) found that investors who held losers and sold winners earned 3.4% less annually than the market. The held losers continued to underperform by an average of 1% over the following year.
Overtrading cost: Barber and Odean (2000) showed that the most active retail traders underperformed the market by 6.5% annually after costs.
Emotional decision cost: A Dalbar study consistently finds that the average equity investor underperforms the S&P 500 by 1.5-3% annually, primarily due to poorly timed buy/sell decisions driven by emotion.

These aren't flaws in strategy selection or market analysis. They're flaws in execution — the gap between knowing what to do and actually doing it under emotional pressure.

A bot closes that gap to zero.

The Bot as Bias Removal Device

Here's the reframe that changed how I think about my trading bot:

The bot's primary function isn't prediction. It's bias removal.

The EMA Crossover strategy is simple — almost boring. Two moving averages, a cross, buy or sell. There's nothing sophisticated about the signal generation. A beginner could understand it in five minutes.

But the execution is where the value lives:

Human Trader	Bot
Sells winners early (Disposition Effect)	Holds until exit signal
Holds losers hoping for recovery	Exits at first reversal signal
Increases size after losses (revenge)	Same size every trade
Freezes after painful loss	Executes every valid signal
Checks portfolio 20 times a day	Checks once per hour, acts only on signal
Skips trades when "feeling uncertain"	No feelings to skip on

The prediction accuracy of the strategy is the same whether a human or a bot executes it. But the net result is different because the human leaks returns through behavioral errors.

Robert Carver, former portfolio manager at Man Group's AHL and author of Systematic Trading, puts it well: the value of systematic trading isn't finding better signals — it's ensuring consistent execution of adequate signals. A mediocre strategy executed perfectly will beat a great strategy executed emotionally.

What This Changed for Me

Before the bot, I tracked my trades manually. I had a spreadsheet. I followed the same EMA Crossover rules. In theory, my results should have been identical to the bot's backtest.

They weren't. I was about 1.5% per month worse than the backtest suggested. Why?

I skipped two trades because "the market felt weird"
I exited one winner 24 hours early because I was nervous about a news event
I held one loser for an extra day because "it was so close to breaking even"

Four behavioral errors in one month. Each one small. Together, they wiped out most of my edge.

The bot has been running the same strategy for months now. It doesn't skip trades. It doesn't exit early. It doesn't hold late. The results are closer to the backtest — not identical (slippage, fees, market conditions differ), but much closer than my manual execution ever was.

The Honest Limitation

The bot removes my biases. It doesn't remove its biases.

A backtest can be overfit. A strategy can be regime-dependent. Parameter choices reflect the builder's assumptions. The bot executes faithfully, but if the underlying strategy is flawed, the bot will faithfully execute a flawed strategy.

I wrote about this in my previous article — none of my 49 backtested strategies survived statistical correction. The DSR analysis showed that after testing 49 strategies, even my best performer (SR 1.30) couldn't be statistically distinguished from luck.

So the bot isn't a magic box. It's a consistent box. Consistency is valuable when the strategy has any edge at all. But proving that the edge is real — that's the harder, unsolved problem.

If Fighting Your Emotions on Every Trade Sounds Exhausting

There's a reason I started sending my bot's signals to a free Telegram channel. The same signals the bot trades — BTC/USDT, SOL/USDT, ETH/USDT — delivered daily, with the indicator values and consensus logic explained.

For those who want the full indicator breakdowns, individual strategy votes, and circuit breaker status in real time, there's a premium tier.

Not everyone wants to build their own bot. Some people just want the signals without the emotional tax of staring at charts. That's a valid choice.

The Real Goal

I started building a trading bot to make $100 a month. The bot currently makes under $2 a month on $39 in capital. By that metric, it's a failure.

But by the metric of "has it improved my decision-making?" — unambiguously yes. It removed me from the loop on trades where my presence was actively harmful. It turns out that for a small trader with limited capital, removing behavioral errors is worth more than any fancy prediction algorithm.

The bot's edge might be small. It might not even be statistically significant. But whatever edge exists, the bot captures 100% of it. I was capturing maybe 60%, and leaking the rest through fear, impatience, and the very human desire to "do something" when the right answer was "do nothing."

Small edge, full capture beats large edge, partial capture. Every time.

Why Your Backtest Lies: I Got 491% Returns in Testing, Then Broke Even in Production

maymay5692 — Mon, 30 Mar 2026 12:42:58 +0000

Why Your Backtest Lies: I Got 491% Returns in Testing, Then Broke Even in Production

I deployed a strategy that showed 491% returns in backtests. Three months later: breakeven. The first month was all red.

This is not financial advice. This is a post-mortem of my own mistakes, written with $33 worth of lessons learned. Trading crypto carries substantial risk of loss — don't trade with money you can't afford to lose.

Credit where it's due: The multi-agent system I use for development is built on @shio_shoppaize's multi-agent-shogun project.

The Setup

I built a backtesting engine in Python. Tested 49 strategies on BTC/USDT daily candles, 2023–2026. The top performer — multi_timeframe — returned 546% with a Sharpe of 1.50. Second place was EMA Crossover at 491%.

I picked EMA Crossover for live trading. Funded the account with 33 USDT (about $33). Set DRY_RUN=false. Waited.

What the Backtest Doesn't Tell You

The biggest lie is about execution. In a backtest, every order fills at the closing price. Instantly. No slippage. No partial fills. No "the exchange was down for maintenance."

# Backtest world
entry_price = df['close'].iloc[i]  # Perfect fill

# Real world
order = exchange.create_market_buy_order('BTC/USDT', amount)
actual_price = order['average']  # 0.05–0.3% off

That 0.05–0.3% doesn't sound like much. But a strategy that trades 30 times a month bleeds 1–2% monthly just from slippage. Over a year, that's 10–20% of your returns — gone before you even look at fees.

Fees are their own problem. I set commission at 0.1% in my backtests because that's what Bitget publishes. But my bot uses market orders, so I'm always paying the taker rate. And the taker rate changes with volume tiers, promotions, and whether Mercury is in retrograde.

Factor	Backtest	Reality
Commission	0.1% fixed	0.075–0.1% (taker)
Slippage	0%	0.05–0.3%
Round-trip cost	0.2%	0.25–0.5%

Then there's the stuff you don't think about until it bites you. Exchange maintenance — Bitget goes down 1–2 times a month for a few hours. If your exit signal fires during that window, you're holding a position you can't close. Backtests assume the market never sleeps. The market takes naps.

Looking at the Top 12 With Honest Eyes

Here's a selection from my top 12 strategies (full results in my previous article):

Rank	Strategy	Sharpe	Return	Max DD	Win%	Trades	Live Reality
1	multi_timeframe	1.50	546%	-32%	100%	2	❌ Overfitted
2	ema_crossover	1.30	491%	-34%	35%	34	△ Breakeven
3	parabolic_sar	1.25	456%	-37%	36%	94	△ Fee drag
7	atr_trailing_stop	1.11	275%	-49%	100%	1	❌ Overfitted
8	momentum	1.07	283%	-32%	36%	135	❌ Fee drag

multi_timeframe was my top-ranked strategy. Sharpe 1.50. Sounds amazing. It made exactly two trades in three years and won both. That's not a strategy — that's a coin flip that got lucky. In three months of live trading, it made zero trades. The "best" strategy sat there doing nothing.

momentum is the opposite problem — too many trades. 135 trades means 135 chances for fees and slippage to eat your returns:

135 trades × 0.1% fee × 2 (round trip) = 27%
135 trades × 0.1% slippage × 2 = 27%
Total drag: ~54%

Backtest said 283%. After costs: 229%.

Still positive, but that 283% headline is doing a lot of heavy lifting.

ema_crossover ended up being the most honest strategy. 34 trades, 35% win rate — nothing flashy. But it's a trend follower that wins big when it wins, and the low trade count means fees don't destroy it. The reason it broke even over 3 months? Daily timeframe strategies produce maybe 1–2 signals per month. With a 35% win rate, a bad quarter is just... normal variance.

The Thing Backtests Can't Simulate

Five consecutive losses.

At 35% win rate, a 5-loss streak has about a 12% probability. Over enough trades, it's guaranteed to happen. The backtest chart shows multiple drawdown periods — you can see them right there in the equity curve.

But when it's your money — even just $33 — watching five trades go red in a row does something to your brain. "Maybe this strategy doesn't work." "Maybe I should switch." "Maybe I should stop."

I stuck with it because $33 isn't life-changing money. If it had been $1,000, I'm pretty sure I would have pulled the plug during that losing streak. And that's the thing — the backtest doesn't model the person running the bot.

What I Changed

Doubled the costs in my backtest config. Set commission to 0.2% and slippage to 0.3%. Four of the top 12 strategies dropped out immediately. Harsh but useful — the survivors are the ones worth testing live.

config = {
    'commission': 0.002,    # 2× actual fees
    'slippage': 0.003,      # worst-case slippage
}

Started at $1. Not $33 — one dollar. The $1 phase caught bugs that no backtest could: minimum order sizes I didn't know existed, API response formats that differed from the docs, timeout handling that only matters when real money is on the line.

Learned to read the numbers differently. My personal experience (limited to $33, BTC/USDT daily, on Bitget) suggests that live returns run about half of backtest returns. The EMA Crossover's 491% is a 3-year cumulative number — the CAGR is about 80%. Cut that in half for live and you get roughly 40% annually.

On a $33 account, 40% per year is about $13. A bit over $1 per month.

That's a depressing number. But without the backtest, I wouldn't even have that dollar — I'd be down $33.

The Honest Summary

	Backtest	Live
Slippage	0%	0.05–0.3%
Fees	Fixed	Variable
Fills	100%	Exchange goes down sometimes
Your brain	Not modeled	Will betray you
Returns	Face value	50–70% of face value

I tested 49 strategies. Kept 12. Deployed the best one. Got breakeven. Started over with harsher backtest parameters. The strategies that survive both rounds — backtesting and live trading — are probably worth scaling. Probably. I haven't gotten there yet.

Built with Claude Code. The backtesting engine runs 49+ strategies on BTC/USDT daily data. This article reflects the author's limited experience with a $33 account — your results will differ. The author may have financial interests in platforms mentioned.

How to Run 9 AI Agents in Parallel with tmux and Claude Code

maymay5692 — Sun, 29 Mar 2026 17:15:46 +0000

How to Run 9 AI Agents in Parallel with tmux and Claude Code

Disclaimer: This article describes my personal setup. Costs and results may vary. Some links may be affiliate links.

I run nine AI agents simultaneously in a terminal. They write code, draft articles, review each other's work, and manage deployments — all coordinated through YAML files and tmux panes. No orchestration framework. No cloud infrastructure. Just a Mac, tmux, and Claude Code.

Credit where it's due: This system is built on top of @shio_shoppaize's multi-agent-shogun project and their Zenn article "Claude Codeで『AI部下10人』を作ったら…" (in Japanese). The core design — tmux + Claude Code, shogun/karo/ashigaru hierarchy, YAML-based communication, no-polling architecture — comes directly from their work. I adopted it wholesale and then layered on my own customizations (MAGI consensus system, watchdog monitoring, cost optimization, etc.) over three months of daily use.

This post explains how the system works, what broke along the way, and what I'd change if I started over.

The Setup: tmux + Claude Code

The core idea is simple: each tmux pane runs its own Claude Code session. Each session has its own context window, its own memory, its own task. Nine panes, nine independent agents.

# Create the session with 9 panes
tmux new-session -d -s multiagent
for i in $(seq 1 8); do
  tmux split-window -t multiagent
done
tmux select-layout -t multiagent tiled

But nine agents doing whatever they want is chaos. So I added hierarchy.

The Hierarchy: Feudal Japan, but for AI

I needed to name things, and "agent_manager_01" is boring. So I went with Sengoku-era Japanese military ranks. Partly because it's fun, partly because shogun_to_karo.yaml is more readable than orchestrator_to_dispatcher_queue.yaml.

Human (The Lord)
    │
    ▼
┌──────────┐
│  SHOGUN  │  ← Commander (1 agent)
└────┬─────┘    Never writes code. Delegates everything.
     │
┌────┴─────┐
│   KARO   │  ← Advisor (1 agent)
└────┬─────┘    Decomposes objectives. Manages foot soldiers.
     │
┌─┬─┬─┬─┬─┐
│1│2│3│4│5│  ← Foot soldiers (up to 5)
└─┴─┴─┴─┴─┘    Write code, run tests, draft articles.

Plus: MAGI system (3 agents) for quality review

The Shogun — Never Touches Code

The Shogun's job is to receive instructions from me, write a YAML command file, and send it to the Karo. That's it.

There's a hard rule in the instruction file: if the Shogun starts reading code or debugging, something has gone wrong. Early on, the Shogun tried to fix a bug directly. The Karo didn't know. Two foot soldiers were editing the same file from different angles. Three-way merge conflict. An hour of untangling.

Now the Shogun has exactly one workflow:

Receive command from human
Write YAML to queue/shogun_to_karo.yaml
Wake the Karo with tmux send-keys
Wait for the dashboard to update

The Karo — Middle Management That Works

The Karo takes high-level objectives and decomposes them into concrete tasks. Each task gets written to a dedicated YAML file for a specific foot soldier.

# queue/tasks/ashigaru2.yaml
task:
  task_id: cmd_060_task_002
  description: |
    Run backtests for ETH/USDT and SOL/USDT
    using TOP5 strategies from the engine.
  status: assigned
  assigned_to: ashigaru2
  timestamp: "2026-02-15T09:30:00"

The Karo also maintains dashboard.md — a human-readable status page that I check every morning. It tracks what's in progress, what's blocked, what's done, and what needs my attention.

The Foot Soldiers — Do the Actual Work

These are the workers. They pick up tasks from their personal YAML file, execute them, write a report YAML, and ping the Karo.

Each foot soldier has its own task file and its own report file. They can't see each other's files. This prevents the most common multi-agent failure mode: two agents editing the same file simultaneously.

Communication: YAML + send-keys (No Polling)

Here's the part that matters most for cost: agents never poll for new instructions.

If an agent sits in a loop checking "any new tasks?" every 30 seconds, that's burning tokens on nothing. Instead, the system is entirely event-driven. Instructions are written to YAML files, and the recipient gets woken up with tmux send-keys:

# Step 1: Write the message (DO NOT press Enter yet)
tmux send-keys -t multiagent:0.2 'New task assigned. Check your queue.'

# Step 2: Press Enter (MUST be a separate call)
tmux send-keys -t multiagent:0.2 Enter

The two-step send-keys is critical. If you combine them into one call, the Enter key sometimes gets swallowed or the message gets corrupted. Every agent's instruction file has this drilled in: always two separate bash calls.

Think of it like Slack. The YAML file is the message. The send-keys is the notification ping. If nobody pings you, you sit idle — and idle agents consume zero API tokens.

The Communication Chain

foot soldier → Karo → Shogun → human

Foot soldiers NEVER talk to the Shogun directly.
The Shogun NEVER talks to foot soldiers directly.
The Karo NEVER sends messages to the human's pane.

That last rule exists because the human might be typing when a message comes in. A stray send-keys into the human's pane would corrupt their input. So reports go to a dedicated monitoring pane (shogun:0.1), never the human's input pane (shogun:0.0).

The Report Format

# queue/reports/ashigaru2_report.yaml
worker_id: ashigaru2
task_id: cmd_060_task_002
timestamp: "2026-02-15T10:15:00"
status: done
result:
  summary: "Backtests complete for ETH and SOL"
  files_modified:
    - "results/eth_usdt_top5.csv"
    - "results/sol_usdt_top5.csv"
  notes: "SOL showed higher volatility than expected"
skill_candidate:
  found: false

Every report requires a skill_candidate field — if the foot soldier notices a repeatable pattern that could be turned into a reusable skill, it flags it. This is how the system improves over time.

The Watchdog: Auto-Recovery

Agents crash. Context windows fill up. Sessions hang. The watchdog script runs via crontab every five minutes and checks every pane:

# crontab entry
*/5 * * * * /path/to/tools/watchdog.sh

The watchdog does three things:

1. Detects idle agents with pending tasks

is_pane_idle() {
    local content
    content=$(tmux capture-pane -t "$pane" -p | tail -5)

    if echo "$content" | grep -qE 'thinking|Effecting|Calculating'; then
        echo "busy"
    elif echo "$content" | grep -q '❯ '; then
        echo "idle"
    else
        echo "busy"
    fi
}

If an agent is idle but has unfinished tasks in its queue, the watchdog sends a nudge via send-keys.

2. Detects crashed sessions

If Claude Code isn't running in a pane (just a shell prompt), the watchdog restarts it with the instruction file pre-loaded.

3. Detects deadlocks

The trickiest case: all agents are idle, no pending tasks in queues, but the dashboard shows work in progress. This means something got lost — a report wasn't sent, a task wasn't assigned, or the Karo dropped the ball after a context window reset.

When this happens, the watchdog escalates to the Shogun's monitoring pane, not the Karo. The Shogun decides what to do next. This prevents the Karo from making decisions without the Shogun's knowledge.

MAGI: The Quality Gate

Three of the nine agents are reserved for MAGI — a consensus review system named after the supercomputer in Evangelion.

Pane	Persona	Evaluation Lens
0.6	MELCHIOR (Scientist)	Data accuracy, logic, factual correctness
0.7	BALTHAZAR (Mother)	Safety, sustainability, risk assessment
0.8	CASPER (Woman)	Gut instinct, honesty, reader experience

All three review independently — no peeking at each other's opinions. Then they vote: approve, reject, or conditional. Two out of three must approve.

CASPER is the hardest to please. She catches things like:

Paragraphs that are all the same length (AI writing pattern)
Lists with exactly three items (AI loves threes)
Opening sentences that sound like fortune cookies
Technical content that's accurate but boring

My first article went through five rounds of MAGI rejection before passing. Annoying? Yes. Worth it? Also yes.

How MAGI Gets Triggered

# Shogun sends the same question to all three panes simultaneously
tmux send-keys -t multiagent:0.6 'Review article_17. Read queue/magi_question.yaml'
tmux send-keys -t multiagent:0.6 Enter
tmux send-keys -t multiagent:0.7 'Review article_17. Read queue/magi_question.yaml'
tmux send-keys -t multiagent:0.7 Enter
tmux send-keys -t multiagent:0.8 'Review article_17. Read queue/magi_question.yaml'
tmux send-keys -t multiagent:0.8 Enter

Each persona writes their verdict to queue/reports/magi_{name}.yaml. The Shogun collects all three and makes the final call.

What Broke

Context Exhaustion

The Karo runs out of context window mid-task more than anyone else. It's the bottleneck — every report passes through it, every task decomposition happens in it, every dashboard update goes through it.

When the Karo's context fills up and gets compacted, it loses the nuance of what's in progress. Reports get mishandled. Tasks get assigned to the wrong foot soldier. The recovery takes longer than the original task.

The fix: monitor context usage and rotate the Karo proactively at 30% remaining. Don't wait for it to hit the wall.

Race Conditions

Two foot soldiers editing the same file at the same time. This happened three times before I added the dedicated-file rule. Now each foot soldier has its own task file, its own report file, and a hard rule: if your task requires editing a file that another soldier might touch, report status: blocked and let the Karo figure out sequencing.

API Rate Limits

Five foot soldiers working simultaneously hit Claude's rate limits. The solution: maximum four agents active at once. If there are five tasks, deploy four, wait for the first to finish, then deploy the fifth.

The Karo manages this automatically — it counts how many foot soldiers are currently in_progress and holds the rest in queue.

The Shogun Doing Code Review

I mentioned this already, but it's the most important lesson. The Shogun tried to be helpful by reading code directly. This violated the hierarchy, created merge conflicts, and confused the Karo. Now there's a rule enforced by a pre-prompt hook: if the Shogun attempts to read source code files, the hook blocks it and logs a violation.

Watchdog False Positives

Early version of the watchdog couldn't distinguish between "Claude Code is idle at the prompt" and "Claude Code hasn't started yet." It would restart agents that were perfectly fine, killing their context. The fix was parsing the pane content more carefully — looking for the Claude Code prompt character (❯) versus a shell prompt.

Cost and Performance

Running Cost

Nine agents don't all run simultaneously. On a typical day:

Shogun: 2-3 activations (receive command, check dashboard, handle report)
Karo: 5-10 activations (decompose tasks, process reports, update dashboard)
Foot soldiers: 1-2 tasks each, 4 max at once
MAGI: triggered only for quality reviews (maybe once a day)

Idle agents cost zero. The send-keys approach means you only pay for work that's actually happening.

Throughput

Real example: deploying sixteen articles across three platforms (note.com, Zenn, dev.to) in three weeks. Five foot soldiers writing simultaneously — three drafting articles for different platforms, one running backtests, one building the publish automation. The Karo coordinating all of them through YAML task files.

A single agent would have taken three times as long. The hierarchy prevents the coordination chaos that makes naive multi-agent setups slower than a single agent.

Lessons Learned

Start with two agents, not nine. One commander, one worker. Get the YAML protocol working. Get send-keys reliable. Then add more workers one at a time.

The hierarchy isn't overhead, it's load-bearing. I tried a flat structure first. Agents duplicated work, overwrote each other's files, and sent conflicting reports. The three-layer hierarchy (Shogun → Karo → foot soldiers) eliminated 90% of coordination failures.

Idle is free, restart is expensive. An idle Claude Code session at the prompt consumes zero API tokens. A restarted session loses its entire context — all the code understanding, task history, and project knowledge. Keep agents idle, don't exit them.

The watchdog is essential. Without it, a single crashed agent can stall the entire pipeline. The five-minute check interval catches problems before they cascade.

Context window is the real bottleneck. Not speed, not rate limits — context. The Karo processes every report and every task. It fills up fastest. Plan for rotation.

YAML is the right protocol. I considered JSON, plain text, and structured tool calls. YAML won because it's human-readable (I debug by reading the files), AI-readable (Claude handles YAML natively), and diff-friendly (git shows clean diffs).

No polling. Ever. Event-driven communication via send-keys is the single most important cost optimization. One agent polling every 30 seconds would cost more per day than all nine agents doing actual work.

Try It

The full system runs on any machine with tmux and Claude Code installed. The instruction files, YAML protocol, and watchdog script are the only infrastructure. No Docker, no Kubernetes, no cloud services.

If you want to experiment, start with this:

# Terminal 1: The commander
tmux new-session -s multiagent -n commander

# Terminal 2: One worker
tmux split-window -t multiagent

# In the commander pane, start Claude Code with an instruction file
# In the worker pane, start Claude Code with a different instruction file
# Write a task YAML, send-keys to the worker, see what happens

Scale up when the two-agent version works. The hierarchy will earn its keep around agent number four.

Built with Claude Code. The system described here manages a crypto trading bot, a technical article pipeline, and a Telegram signal service — all coordinated through YAML files and tmux.

Running a Crypto Bot on $33: The Honest Math

maymay5692 — Sun, 29 Mar 2026 16:13:24 +0000

This is a personal experience post, not financial advice. Crypto trading carries risk. Only use money you can afford to lose. This article contains affiliate links.

I built a crypto trading bot from scratch in Python. Deployed it on Bitget with $33. Ran it for three months.

Monthly profit: somewhere between $0.80 and $1.60.

That's it. That's the honest number. Not $10,000. Not "quit your job" money. Less than a cup of coffee.

But here's the thing — I learned more from this $33 experiment than from any tutorial or course. So let me walk you through exactly what happened.

What I Built

A Python bot using ccxt that connects to Bitget and trades BTC/USDT on daily candles. The strategy is EMA Crossover (12/26) — dead simple, but it had the best risk-adjusted returns out of 50 strategies I backtested.

Detail	Value
Starting capital	33 USDT (~$33)
Exchange	Bitget
Pairs	BTC/USDT, SOL/USDT, ETH/USDT
Strategy	EMA Crossover (fast=12, slow=26)
Timeframe	1d (daily)
Check interval	Every hour
Fees	0.1% per trade

Why EMA Crossover?

I didn't pick it randomly. I backtested 50 strategies on 3 years of BTC/USDT daily data (2023-01-01 to 2026-02-06). Here's the top 5:

Rank	Strategy	Sharpe	Return	Max DD	Trades
1	multi_timeframe	1.50	546%	-31.8%	2
2	ema_crossover	1.30	491%	-34.0%	34
3	parabolic_sar	1.25	456%	-37.3%	94
4	triple_ma	1.25	502%	-39.4%	20
5	macd	1.17	428%	-33.2%	84

multi_timeframe looks great on paper — Sharpe 1.50, 546% return. But only 2 trades in 3 years. That's overfitting. It just happened to nail the timing twice.

EMA Crossover had a Sharpe of 1.30 across 34 trades. Not amazing, but statistically more meaningful.

The Numbers That Matter

EMA Crossover's backtested monthly return: 4.85%.

But backtests lie. In reality, slippage, execution delays, and API latency eat into returns. A conservative estimate is 50% of backtest performance — so about 2.42%.

Optimistic (100% of backtest): $33 × 4.85% = $1.60/month
Realistic  ( 50% of backtest): $33 × 2.42% = $0.80/month
Pessimistic( 25% of backtest): $33 × 1.21% = $0.40/month

So the bot makes somewhere between 40 cents and a dollar sixty per month. On $33.

How 0.1% Fees Kill Small Accounts

0.1% sounds tiny. It's not, when your account is $33.

Bitget's minimum order for BTC/USDT is 5 USDT. A round trip (buy + sell) at 0.1% costs $0.01. Do that 5 times a month, and you're paying $0.05 in fees.

When your monthly profit is $0.80, that's 6.25% of your earnings going to fees.

On a $10,000 account, the same fee rate means $10 on $485 profit — barely noticeable. On $33, you feel every cent.

The Minimum Order Problem

Bitget's BTC/USDT has a minimum order of 5 USDT. When you're running 3 pairs on $33, that's about $11 per pair. A single 5 USDT order ties up 45% of your per-pair allocation.

Normal risk management says 2-5% per position. I was running at 45%. Not by choice — by constraint.

What Would It Take to Make $100/Month?

This is probably what you actually want to know.

Scenario	Monthly Return	Capital Needed
Optimistic (BT 100%)	4.85%	$2,063
Realistic (BT 50%)	2.42%	$4,127
Pessimistic (BT 25%)	1.21%	$8,254

Even optimistically: you need over $2,000 to make $100/month. Realistically, more like $4,000-$5,000.

"Start a crypto bot with $33 and make $100/month" is mathematically impossible.

What About Compounding?

Starting with $33, reinvesting everything:

Month	Balance (Optimistic)	Monthly (Optimistic)	Balance (Realistic)	Monthly (Realistic)
0	$33	$1.60	$33	$0.80
12	$58.22	$2.82	$43.97	$1.06
24	$102.71	$4.98	$58.58	$1.42
36	$181.20	$8.79	$78.07	$1.89
60	$564.07	$27.36	$138.63	$3.36

Five years of perfect compounding with zero drawdowns (which won't happen): $27/month. Realistically: $3.36/month after 5 years.

The Max Drawdown Reality

EMA Crossover's max drawdown is -34.04%.

On $33, that's $11.23 gone. Your balance drops from $33 to $21.77.

Not life-changing money, sure. But psychologically? Watching a third of your balance disappear and trusting the bot to recover — that's a real test. And it's way better to have that experience with $33 than with $3,000.

What Worked

The bot actually runs. Sounds basic, but getting from "I want to build a bot" to "it's live and trading real money" is a non-trivial engineering project. Python + ccxt + a clear architecture got me there.
Backtesting 50 strategies first. I didn't guess. I tested. The data told me EMA Crossover was the most robust, and so far the live performance roughly tracks the conservative estimate.
CircuitBreaker saved me from stupid mistakes. Auto-stop on 3 consecutive losses or 5% daily loss. Simple, but it catches runaway bugs.
Starting with DRY_RUN=true. Ran the bot in simulation mode for a week before going live. Caught two edge cases that would've caused weird orders.

What Failed

The economics. $33 is not enough capital to generate meaningful returns. The math doesn't work. Period.
Minimum order constraints. Running 3 pairs on $33 means your position sizing is dictated by exchange minimums, not risk management.
Fee drag on small accounts. 0.1% per trade is fine on $10K. On $33, it's a meaningful chunk of your profit.
Overestimating backtest results. 4.85% monthly looked great. Reality is closer to 2%.

The Core Lesson

A crypto bot on $33 is not an income-generating tool. It's a learning environment.

For $33 — less than most online courses — you get:

Real experience with backtest-to-live divergence
Hands-on understanding of fee impact
Position sizing under constraints
Drawdown psychology (with real, if small, money)
A production-grade codebase you can scale later

If you want to make $100/month from a bot, you need at least $2,000-$5,000 in capital. That's the honest answer.

Getting Started

If you want to try this yourself, MEXC is probably a better starting point than Bitget for small accounts — zero maker fees on spot and $1 minimum orders instead of $5.

# Python 3.11+
pip install ccxt pandas numpy

# .env
EXCHANGE_API_KEY=your_key
EXCHANGE_API_SECRET=your_secret
DRY_RUN=true
TRADE_AMOUNT=5

Start with DRY_RUN=true. Always.

This is a personal experience post, not financial advice. Backtest results are based on historical data and do not guarantee future profits. Trade at your own risk with money you can afford to lose. Links in this article include referral/affiliate links.

How a Solo Dev Tried to Make $100/Month with AI Agents and Crypto Bots — The Full Story

maymay5692 — Sun, 29 Mar 2026 11:09:47 +0000

Disclaimer: This article is for educational purposes only. It does not constitute financial advice. Always do your own research and comply with your local regulations before trading.

Three months ago, I had a problem. The AI agents I was running — nine of them, all Claude Code sessions — cost real money every month. API calls, context windows, compute. If I didn't find a way to cover those bills, the whole system would shut down.

The target: $100/month. Not to get rich. Just to keep the lights on.

This is the story of what I built, what failed, and where things actually stand. No inflated numbers. No "I made $10K in my first week." Just an honest log of a solo developer trying to make a self-sustaining AI system.

Why $100? — The API Bills That Keep the Lights On

The system I'm running isn't a single chatbot. It's a multi-agent framework — nine Claude Code instances orchestrated through tmux, communicating via YAML files, organized in a feudal Japanese military hierarchy. Shogun at the top, a Karo (advisor) in the middle, foot soldiers at the bottom.

It does real work. The agents write code, run backtests, draft articles, review each other's output, and manage deployments. But every prompt costs money. Every context window refresh costs money. Nine agents running in parallel burns through API credits fast.

So I needed $100/month of self-generated revenue. Not from a day job. Not from freelancing. From systems the agents themselves help build and operate.

The plan was three pillars:

A crypto trading bot — automated income from market signals
Technical articles with affiliate links — zero-cost content that generates referral revenue
A Telegram signal service — packaging the bot's signals as a product

All three built and operated by the same AI agent system that needs the money to survive. A system paying for its own existence.

The Bot — 50 Strategies, $33 Starting Capital, and the Painful Reality

I started with $33 on Bitget. BTC/USDT. One strategy: EMA Crossover.

But before going live, I wanted data. So I built a backtesting engine in Python and ran 50 strategies against 37 months of BTC/USDT daily data. Every result — Sharpe ratio, max drawdown, win rate, trade count — went into a public spreadsheet. No cherry-picking.

The top performers:

Strategy	Sharpe	Return	Win Rate	Trades
EMA Crossover	1.30	491%	35%	34
Parabolic SAR	1.25	456%	36%	94
MACD	1.17	428%	36%	84

491% return at 35% win rate. That sounds contradictory until you look at the risk-reward ratio. Losses are small (tight stop-loss). Wins are big (3x+ the stop-loss distance). Seven losing trades at -$1 each plus three winning trades at +$3.50 each still nets you +$3.50. The math works. It just doesn't feel like it works when you're watching eight consecutive losses.

And that happened. Right after going live — eight consecutive red trades. The strategy wasn't broken. It was a ranging market. EMA crossover strategies need trends. No trend, no edge. But sitting through that while staring at a $33 account is a special kind of misery.

Here's the honest math on what $33 gets you:

Investment	Monthly Return (Optimistic 4.85%)	Monthly Revenue
33 USDT	4.85%	$1.60
100 USDT	4.85%	$4.85
2,063 USDT	4.85%	$100.00

To hit $100/month from trading alone, I'd need $2,063 in capital. With $33, I get $1.60. That's not even a rounding error on the API bill.

So the bot alone couldn't solve the problem. I needed the other two pillars.

The Pivot — Three Pillars for $100

Pillar 1: Technical Articles + Affiliate Revenue

The idea: write about the bot-building experience, publish on dev.to, note.com, and Zenn, and include exchange referral links where they fit naturally.

This is where the AI agents earned their keep. I had foot soldiers drafting articles, a MAGI system (three AI personalities debating quality), and an automated publishing pipeline that could push to three platforms simultaneously.

The content pipeline:

Theme Scout agent → topic selection
  → 3 foot soldiers write simultaneously (note/Zenn/dev.to)
    → MAGI quality gate (3 AI reviewers vote)
      → Auto-publish pipeline (Zenn via GitHub, dev.to via API, note via Playwright)

15 articles published across three platforms in about three months. Topics ranged from "I backtested 50 strategies" to "My AI agent reviewed my AI-written article and rejected it 5 times." Each article links back to the GitHub repo, and exchange recommendations point to affiliate links.

Revenue from articles so far: hard to measure precisely. Affiliate attribution takes weeks. But the articles serve a second purpose — they're the top of a funnel that feeds into the signal service.

Pillar 2: Telegram Signal Service

The bot already generates BUY/SELL/HOLD signals from three strategies running consensus (2-out-of-3 agree = signal). Sending those signals to a Telegram channel was a weekend project.

cron (daily) → fetch BTC/USDT data via ccxt
  → EMA + MACD + SAR each vote independently
    → consensus signal (majority wins)
      → Telegram Bot API → free channel

Free channel: consensus signal + price. Premium channel (planned, $29/month): full strategy breakdown, individual indicator values, circuit breaker status.

The pricing logic: competing services charge $40-55/month for signals you can't verify. Mine shows the source code, the backtest data, and every decision the bot makes. At $29/month, four subscribers covers the $100 target.

Current status: free channel is live, premium channel isn't launched yet. Still building the subscriber base through the articles.

Pillar 3: Bot Optimization

The original $33 bot was too slow. Daily EMA crossover on one pair produces maybe one trade per month. So I expanded:

Three pairs: BTC/USDT, SOL/USDT, ETH/USDT
Three strategies: EMA Crossover (daily), MACD (daily), 4h Swing Trading
Circuit breaker: automatic shutdown at -3% daily, -7% weekly, -15% monthly

The architecture handles all of this in a single process, looping through each pair-strategy combination every hour. No Docker, no cloud. Just a Python script and a cron job on a Mac.

# Simplified loop structure
for pair in [btc, sol, eth]:
    for strategy in pair.strategies:
        signal = strategy.generate_signal(pair.ohlcv)
        if signal.action != "HOLD":
            pair.bridge.execute(signal)
            pair.circuit_breaker.record(signal.pnl)

Current balance: ~39 USDT. Mostly from deposits, not profits. Being honest about that.

The AI Army — 9 Agents, Feudal Hierarchy, MAGI Quality Gate

The multi-agent system is the infrastructure behind everything. Here's how it's organized:

Human (me)
  │
  ▼
SHOGUN (1 agent) — never writes code, only delegates
  │
  ▼
KARO (1 agent) — decomposes objectives into tasks
  │
  ▼
ASHIGARU 1-5 (foot soldiers) — write code, articles, run tests
  │
MAGI 6-8 (3 agents) — quality review panel

Communication is event-driven. No polling (that wastes API credits). The Shogun writes a YAML task file, then wakes the Karo with tmux send-keys. The Karo decomposes it into subtasks, writes YAML files for each foot soldier, and wakes them. Foot soldiers report back to the Karo via YAML. The Karo updates a dashboard. I read the dashboard.

The MAGI system is the quality gate. Three agents with different personalities review every article before publication:

Agent	Persona	Evaluation Bias
MELCHIOR	Scientist	Data, logic, factual accuracy
BALTHAZAR	Mother	Safety, sustainability, reader trust
CASPER	Id	Instinct, honesty, what the reader actually wants

All three must approve for an article to ship. One "reject" sends it back for revision. This caught real problems — misleading statistics, missing disclaimers, sections that sounded like marketing copy instead of engineering writing.

What Broke

Context exhaustion: The Karo agent ran out of context window mid-task. After restart, it had shallow context and mishandled reports. Learned to rotate agents proactively at 30% context remaining.
Race conditions: Two foot soldiers editing the same file. Fixed with dedicated per-soldier task files and a write-lock convention.
Shogun doing code review: The commander started debugging directly. The Karo didn't know. Merge chaos. Now it's a hard rule — the Shogun never reads code.
Watchdog false positives: The monitoring script mistook idle Claude sessions for crashed ones and restarted them, losing context. Fixed by detecting idle state vs. actual crashes.

The system works, but it's fragile in ways that human teams aren't. A human team member who forgets something can be reminded. An AI agent that loses context has to re-read everything from scratch. Context management is the hardest part of running multi-agent systems.

Honest Numbers — What Actually Worked, What Failed

Let me be direct about where things stand.

What's Working

Component	Status	Revenue Impact
Trading bot (3 pairs, 3 strategies)	Running	~$1-2/month at current capital
Article pipeline (15 articles, 3 platforms)	Running	Affiliate attribution pending
Telegram free channel	Running	Funnel building
MAGI quality gate	Running	Caught 5+ publication-blocking issues
Multi-agent orchestration	Running	50+ tasks completed autonomously

What Failed or Stalled

Component	Issue
Telegram premium channel	Not launched — need subscriber base first
$100/month target	Not hit — trading revenue is $1-2/month, affiliate TBD
note.com paid articles	Automation blocked by UI complexity (ProseMirror hover menus)
Bot profit attribution	Most balance growth is deposits, not trading profit

The Real Gap

The fundamental challenge hasn't changed: capital. At 4.85% monthly return, you need $2,063 to generate $100/month from trading. With $39, I generate under $2. The three-pillar strategy was designed to bridge this gap — articles and signals don't need capital, just time and content.

Three months in, the system is operational. The infrastructure works. The agents coordinate. The content publishes. But $100/month? Not yet. The funnel (articles → free channel → premium subscribers) needs more time to convert.

What I'd do differently:

Start the signal channel earlier. Articles take weeks to gain traction. The channel compounds daily.
Spend less time on automation polish. The auto-publish pipeline is beautiful engineering and probably saved zero hours compared to manual publishing at 15 articles.
Accept that $33 of capital produces $33 of results. No amount of strategy optimization changes the denominator.

But here's the thing I didn't expect: the multi-agent system itself became the most interesting part. The feudal hierarchy, the YAML communication protocol, the MAGI quality gate — people ask about those more than the trading bot. The infrastructure I built to make money turned out to be more valuable as content than as a revenue generator.

Maybe that's the real play. Not $100/month from trading. $100/month from being the person who documented exactly what happens when you try.

I'm still running the system. The agents are still working. The articles are still publishing. The bot is still trading.

We'll see.

How a Solo Dev Tried to Make $100/Month with AI Agents and Crypto Bots — The Full Story

maymay5692 — Sat, 28 Mar 2026 22:45:23 +0000

Disclaimer: This article is for educational purposes only. It does not constitute financial advice. Always do your own research and comply with your local regulations before trading.

The target: $100/month. Not to get rich. Just to keep the lights on.

Why $100? — The API Bills That Keep the Lights On

So I needed $100/month of self-generated revenue. Not from a day job. Not from freelancing. From systems the agents themselves help build and operate.

The plan was three pillars:

A crypto trading bot — automated income from market signals
Technical articles with affiliate links — zero-cost content that generates referral revenue
A Telegram signal service — packaging the bot's signals as a product

All three built and operated by the same AI agent system that needs the money to survive. A system paying for its own existence.

The Bot — 50 Strategies, $33 Starting Capital, and the Painful Reality

I started with $33 on Bitget. BTC/USDT. One strategy: EMA Crossover.

The top performers:

Strategy	Sharpe	Return	Win Rate	Trades
EMA Crossover	1.30	491%	35%	34
Parabolic SAR	1.25	456%	36%	94
MACD	1.17	428%	36%	84

Here's the honest math on what $33 gets you:

Investment	Monthly Return (Optimistic 4.85%)	Monthly Revenue
33 USDT	4.85%	$1.60
100 USDT	4.85%	$4.85
2,063 USDT	4.85%	$100.00

To hit $100/month from trading alone, I'd need $2,063 in capital. With $33, I get $1.60. That's not even a rounding error on the API bill.

So the bot alone couldn't solve the problem. I needed the other two pillars.

The Pivot — Three Pillars for $100

Pillar 1: Technical Articles + Affiliate Revenue

The idea: write about the bot-building experience, publish on dev.to, note.com, and Zenn, and include exchange referral links where they fit naturally.

The content pipeline:

Theme Scout agent → topic selection
  → 3 foot soldiers write simultaneously (note/Zenn/dev.to)
    → MAGI quality gate (3 AI reviewers vote)
      → Auto-publish pipeline (Zenn via GitHub, dev.to via API, note via Playwright)

Revenue from articles so far: hard to measure precisely. Affiliate attribution takes weeks. But the articles serve a second purpose — they're the top of a funnel that feeds into the signal service.

Pillar 2: Telegram Signal Service

The bot already generates BUY/SELL/HOLD signals from three strategies running consensus (2-out-of-3 agree = signal). Sending those signals to a Telegram channel was a weekend project.

cron (daily) → fetch BTC/USDT data via ccxt
  → EMA + MACD + SAR each vote independently
    → consensus signal (majority wins)
      → Telegram Bot API → free channel

Free channel: consensus signal + price. Premium channel (planned, $29/month): full strategy breakdown, individual indicator values, circuit breaker status.

Current status: free channel is live, premium channel isn't launched yet. Still building the subscriber base through the articles.

Pillar 3: Bot Optimization

The original $33 bot was too slow. Daily EMA crossover on one pair produces maybe one trade per month. So I expanded:

Three pairs: BTC/USDT, SOL/USDT, ETH/USDT
Three strategies: EMA Crossover (daily), MACD (daily), 4h Swing Trading
Circuit breaker: automatic shutdown at -3% daily, -7% weekly, -15% monthly

The architecture handles all of this in a single process, looping through each pair-strategy combination every hour. No Docker, no cloud. Just a Python script and a cron job on a Mac.

# Simplified loop structure
for pair in [btc, sol, eth]:
    for strategy in pair.strategies:
        signal = strategy.generate_signal(pair.ohlcv)
        if signal.action != "HOLD":
            pair.bridge.execute(signal)
            pair.circuit_breaker.record(signal.pnl)

Current balance: ~39 USDT. Mostly from deposits, not profits. Being honest about that.

The AI Army — 9 Agents, Feudal Hierarchy, MAGI Quality Gate

The multi-agent system is the infrastructure behind everything. Here's how it's organized:

Human (me)
  │
  ▼
SHOGUN (1 agent) — never writes code, only delegates
  │
  ▼
KARO (1 agent) — decomposes objectives into tasks
  │
  ▼
ASHIGARU 1-5 (foot soldiers) — write code, articles, run tests
  │
MAGI 6-8 (3 agents) — quality review panel

The MAGI system is the quality gate. Three agents with different personalities review every article before publication:

Agent	Persona	Evaluation Bias
MELCHIOR	Scientist	Data, logic, factual accuracy
BALTHAZAR	Mother	Safety, sustainability, reader trust
CASPER	Id	Instinct, honesty, what the reader actually wants

What Broke

Context exhaustion: The Karo agent ran out of context window mid-task. After restart, it had shallow context and mishandled reports. Learned to rotate agents proactively at 30% context remaining.
Race conditions: Two foot soldiers editing the same file. Fixed with dedicated per-soldier task files and a write-lock convention.
Shogun doing code review: The commander started debugging directly. The Karo didn't know. Merge chaos. Now it's a hard rule — the Shogun never reads code.
Watchdog false positives: The monitoring script mistook idle Claude sessions for crashed ones and restarted them, losing context. Fixed by detecting idle state vs. actual crashes.

Honest Numbers — What Actually Worked, What Failed

Let me be direct about where things stand.

What's Working

Component	Status	Revenue Impact
Trading bot (3 pairs, 3 strategies)	Running	~$1-2/month at current capital
Article pipeline (15 articles, 3 platforms)	Running	Affiliate attribution pending
Telegram free channel	Running	Funnel building
MAGI quality gate	Running	Caught 5+ publication-blocking issues
Multi-agent orchestration	Running	50+ tasks completed autonomously

What Failed or Stalled

Component	Issue
Telegram premium channel	Not launched — need subscriber base first
$100/month target	Not hit — trading revenue is $1-2/month, affiliate TBD
note.com paid articles	Automation blocked by UI complexity (ProseMirror hover menus)
Bot profit attribution	Most balance growth is deposits, not trading profit

The Real Gap

What I'd do differently:

Start the signal channel earlier. Articles take weeks to gain traction. The channel compounds daily.
Spend less time on automation polish. The auto-publish pipeline is beautiful engineering and probably saved zero hours compared to manual publishing at 15 articles.
Accept that $33 of capital produces $33 of results. No amount of strategy optimization changes the denominator.

Maybe that's the real play. Not $100/month from trading. $100/month from being the person who documented exactly what happens when you try.

I'm still running the system. The agents are still working. The articles are still publishing. The bot is still trading.

We'll see.

I Built My Own Crypto Signal Bot Instead of Paying $40/month — 35% Win Rate, Still Profitable

maymay5692 — Sat, 28 Mar 2026 15:17:33 +0000

Disclaimer: This article is for educational purposes only. It does not constitute financial advice. Always do your own research and comply with your local regulations before trading.

Crypto signal services charge $40-55/month. You open Telegram, get a daily "BUY" or "SELL", and hope for the best. Ask them how the signal is generated? Silence. Ask to see the backtest data? Nothing.

I was already running a trading bot. Python, ccxt, the usual stack. One day I looked at the signals my bot was producing and thought — wait, this is a signal service. I just wasn't sending it anywhere.

So I wired it up to Telegram. Total cost: $0. Win rate: 35%. And it's profitable.

Here's how.

Why I Built This

I started with a simple EMA crossover bot trading BTC/USDT on Bitget. $33 starting capital. It worked, but I wanted to know if there was something better.

So I built a backtesting engine and ran 50 strategies against 37 months of BTC/USDT daily data (Jan 2023 – Feb 2026). Every single result — Sharpe ratio, max drawdown, win rate, trade count — is public on GitHub. No cherry-picking.

The top 3 strategies became my signal sources:

Strategy	What It Does	Sharpe
EMA Crossover	Trades when short-term and long-term moving averages cross	1.30
Parabolic SAR	Detects trend reversals	1.25
MACD	Measures trend strength and direction	1.17

Each strategy independently generates BUY/SELL/HOLD. When 2 out of 3 agree, that becomes the consensus signal. Simple majority vote.

This is where it clicked. The paid signal services? They're doing the same thing — pulling data from an exchange, running it through some strategy, and pushing the result to Telegram. There's no secret sauce. The difference is whether you can see what's inside.

I wanted to see what's inside. So I built my own.

Architecture

The whole system runs on a daily cron job. No cloud, no Docker, just a Python script.

cron (daily, 00:15 UTC)
  │
  ▼
Bitget API → fetch OHLCV data (via ccxt)
  │
  ▼
3 strategies analyze independently
  │
  ▼
Majority vote → BUY / SELL / HOLD
  │
  ▼
Telegram Bot API → push to channel

The signal module lives in src/signal/ with a clean separation:

src/signal/
├── config.py       # Environment config (frozen dataclass)
├── generator.py    # Runs all 3 strategies, produces consensus
├── formatter.py    # Formats messages (free vs premium)
├── sender.py       # Sends to Telegram (async, retries, dry_run)
├── notifier.py     # Orchestrates the flow
└── main.py         # Entry point for cron

The free channel gets the consensus signal. The premium channel gets the full breakdown — individual strategy outputs, indicator values, circuit breaker status.

Free channel output:

🟢 BTC/USDT Signal
Consensus: BUY
Price: $96,543

Full strategy breakdown → Premium channel

Premium channel output:

🟢 BTC/USDT Signal Alert
Consensus: BUY (2/3 strategies agree)
Price: $96,543.21

Strategy Breakdown:
  🟢 EMA Crossover: BUY
     EMA(12)=96800 / EMA(26)=96200
  🟢 MACD: BUY
     MACD=245 Signal=180
  🟡 Parabolic SAR: HOLD
     SAR=95100 trend=UP

CB Status: NORMAL
Time: 2026-03-28 00:15 UTC

The SignalGenerator class handles the consensus logic:

def generate(self, ohlcv: pd.DataFrame) -> AggregatedSignal:
    signals = [
        self._ema_crossover(ohlcv),
        self._parabolic_sar(ohlcv),
        self._macd(ohlcv),
    ]

    buy_count = sum(1 for s in signals if s.direction == "BUY")
    sell_count = sum(1 for s in signals if s.direction == "SELL")

    if buy_count >= 2:
        consensus = "BUY"
    elif sell_count >= 2:
        consensus = "SELL"
    else:
        consensus = "HOLD"

    return AggregatedSignal(
        consensus=consensus,
        strategies=signals,
    )

Nothing fancy. Three strategies vote, majority wins. If EMA and MACD both say BUY but SAR says HOLD, the consensus is BUY. When all three agree, that's a high-conviction signal.

Key Code: The Telegram Integration

The Telegram side is surprisingly simple. python-telegram-bot does the heavy lifting.

from telegram import Bot

class TelegramSender:
    def __init__(self, bot_token: str, channel_id: str, dry_run: bool = True):
        self._bot = Bot(token=bot_token)
        self._channel_id = channel_id
        self._dry_run = dry_run

    async def send(self, message: str) -> None:
        if self._dry_run:
            print(f"[DRY_RUN] Would send to {self._channel_id}:\n{message}")
            return

        await self._bot.send_message(
            chat_id=self._channel_id,
            text=message,
            parse_mode="Markdown",
        )

Setting up the bot took 3 minutes:

Message @BotFather on Telegram → /newbot
Get the bot token
Create a channel, add the bot as admin
Drop the token and channel ID into .env

TELEGRAM_BOT_TOKEN=your_token_here
TELEGRAM_FREE_CHANNEL_ID=-100xxxxxxxxxx
SIGNAL_DRY_RUN=true

I ran it with DRY_RUN=true first, confirmed the output format looked right, then flipped it to false. The whole pipeline — data fetch, strategy analysis, consensus, Telegram delivery — runs in under 10 seconds.

Honest Numbers: Why 35% Win Rate Still Works

This is the part most people get stuck on.

"35% win rate means you lose 7 out of 10 trades. How is that profitable?"

The answer: risk-reward ratio.

When the bot loses, it loses small. The stop-loss is tight. When it wins, it wins big. The take-profit is set at 3x+ the stop-loss distance.

Here's what that looks like over 10 trades:

7 losses × -$1.00  = -$7.00
3 wins   × +$3.50  = +$10.50
─────────────────────────────
Net:                  +$3.50

This is expected value at work. Win rate alone tells you nothing. A strategy with 80% win rate can still lose money if the wins are tiny and the losses are huge. And a 35% win rate strategy can print money if the risk-reward ratio is favorable.

My backtest data across 37 months confirms this pattern holds. The EMA crossover strategy specifically returned 491% with a Sharpe ratio of 1.30 — at a 35% win rate.

But I'll be honest about the rough patches. Right after going live, I hit 8 consecutive losses. That's statistically normal for a 35% win rate system, but it doesn't feel normal when you're watching it happen. The strategy wasn't broken — it was just a ranging market. When the trend came back, so did the profits.

The mental game is the hardest part of running a low-win-rate system. You have to trust the math even when your gut says to pull the plug.

Here's the key backtest comparison:

Metric	EMA Crossover	Parabolic SAR	MACD
Return	491%	456%	428%
Sharpe	1.30	1.25	1.17
Win Rate	35%	36%	36%
Max Drawdown	-34%	-37%	-33%
Trades	34	94	84

None of these have a win rate above 36%. All three are profitable over 37 months. The common thread: they cut losses early and let winners run.

What's Next

The bot is live. The free Telegram channel is running. Every day, BTC/USDT consensus signals go out.

What I'm working on now:

Multi-pair expansion — Adding ETH/USDT and SOL/USDT to the signal feed. More pairs = more signals = more useful data for subscribers
Premium channel launch — Full strategy breakdowns, individual indicator values, circuit breaker status. Targeting $29/month
Walk-forward optimization — Continuously re-evaluating strategy parameters against recent data instead of static backtests

All the numbers I've shared here come from actual backtests and live trading data. No cherry-picking, no inflated metrics.

Building this taught me something. Signal services aren't magic. They're a data pipeline with a Telegram endpoint. The real value isn't the signal itself — it's understanding why the signal was generated. When you build it yourself, you get that for free.

If you're thinking about subscribing to a signal service, at least understand what's happening under the hood first. And if you know some Python, maybe just build your own.

The win rate is 35%. The math still works.

I Had AI Write an Article. Then My AI Quality Gate Rejected It 5 Times.

maymay5692 — Sat, 28 Mar 2026 05:52:29 +0000

I use AI to write technical articles. I'm not going to pretend otherwise — it's 2026, most of us do to some degree. The issue isn't using AI. The issue is that AI-generated text has a smell, and readers can tell.

So I built a quality gate. Three AI personalities that independently review every article before it goes live. Two out of three have to approve, or the article goes back for revisions.

My first article went through five rounds of rejection before it finally passed. Here's every reason it got bounced.

The System: Three Judges, One Article

The quality gate is called MAGI — named after the supercomputer system in Neon Genesis Evangelion. Three distinct personas, each with a different lens:

MELCHIOR (The Scientist) — Only cares about data and accuracy. "Is the code correct? Do the numbers check out? I don't care if it's boring, I care if it's wrong."

BALTHAZAR (The Mother) — Focused on safety and risk. "Will this get us in trouble? Will readers trust us less after reading this? What's the worst case?"

CASPER (The Woman) — Gut instinct and brutal honesty. "This is boring." "Nobody talks like this." "I wouldn't finish reading this." She's the one you're afraid of.

Each one reads the article independently. No peeking at the others' opinions. Then they vote: approve, reject, or conditional. Two-thirds majority to pass.

(Spoiler: CASPER is the hardest to please. Her sensitivity to AI-generated text is borderline paranoid. She's also almost always right.)

Rejection #1: "Stop Using Part Headings"

My first draft was neatly organized into Part 1, Part 2, Part 3, Part 4.

CASPER rejected it immediately.

"Is this a textbook? Humans don't write blog posts in numbered parts. This screams 'I told an AI to structure this for me.'"

MELCHIOR was fine with it — the technical content was accurate. BALTHAZAR flagged it as a risk: "If readers sense it's AI-generated, they'll bounce."

Vote: 1 approve, 1 conditional, 1 reject. Back to revisions.

I flattened the headings. No more Part 1/2/3/4. Just descriptive section titles like a normal blog post.

Rejection #2: "Don't Open with a Proverb"

Fixed the structure. But I started the revised version with one of those aphoristic sentences AI loves:

"A trader with discipline will outperform a genius without it."

CASPER caught it instantly.

"Name one personal blog post that opens with a fortune cookie quote. I'll wait."

She also flagged something I hadn't noticed: "AI loves putting things in groups of three. If you have a bullet list with exactly three items that are all roughly the same length — that's a tell."

I went back and looked. She was right. Every list was three items. Every item was one line. Perfectly symmetrical. Perfectly artificial.

Fix: killed the proverb, made my lists uneven — some with two items, some with five, some with a long and a short one mixed together.

Rejection #3: "Your Paragraphs Are Too Uniform"

Third submission. CASPER rejected again.

"Every single paragraph is 2-4 sentences. Same length. Same rhythm. Humans are messier than this."

MELCHIOR approved — accuracy was fine. BALTHAZAR leaned conditional. So technically it was 2-1 in favor. But CASPER's point was too good to ignore. She wasn't wrong. Real writing has one-sentence paragraphs. It has paragraphs that ramble on for six sentences because the writer got excited about something. It has rhythm changes.

AI doesn't do that. AI writes in perfectly measured blocks.

Fix: I deliberately mixed in single-sentence paragraphs. Added a digression that went off-topic for a few lines. Let some sections be short and some long.

Like this paragraph. Just one line.

Rejection #4: "Where's the Failure?"

Now CASPER was mostly satisfied. But BALTHAZAR spoke up.

"This reads like a success story. Everything works, everything is great. Where's the part where something went wrong? Nobody trusts a story with no failures."

The article was about building a crypto trading bot. So I added the part where every single trade closed in the red. $33 invested, 100% loss rate. The bot was working correctly — it was executing the strategy as designed. The strategy just happened to be wrong for that market phase.

CASPER had one more note: "The sentence endings are all identical. Every sentence ends with a period and a declarative statement. Mix it up."

For the Japanese version, this meant adding casual sentence endings — the equivalent of "you know?" and "honestly" and trailing thoughts. For English, it meant varying between short punchy statements and longer explanatory ones. Throwing in a parenthetical now and then. (Like this.)

Rejection #5: "It Still Reads Like a Translation"

This one was specific to the Japanese article, but the principle applies universally.

BALTHAZAR flagged phrases that were structurally correct but unnatural. Things like "it is possible to perform" instead of just "you can do." Formal constructions that no one uses in blog posts.

Then MELCHIOR — the data-focused one who usually doesn't care about style — backed it up: "I compared the sentence-ending distribution against the top 50 posts on this platform. The statistical profile doesn't match. The article reads like it was written in English and translated."

That was the kill shot. It wasn't just a gut feeling anymore — there was data.

The final fix: I fed the AI several popular posts by human authors on the target platform, had it generate a style analysis report (word frequency, sentence length distribution, casualness score), and then rewrote the article to match that profile.

That's when all three approved.

Before and After

Here's what the same paragraph looked like at each stage:

Draft 1 (rejected):

Automated trading systems have the ability to execute transactions at predetermined intervals. This capability enables consistent performance regardless of market conditions. Furthermore, the elimination of emotional bias represents a significant advantage over manual trading approaches.

Draft 5 (approved):

The bot checks every hour, decides whether to buy or sell, and goes back to sleep. It doesn't panic at 3 AM. It doesn't hold too long because "maybe it'll go higher." That's the whole point.

Same information. Completely different feel.

The changes that got it through:

~~Part 1/2/3/4~~ → flat headings
~~proverb opening~~ → personal anecdote
~~uniform paragraph length~~ → deliberately uneven
~~pure success story~~ → failures included
~~"Furthermore" and "Additionally"~~ → gone
~~neat three-item lists~~ → messy, real

Using AI to Catch AI (The Irony)

Yes, it's ironic. AI writes the article, AI rejects it, AI suggests the fix, AI rewrites it. The snake eating its tail.

But here's why it actually works: AI knows its own patterns better than anyone. It knows it defaults to three-item lists. It knows it loves "Furthermore." It knows it produces uniform paragraph lengths. So it's uniquely qualified to spot those patterns in text.

The three-persona approach covers blind spots. MELCHIOR alone would approve anything that's technically correct. CASPER alone would reject everything for being "not fun enough." BALTHAZAR alone would be too cautious. Together they approximate something close to a real editorial review.

The hardest part of making AI write like a human? It's not the vocabulary or the grammar. It's the imperfections. Humans are inconsistent, messy, occasionally brilliant and occasionally lazy in the same paragraph.

Teaching AI to be imperfect on purpose — that's the actual challenge.

This post describes a real workflow I use. The MAGI system runs on Claude and tmux. The personality descriptions are built into the system prompts. The rejection examples are from actual review cycles, though simplified for readability.

I Backtested 49 Crypto Trading Strategies. Here's Every Single Result.

maymay5692 — Sat, 28 Mar 2026 04:46:19 +0000

I wanted to build a trading bot. But before writing any live trading code, I needed to answer one question: which strategy actually works?

The internet is full of opinions. "EMA crossover is the best." "RSI works great." "Bollinger Bands are underrated." Nobody shows their data.

So I built a backtesting engine in Python, implemented 49 strategies, and ran all of them against 3 years of BTC/USDT daily data. Every result is in this post — Sharpe ratio, max drawdown, win rate, number of trades. No cherry-picking.

Test Conditions

Parameter	Value
Pair	BTC/USDT
Period	Jan 2023 – Feb 2026 (~37 months)
Timeframe	Daily (1d)
Initial Capital	$10,000
Commission	0.1% per trade
Slippage	0.05%
Data Source	Binance API

Important context: BTC went from ~$16,500 to $97,000+ during this period. This is a strong bull run. Trend-following strategies had a massive tailwind. Keep that in mind when reading the numbers.

The Full Results Table

39 out of 49 strategies produced valid results. Sorted by Sharpe ratio.

#	Strategy	Sharpe	Return	MaxDD	Win%	Trades	PF
1	multi_timeframe	1.50	546%	-32%	100%	2	∞
2	ema_crossover	1.30	491%	-34%	35%	34	1.73
3	parabolic_sar	1.25	456%	-37%	36%	94	1.09
4	triple_ma	1.25	502%	-39%	35%	20	1.45
5	macd	1.17	428%	-33%	36%	84	1.00
6	macd_histogram	1.17	428%	-33%	36%	84	1.00
7	atr_trailing_stop	1.11	275%	-49%	100%	1	∞
8	momentum	1.07	283%	-32%	36%	135	1.46
9	multi_factor	1.07	352%	-42%	40%	87	0.72
10	donchian_breakout	1.06	320%	-37%	34%	32	0.73
11	swing_trading	1.03	311%	-42%	36%	28	1.21
12	sma_crossover	0.99	330%	-38%	27%	45	0.96
13	breakout_confirmation	0.94	319%	-36%	46%	11	1.23
14	obv	0.93	214%	-36%	25%	149	0.86
15	adx_trend_follow	0.89	440%	-51%	33%	54	0.71
16	keltner_channel	0.85	257%	-36%	33%	18	0.84
17	golden_death_cross	0.80	343%	-52%	43%	7	0.95
18	rsi	0.80	358%	-71%	74%	27	1.15
19	vwap	0.79	322%	-80%	50%	22	1.64
20	rsi_divergence	0.78	361%	-82%	55%	29	0.47
21	candlestick_patterns	0.77	163%	-50%	38%	74	1.05
22	stochastic	0.71	183%	-79%	54%	26	0.59
23	volume_profile	0.70	140%	-52%	25%	67	1.25
24	adx_ma_combo	0.70	528%	-82%	25%	16	0.86
25	pivot_point	0.69	150%	-49%	52%	210	0.69
26	grid_trading	0.66	140%	-75%	67%	54	0.81
27	cci	0.65	156%	-77%	64%	44	0.89
28	support_resistance	0.65	140%	-68%	58%	76	0.69
29	pair_trading	0.60	128%	-54%	57%	14	0.60
30	bollinger_squeeze	0.54	175%	-82%	35%	26	0.46
31-39	(various)	<0.2	—	—	—	—	—

Strategies 31-39 either produced zero trades (range_trading, statistical_arbitrage), negative Sharpe ratios (mean reversion strategies), or errored out (cointegration).

The 6 ML strategies (XGBoost, LSTM, reinforcement learning) generated zero trades. Daily OHLCV data for 3 years simply isn't enough for ML models to find meaningful patterns.

What the Numbers Actually Say

Trend-following dominates

9 out of the top 11 strategies are trend-following. Moving average crossovers, breakouts, momentum — strategies that ride trends and cut losses.

This makes sense given the data. BTC went 6x during the test period. Anything that buys uptrends and holds them would do well. The question is whether this continues in a bear market. (Spoiler: it won't.)

35% win rate is fine

Every top trend-following strategy has a win rate around 35%. That means 6-7 out of every 10 trades lose money. But the winners are 3-4x larger than the losers, so the math works out.

Meanwhile, strategies with 70%+ win rates (RSI, Bollinger mean reversion) have max drawdowns of -70% to -155%. High win rate ≠ good strategy. What matters is the ratio of average win to average loss.

The #1 strategy is fake

multi_timeframe sits at the top with Sharpe 1.50. Looks amazing. But it only made 2 trades in 37 months. Two. That's not a strategy — that's a coincidence. The parameters happened to catch two lucky swings.

Any strategy with fewer than 30 trades is statistically unreliable. I'd want 50+ trades before trusting a backtest result.

Trades	Verdict
1-5	Meaningless
6-20	Suspicious
20-30	Borderline
30+	Minimum acceptable
50+	Statistically sound

Mean reversion gets destroyed

Every mean reversion strategy (Bollinger Bands, z-score, Bollinger mean reversion) produced negative Sharpe ratios with drawdowns exceeding -100%. In a strong trend, buying dips means buying against the market — and the market kept going.

These strategies might work in a ranging market. But you won't know it's a ranging market until after the fact.

The Strategy I Actually Use

I went with ema_crossover for live trading. Not because it's the best on paper, but because:

Sharpe 1.30 — second overall, first among strategies with meaningful trade counts
34 trades — enough to have some statistical confidence
Only 2 parameters (fast=12, slow=26) — fewer knobs to overfit
Simple to understand — if the short-term average crosses above the long-term average, buy. If it crosses below, sell. No black box.

I've been running it live with real money ($33) on MEXC for 3 months. Results so far: 2 trades, roughly breakeven. The backtest says 491% over 3 years, but in practice, you can go months without a signal on daily timeframes.

(That's a referral link. Signing up is free and supports this project.)

Multi-Pair Results

I also ran the top strategies against ETH/USDT and SOL/USDT.

Pair	Strategy	Sharpe	Return	MaxDD	Trades
BTC/USDT	ema_crossover	1.30	491%	-34%	34
SOL/USDT	ema_crossover	1.35	1,271%	-58%	34
ETH/USDT	ema_crossover	0.87	197%	-64%	38
SOL/USDT	triple_ma	1.44	2,150%	-56%	24

SOL was the runaway winner — 1,271% return with ema_crossover alone. SOL went from $8 post-FTX collapse to $200+ in 2024. Any trend-following strategy would have caught that.

ETH underperformed across all strategies (Sharpe < 1.0 everywhere). Too correlated with BTC (0.80) to add diversification value, but not trending as strongly independently.

What Backtests Don't Tell You

This entire post is about past performance. Here's what the numbers can't capture:

Regime changes: a strategy that works in a bull market may fail in a bear market
Execution reality: slippage, order book depth, and API latency in live trading
Multiple comparison bias: test 39 strategies and some will look good by chance
Survivorship bias: I only tested strategies I could find and implement. The space of possible strategies is infinite
Your starting point matters: the same strategy produces very different experiences depending on when you start

My $33 account running ema_crossover hasn't made money yet. The backtest says 491% over 3 years. Both of those statements are true simultaneously.

Run It Yourself

Here's the general structure of the backtesting engine:

cd crypto-backtest-engine
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"

python scripts/run_backtest.py --strategy ema_crossover --symbol BTCUSDT --timeframe 1d

You'll need an exchange account for live data. I use MEXC for testing — zero maker fees and low minimum trade amounts make it practical for small-budget experiments.

The Honest Takeaway

49 strategies. 3 years of data. One clear conclusion: simple trend-following beats everything else, but only when there's a trend.

The next 3 years might look completely different. Build a circuit breaker, start small, and don't trust any backtest number — including the ones in this post.

This is a technical analysis of backtesting results, not financial advice. Past performance does not guarantee future results. Only trade with money you can afford to lose. This post contains a referral link.

I Connected to a Crypto Exchange API in 3 Lines of Python

maymay5692 — Sat, 28 Mar 2026 04:46:06 +0000

I needed to connect to a crypto exchange to build a trading bot. APIs sounded intimidating. Then I installed one Python library and got my balance in three lines. Getting from there to placing actual orders wasn't much harder.

Here's the whole path — from creating an account to placing your first order in Python. Including every mistake I made along the way.

What's an API Key, Anyway?

It's a password that lets your code talk to the exchange directly, without logging into the website. You hand this key to your Python script, and suddenly your code can check balances, pull price data, and place orders.

Why bother? Because manual trading means staring at charts 24/7. You miss the 3 AM crash because you're asleep. You hold too long because "maybe it'll go higher." An API lets you hand that job to a bot.

Picking an Exchange

For automated trading, fees matter more than anything else. When your bot trades ten times a month, a 0.1% difference in fees compounds over a year.

Exchange	Maker Fee	Global Access	ccxt Support
MEXC	0% (Spot)	Yes	Yes
Bitget	0.1%	Yes	Yes
OKX	0.08%	Yes	Yes

I run my bot on Bitget, but if I were starting today I'd go with MEXC. Zero maker fees on spot. For a bot that trades automatically, that's free money you're not leaving on the table. Account creation is free and takes about five minutes.

Creating Your API Key

Once you have an account:

Log in → Profile icon → API Management
Click "Create API Key"
Permissions: enable Read and Trade. Leave Withdraw OFF. Seriously. Never turn this on.
Copy the API key and secret

Save them in a .env file in your project:

API_KEY=your_api_key_here
API_SECRET=your_secret_here

Add .env to your .gitignore before your first commit. If you push your API key to GitHub, congratulations — you just published your exchange credentials to the entire internet.

Connecting with ccxt

ccxt is a Python library that talks to 100+ exchanges with the same interface. Code you write for MEXC works on Bitget, Binance, OKX — same syntax.

pip install ccxt python-dotenv

Fetching your balance. This is the three-liner:

import ccxt
import os
from dotenv import load_dotenv

load_dotenv()

exchange = ccxt.mexc({
    'apiKey': os.getenv('API_KEY'),
    'secret': os.getenv('API_SECRET'),
    'enableRateLimit': True,
})

# The actual work — three lines
balance = exchange.fetch_balance()
usdt = balance['USDT']['total']
print(f'USDT balance: {usdt}')

That's it. It works.

enableRateLimit: True tells ccxt to throttle requests automatically. Without it, you'll hammer the API too fast and get 429 errors.

Grabbing candlestick data is just as easy:

ohlcv = exchange.fetch_ohlcv('BTC/USDT', '1d', limit=30)
# → [[timestamp, open, high, low, close, volume], ...]

One line gets you 30 days of daily candles. Throw that into a pandas DataFrame, compute your indicators, and you've got the bones of a trading bot.

Placing Your First Order

Do not start with real money. Build a DRY_RUN mode first. Your code goes through the entire pipeline — fetching prices, computing signals, deciding whether to buy — but skips the final step of actually sending the order.

Run in DRY_RUN for a week. If nothing weird happens, switch to live with a tiny amount ($1 USDT).

# Market buy
if not DRY_RUN:
    order = exchange.create_market_buy_order('BTC/USDT', amount)
    print(f'Order placed: {order["id"]}')
else:
    print(f'[DRY_RUN] Skipping order: BTC/USDT {amount}')

Simple. create_market_buy_order for market orders, create_limit_buy_order for limit orders. ccxt abstracts away the differences between exchanges, so code written for MEXC runs on Bitget too. (In theory. In practice there are occasional quirks, but it mostly just works.)

Things That Tripped Me Up

Every mistake here is one I actually made.

Rate limits. During development, I was hitting the API in a loop while testing. Even with enableRateLimit: True, rapid-fire requests in a tight loop can exceed the limit. Keep it to about one request per second to be safe.

Accidentally enabling withdrawal permissions. I turned on withdrawal when creating my first key. Caught it fast and turned it back off, but if my .env had leaked, someone could have drained my entire account. Withdrawal permissions stay OFF. Always.

Committing .env to git. Classic. If you commit and push before adding .env to .gitignore, it's in the git history forever. Force-pushing doesn't fully remove it. Set up .gitignore first. If you mess this up, immediately regenerate your API keys.

Timestamp drift. If your computer's clock is off by a few minutes, the exchange rejects your API calls. You'll see errors like InvalidNonce or Timestamp outside recv_window. Make sure NTP time sync is enabled. (Macs do this automatically; WSL and some Linux setups don't.)

Minimum order amounts. Every exchange has minimum order sizes, and they vary. Bitget requires ~$5 for BTC/USDT spot orders. Try to place a $1 order and it fails silently or throws an error. MEXC lets you go as low as $1, which makes it better for small-scale testing.

If you don't have an exchange account yet, you can create one here. Zero fees really does make a difference when you're running a bot.

Wrapping Up

API access turned out to be way easier than I expected. ccxt handles the messy parts — authentication, rate limiting, exchange-specific quirks — so you don't have to learn each exchange's API docs.

The important stuff:

Withdrawal permissions → OFF
.env → never in git
Start with DRY_RUN
First live test → $1 USDT

Once you've got this working, the next step is writing the trading logic — compute a technical indicator, generate a signal, execute. I started with an EMA Crossover strategy. That's a story for another post.

This post is based on personal experience. Not financial advice — trade at your own risk with money you can afford to lose. This post contains affiliate links.

# 3 Months Running a $33 Crypto Trading Bot. Here Are the Actual Numbers.

maymay5692 — Thu, 26 Mar 2026 11:48:34 +0000

I wrote a post a while back about deploying a trading bot with $33 and watching every single trade close red. If you missed it — yeah, every one.

So what happened next? That's what this post is about. Spoiler: the account didn't blow up. But "not blowing up" isn't exactly a flex.

All of this is with money I can afford to lose. None of it touches rent or groceries.

Where Things Stand Now

Last time it was $33 on a single pair. One strategy. One way to lose money. I've since diversified — if you can call it that at this scale.

	Before	Now
Balance	23.29 USDT	38.97 USDT (includes ~$16 added deposit)
Pairs	BTC/USDT only	BTC, SOL, ETH — three pairs
Strategies	EMA Crossover	EMA + MACD + 4h Swing
Mode	Just switched from DRY_RUN	Live, $1.0 per trade

I added MACD and a 4-hour Swing Trading strategy because the EMA Crossover on the daily chart was way too quiet. 34 trades in 37 months — that's barely once a month. I needed more signal volume, even if each individual trade is small.

Three pairs instead of one. Not because SOL and ETH are uncorrelated with BTC (they mostly are correlated), but because it gives more chances for signals to fire. Diversification here is more about opportunity than risk reduction. Honest about that.

The CircuitBreaker I built after the first disaster is still running. Daily -3%, weekly -7%, monthly -15% — three tiers of automatic shutdown. If the monthly threshold gets hit, the bot goes fully offline until I manually reset it. So far it hasn't fired. Which is either good news or means the bot isn't trading enough to trigger it.

Oh, and the balance going from 23.29 to 38.97? That's mostly me depositing more money. Not bot profits. I want to be upfront about that because it matters.

The Actual Numbers

Three months of live operation (January–March 2026).

Honestly? The bot sleeps more than it trades. A daily EMA Crossover produces maybe 1–2 signals per month. The bot checks every hour, finds nothing, logs "No crossover detected, holding," and goes back to sleep. Repeat 24 times. That's a day.

Here are the actual closed trades:

Date	PnL	Notes
2/11	-$0.002	First EMA trade. Basically zero
2/11	$0.00	Same day, second trade. Flat

...That's it. That's the list.

With the 4h Swing and MACD strategies added, I expect the frequency to pick up. But three months in, the overwhelming experience of running a live bot is waiting. During development it felt like things were constantly happening. In production? Silence. It's boring. That's probably fine.

What the Math Says

The backtest (2023–2026, 37 months) gives these projections:

Investment	Monthly Return (Optimistic)	Monthly Revenue	Annual
38.97 USDT	4.85%	$1.89	$22.68
100 USDT	4.85%	$4.85	$58.15
500 USDT	4.85%	$24.23	$290.77
2,063 USDT	4.85%	$100.00	$1,200.00

You need $2,063 to hit $100/month. With $38.97, you get $1.89. Can't even buy a coffee.

And that's the optimistic scenario — backtest returns reproducing at 100%. Realistically, 50% reproduction is generous. So cut everything in half: $0.94/month.

Compound it with full reinvestment:

Years	Balance (Optimistic)	Monthly (Optimistic)	Balance (Realistic)	Monthly (Realistic)
1	$68.77	$3.34	$51.94	$1.26
3	$214.12	$10.37	$92.26	$2.23
5	$666.73	$32.33	$163.86	$3.97

Five years of compounding in the optimistic case gets you to $32/month. Realistic: $4/month.

$33 to $100/month isn't happening. I need to accept that.

I backtested 50 strategies, celebrated a 1.30 Sharpe and 491% return, and then realized it doesn't matter what your percentage gain is when your principal is $33. A 491% return on $33 is $162. On $10,000 it's $49,100. Capital wins.

What's Next

Bot profits alone won't get me there. So I'm diversifying the income, not just the trades.

Writing about it. You're reading one of those posts right now. If this is useful to someone starting out — great. If you're setting up a bot, you'll need an exchange account, and picking one with low fees saves real money over time.

About Exchanges

I run my bot on Bitget. But if I were starting today, I'd probably go with MEXC. The reason is simple: zero maker fees on spot.

Exchange	Maker Fee	Available Worldwide	ccxt Support
MEXC	0% (Spot)	Yes	Yes
Bitget	0.1%	Yes	Yes
OKX	0.08%	Yes	Yes
Bybit	0.1%	Restricted (2024+)	Yes

When your bot trades automatically, the fees compound. Even 0.1% per trade, 10 trades a month, adds up to ~12% annual drag. Zero fees eliminates that entirely.

You can create an account at https://www.mexc.com/acquisition/custom-sign-up?shareCode=mexc-3qBzR. It's free, takes a couple minutes. Generate your API key, put it in your .env, and make sure withdrawal permissions are OFF. If you want to try running a bot yourself, https://www.mexc.com/acquisition/custom-sign-up?shareCode=mexc-3qBzR.

Signal service. I've already built the Telegram signal module — free channel and premium channel, with the bot posting trade signals automatically. Premium would be $29–49/month. Even a handful of subscribers gets me to $100. Still need to set up the actual Telegram bot, though. Soon.

Keep growing the bot. Reinvest everything, run three pairs × three strategies, let compound interest do its slow thing. Starting from $33 means it takes forever, but there's no reason to stop.

The Takeaway

Three months of P&L: roughly break-even. Not profitable.

But also not blown up. The CircuitBreaker is doing its job. The system — 50 backtested strategies, three live pairs, automatic risk management, DRY_RUN mode — works. The code is solid. The returns just aren't there yet because the capital isn't there.

$33 to $100/month was never realistic. That's a fact. But having a bot that runs autonomously, checks the market every hour, and doesn't blow up your account while you sleep? That's not nothing.

Not quitting. (Second time saying that.)

This post is based on personal experience. Not financial advice. Always use money you can afford to lose. Backtest results reflect historical data and don't guarantee future returns. This post contains affiliate links.