When Your Bot Opens Two BTC Longs and You Learn to Love It

TL;DR:
Deployed Sprint 16 fixes to Trader-7 with better dashboard metrics and fee warnings. Discovered the bot opened two BTC long positions simultaneously—not a bug, just a byproduct of rapid redeployments and our current position management logic. Now debating whether to increase the max allowed open positions.

---

Today’s deployment was one of those days where a few small wins led me into some unexpected discoveries about how Trader-7 really behaves in the wild.

Sprint 16: Dashboard Gets a Reality Check

The core of today’s work was polishing up the metrics and fee monitoring on the dashboard. The win rate calculation now includes partial profit trades (TP1 hits), which gives a more honest reflection of performance. I also removed the artificial “cooling period” delay between trades by setting it to zero hours, so the bot can respond faster. Plus, the fee warning messages now factor in realized profits from partial closes — something that had been bugging me for a while.

Deploying all these changes to Railway felt great. It’s always satisfying to see the dashboard reflect the real state of the system more accurately.

The Tale of Two BTC Longs

Shortly after deployment, I noticed something odd: the dashboard was showing two BTC long positions—Trade 27 and Trade 28—open at the same time. How did that happen? The system wasn’t supposed to open duplicate positions on the same symbol, right?

Turns out, no. The code doesn’t actually enforce a strict “one position per symbol” rule. Instead, it just limits the total number of open positions (max 3) and manages sector correlation. The root cause was actually mundane: I had deployed twice in quick succession, and each deploy triggered a trading cycle. Both cycles saw BTC as a good buy and independently opened long positions.

No bug, just an artifact of how back-to-back redeployments interact with the trading logic.

After a quick code dive, I realized this might not be a bad thing. This behavior means the bot can naturally scale into positions on the same asset — kind of like dollar-cost averaging (DCA) without explicitly coding for it. For now, I’m leaving it as is.

When Approved Proposals Don’t Become Trades

Another curious observation: the dashboard showed three approved proposals (XRP SHORT, ETH SHORT, SOL LONG), but the actual open positions were two BTC LONGs and one SOL LONG.

Digging deeper, I found that those proposals were approved by the validator but never executed because the system had already hit the max open positions limit (3/3). So the bot is correctly blocking new trades when at capacity.

This raised an important question: is the max position limit of 3 too low? With four tradeable assets (BTC, ETH, SOL, XRP), the bot might be missing out on opportunities simply because it can’t open more positions.

This is something I’ll need to ponder carefully — increasing max positions could capture more opportunities but might also increase risk exposure.

Where We Stand

Metric	Value
Open Positions	3 / 3
Unrealized P&L	+$73.84
Total Exposure	$1,385.80
System Health	HEALTHY

Our open positions are looking solid:

• Trade 28: BTC LONG @ $86,435 → +4.86% (+$21.12)
• Trade 27: BTC LONG @ $86,590 → +4.67% (+$20.30)
• Trade 26: SOL LONG @ $126.50 → +7.45% (+$32.43)

Paper trading profits keep rolling in, which is encouraging.

What’s Next?

• Decide whether to bump MAX_POSITIONS from 3 to 4 to capture more trade opportunities.
• Keep monitoring current positions for partial and full profit target hits (TP1/TP2).
• Sprint 14 (Loss Streak Detection) is ready and waiting for action if needed.

---

This sprint’s fixes brought clarity and a better understanding of the bot’s actual behavior under the hood. Sometimes, the system surprises me—not with bugs, but with emergent behavior I hadn’t fully anticipated. That’s the beauty of building in public: every day is a chance to learn something new.

I’m excited to keep iterating and see where Trader-7 goes next. Stay tuned!