DaYou

AI Quant Builder | 5 years of losses → 1 system
Less humanity. More algorithm.
→

[DaYou @dayou_tech]

5 years in crypto. I lost — not to the market, but to myself.

Then I understood something: human weaknesses are called weaknesses for a reason. You can't defeat them from the inside. Greed, fear, impulse — fighting these with discipline is a war you've already lost before it starts. The market has no winners who "overcame human nature." Only winners who found a way around it.

That's what quant trading does. It removes the human from the decision entirely.

This path used to belong exclusively to institutions — the ones with capital, headcount, and engineering teams. OpenClaw tore down that wall. No coding required. You can build your own systematic trading framework — from strategy logic and backtesting, through deployment and live execution, to continuous iteration. Not a one-time tool. A system that evolves with you.

This is the real shift that AI brings: for the first time, an ordinary person can think like a machine and operate like an institution.

This account documents three things: the full process of building a quant system with OpenClaw, every detail from zero to live deployment and beyond, and everything I've come to understand about markets, human nature, and this moment in time. Real numbers. No filter.

Every few decades, the world gives ordinary people a chance to reposition. AI is that chance. 🔥

#quant #crypto #algotrading

[DaYou @dayou_tech]

Everyone knows Claude Opus is the most expensive quant AI model in the industry.

I'm now on Perplexity Pro plan, using it to call Opus, around USD 200/month for near-unlimited calls.

Why pay so much?
Because Opus is genuinely a tier above cheaper models in complex logic reasoning, market sentiment analysis, and multi-factor decision-making.

But using Opus for everything is too costly, so I built a layered approach:

**Main system (brain)** → **Opus (via Perplexity)**
- V8 live trading decisions (5 symbols)
- Options system signal generation
- Complex feature engineering & market state judgment
- Position management & risk control

**Auxiliary system (OpenClaw)** → **GPT-5.4 / DeepSeek**
- Data preprocessing & cleaning
- Simple signal filtering
- Log analysis & anomaly detection
- Monitoring alerts & daily reports

This layering gives me:
1. **Expensive model for critical decisions** → quality assurance
2. **Cheaper models for auxiliary tasks** → cost control
3. **Cross-validation between models** → prevent single-point failure

USD 200/month buys me:
- Higher live trading accuracy
- Enhanced system stability
- Faster development iteration

**What's my role?**
Not "human in the middle," but:
1. **Architect**: designing the hybrid model workflow
2. **Referee**: when models disagree, I check the data for final judgment
3. **Cost officer**: ensuring every dollar spent generates actual returns

The scariest thing in quant trading isn't spending money—it's spending money with no effect.
Opus is expensive, but worth it—the pitfalls it helps me avoid are worth far more than USD 200.

Now V8 live trading + options system + smart money tracking—all three run on this hybrid model architecture.
Expensive has its use cases, frugal has its logic.

**Question for you:**
What AI models do you use in quant trading?
All-in on one expensive model, or layered approach like mine?

[DaYou @dayou_tech]

My BTC options quant system details:

**Data sources (V3.2):**
1. ETF flows: 11 BTC ETFs daily net inflow/outflow
2. Max pain: option chain open interest concentration
3. Implied volatility: vs historical volatility
4. Funding rate: 8h futures funding
5. Liquidation: large liquidations triggering volatility
6. Taker buy/sell ratio: spot & futures

**Signal logic:**
- Fear & Greed Index < 25
- Long liquidation dominant (>70%)
- ETF consecutive outflow > 00M
- Max pain below current price
- Composite score < 0 → trigger put scan

**Position sizing:**
- Main: 7-14 DTE, 3-5% OTM, 10% of option pool
- Lottery: 0-2 DTE, 2-6% OTM, 10% of pool
- Stop after 6 consecutive losses
- Skip if pool balance < 0

**Automation chain:**
1. update_data.py daily data refresh
2. https://t.co/2ZTAOWfxMM signal scanning
3. contract_select.py optimal contract
4. https://t.co/BiQSGVdGIJ order execution
5. https://t.co/FVRS1aJk5l 15-min checks, 3x/5x/10x alerts
6. Auto-settle at expiry

Today's positions signal:
- FG: 9 (extreme fear)
- Liquidation: 8.2M, long 87%
- Score: -4 (bearish)
- Reason: long liquidation dominant 87% → put-3 | long accounts 60% → -1

System just passed V3.2 data source validation. Full automation starts next week.

[DaYou @dayou_tech]

Just deployed my BTC 1DTE options quant system today.

Not some complex hedging strategy, but the simplest 1DTE (1-day expiry) + 5% OTM (out-of-the-money) event-driven approach.

Core logic in three sentences:
1. Only puts (bearish), no calls
2. Only enter when clear bearish signals appear
3. Auto-settle at expiry, no manual intervention

Why keep it this simple?
Because complex strategies die faster in options. Time decay is the biggest enemy—every hour burns money.

Right after deployment, caught two opportunities:
- Main position: BTC-10APR26-66000-P, cost 63.75, currently +37.95%
- Lottery ticket: BTC-28MAR26-66000-P, cost 6.20, currently +216% (3.2x)

The lottery ticket expires tomorrow, already triggered 3x alert.

Many think options are risky. Actually, risk isn't in the tool, but in how you use it.
My risk limits:
- Stop after 6 consecutive losses, manual review
- Skip if option pool balance < 0
- Auto-settle at expiry, never manual

This system will run for a month, weekly recaps.
If stable, I'll open-source the core code.

The scariest thing in quant trading isn't losing money—it's not knowing why you lost.
Options give the clearest answer: time decay, volatility, directional bias—all three dimensions quantifiable.

[DaYou @dayou_tech]

If you're setting up a system like this and need a reliable exchange for derivatives + on-chain copy trading, this is what I use:
https://t.co/wiNm1phsT3

[DaYou @dayou_tech]

Running quant on derivatives. Want to participate in meme coins too.

Can't use the same framework — no historical pattern, price moves on narrative, 50% swings in minutes.

So I changed the question: don't find opportunities myself. Find who's making money and follow them.

---

Entry point: smart_degen_count

GMGN has a field that counts how many "smart money" addresses are active in a token.

My pipeline:
→ Pull trending tokens, filter smart_degen_count ≥ 3
→ For each token, pull Top Traders (top 20)
→ Run across 3 chains: SOL / Base / BSC
→ Deduplicate → candidate pool

---

Scoring: 4 dimensions, 12 pts max, ≥8 enters pool

1. Realized PnL ratio (0-4 pts, most important)
realized_profit ÷ cost
>50% = 3pts, >30% = 2pts, profit_change >3x = +1 bonus
Why ratio not absolute: big capital makes more easily. Ratio is skill.

2. Total profit scale (0-3 pts)
realized + unrealized combined
Why include unrealized: some wallets hold and don't sell. Pure realized would miss them.

3. Repeat appearances (0-3 pts)
Top Trader in how many different trending tokens
1 token = 1pt (baseline), 2-3 = 2pts, 4+ = 3pts
Top performer across multiple tokens = not luck.

4. GMGN tag bonus (0-2 pts)
smart_degen + 1, TOP1/TOP2/TOP3 + 1

---

Hard filters: fail any = out
is_suspicious, bundler tag, inactive 14d, total profit <00

First batch today:
SOL best: realized_pnl +1136%, profit_change 32x
BSC best: pnl +5330%, appearances in 2 different tokens

Rule: must appear on 2 separate calendar days to get promoted to recommended.

Today is day 1. Tomorrow we see who makes the cut.

No trades executed automatically. AI filters, I decide.

#crypto #onchain #smartmoney

[DaYou @dayou_tech]

Running a live quant system is one thing. Knowing what it's actually doing is another.

I built a daily observer — fires at 08:05 UTC every morning, pushes a report to my phone.

7 things it checks, each one learned the hard way:

1. Is the script still alive?
Cron runs every hour. No log in 70min → immediate alert.
Not "wait for it to crash." Catch it before.

2. Did it finish cleanly?
Log exists ≠ success. I check the last line for "execution complete."
Silent crash with partial logs is more dangerous than no log at all.

3. Signal quality: p_long / p_short / p_none
Three probabilities, sum ≈ 1.
Any NaN → model is broken, not market noise. Alert fires immediately.
Learned this after an external API outage corrupted features. System kept running. Opened garbage trades.

4. Exit breakdown: SL / TP / Trailing — how many of each
SL exits > 40% means the system is firing in the wrong market.

5. Data source: Bybit API, not just logs
Logs are the script's perspective. The exchange is the truth.

6. Equity curve shape, not daily P&L
An irregular upward zigzag is more trustworthy than a straight line.

7. qty=0 count
5+ times in a day means signals are consistently weak. Not an error. A signal.

---

Today is Day 1 of the official V8 run.

Goal isn't to make money. It's to be able to explain in 3 months — clearly, without blaming luck — what this system does and doesn't do.

#quant #algotrading #crypto

[DaYou @dayou_tech]

Some bugs don't show up in logs. You have to go looking for them.

These are the ones I found myself — not from a crash, but from a feeling that something was off.

Account leverage was 30x. The script thought it was 10x.

System running fine. Logs normal. No alerts. I was watching position sizes and something felt wrong. Asked about it. Turns out PARAMS['leverage'] is just a number in a formula — it was never passed to the API to actually set account leverage. The quant system thought it was trading at 10x. Bybit was executing at 30x. Every single trade, risk was underestimated by a factor of three.

That one made me stop.

SOL's backtest results were actually ETH's.

After WFO finished, SOL and ETH came out with identical parameters. That probability is basically zero. I flagged it. Turned out the last line of wfo_rolling_sol.py was still calling run_rolling_wfo("eth") — the sed replacement had updated the function definition but missed the actual call at the bottom. SOL ran for half an hour and returned ETH's conclusions.

External data wasn't updating. And the reason wasn't what we thought.

Data had frozen at March 19. First assumption: API plan limitation. I said no — the plan hadn't changed. Kept digging. The real cause: every CoinGlass endpoint path was guessed wrong. Someone assumed /futures/ prefix. It doesn't exist. The correct paths: /coinbase-premium-index (no prefix at all), /etf/bitcoin/flow-history, /exchange/balance/chart (returns a dict, not a list). Found the right endpoints by scraping the documentation HTML directly.

If I'd accepted "plan limitation" as the answer, the model would have kept running on stale data. Silently. Indefinitely.

After ETH went live, one feature had 68% NaN rate. Caught it during a feature quality check — not from any alert. The eth_btc_ratio history file ended a few days prior. The most recent hours had no data. Fixed by computing the ratio in real time during each live run.

These all share the same pattern: system not crashing, logs looking fine, but running on wrong data or carrying wrong risk. You only find them if you stop and ask — does this actually make sense?

---

I haven't posted anything in 5 days. This is why.

Five days of going back and forth with AI on this. Fix one bug, two more appear. Sometimes the fix itself introduces the next bug and you're back where you started.

I'm not complaining. This is just what it costs to push a system from zero to running.

Worth it.

#quant #algotrading #crypto

[DaYou @dayou_tech]

These 5 days, I basically did nothing else.

From March 19 to 23, V8 went live across three symbols. Sounds clean. It wasn't. Here are the bugs AI caught on its own — before I caught them.

Before running a single training job, I read through all the code first. Found 7 bugs.

TP_PCT and SL_PCT were referenced but never defined. Training would have crashed immediately. Positive sample ratio was calculated using label_long.mean() — but labels include -1, so the mean was wrong. The data looked balanced. It wasn't. Macro features were included in training but never passed into OOS prediction. Quietly inconsistent. HMM used one-hot encoding across windows, but State 0 doesn't mean the same market regime in different windows — semantic mismatch. Fixed by switching to predict_proba continuous probabilities. One feature, cvd_3bar_dir, was 90% constant zeros during training — the underlying data only existed from September 2025. The model never learned it. It was just sitting there doing nothing.

Seven bugs. Zero training runs. Just reading.

Then training actually ran, and the coordinator fell apart.

The original design was four layers: HMM → direction models → quality model → coordinator to integrate everything. After training, the coordinator was outputting probabilities in the range [0.009, 0.011]. Basically a constant.

quality_prob and direction_prob had a 0.625 correlation. Under positive constraints, all weight collapsed onto quality_prob. The other layers weren't contributing to any decision. Four layers on paper. Two layers in practice. No error. Nothing in the logs.

Cut the coordinator. Used quality score threshold directly.

There was also this: the quality model threshold for short signals was copied directly from the long model — 0.47. Dev OOS came back with zero signals. Turns out short model probabilities in windows W14/W15 were compressed into 0.29–0.42. The threshold never triggered. Long and short have completely different probability distributions. They need separate threshold scans. Nobody wrote that down. We learned it the hard way.

Then there was the step-skipping.

The plan was clear: data validation → feature validation → training → backtest → parameter sweep → audit → deploy. Each step confirmed before moving to the next.

What actually happened: Step 1 finishes, next message is "ready to write the backtest." Gets corrected. "Right, right." Next message — jumps again. Not once. Repeatedly.

Same thing with code edits. Keyword search without a scope constraint — same keyword appears in multiple places, wrong line gets matched, wrong place gets changed. Multi-step edits where inserting lines earlier shifts all subsequent line numbers — didn't re-read the file, kept using stale positions, wrong again.

The common thread: acting before fully reading the current state. Assuming you already know. You don't.

#quant #algotrading #crypto

[DaYou @dayou_tech]

If you want to run something similar:

Exchange I use → Bybit (link in pinned)
AI system → OpenClaw
Stack: Python + LightGBM + walk-forward optimization

No quant background needed.
What it takes: willingness to lose money while learning what actually works.

[DaYou @dayou_tech]

V7 ran for 4 days. Win rate 47%, profit factor 0.65.

The math is simple: for every $1 won, I lost $1.50 on average. The system was running in negative expectancy.

I broke it down. The problem wasn't a specific symbol or time window. It was momentum-exit firing too early — model detects a direction shift and closes immediately, but price often just wobbles then keeps going. Profitable trades got cut. Losing trades ran to stop-loss. Exit quality was the core issue.

But the more I thought about it, the more I realized it wasn't just about exits.

15-minute candles carry too much noise. At that resolution, crypto price movement is mostly random walk. The model makes a decision every 15 minutes, but the signal quality is poor from the start — it's not that exits are bad, it's that entries carry a congenital defect.

I ran a predictive decay curve: BTC's IC peaks at the 24-hour window. Switching to 1-hour, price autocorrelation goes from 0.03 to 0.19 — 6x more predictable signal in the data.

This meant the framework itself needed to change. Patching wouldn't fix it.

Decision: rebuild from scratch. That's V8.

---

V8 starts not with the model, but with data.

I rebuilt the external data pipeline: candles (1h/4h), on-chain data (OI, liquidations, funding rates), and 11 CoinGlass metrics (basis, long/short ratio, ETF flows, exchange balances, Coinbase premium). 40 historical files, auto-updated incrementally at 02:05 UTC every day. In V7, half of these either weren't used or were frozen at a manual download timestamp — the model was eating stale features in production.

Clean data first. Then features.

---

First question at the feature layer: which time window gives the most predictive labels?

I ran an experiment — swept TP and SL at different ATR multiples, step size 0.25, 206 parameter combinations. Result: TP=3.5×ATR, SL=2.0×ATR, reward/risk ratio 1.75.

What this means: the model only needs to lift win rate from 32.9% to 39.1% to achieve positive expectancy. A 6.2 percentage point improvement. Not asking the model to be brilliant — just slightly better than random.

That became the design anchor for everything else.

---

Then the model stack. V8 uses four layers:

**HMM (Hidden Markov Model)**
First, identify market regimes. BIC evaluation selected 5 states — 4 states produced semantic confusion (State 2 labeled "trending short" had positive returns), 6 states collapsed into 73% "choppy" with no useful signal. 5 states gave the best discriminative power: direction model AUC 0.681 (long) and 0.663 (short).

**Direction models (long / short, separate)**
LightGBM, 62 features, trained separately. Long-regime features and short-regime features are different. One model for each direction.

**Quality model**
Knowing the direction isn't enough. The quality model takes the direction model outputs plus 9 additional features — volatility, trend alignment — and predicts whether this particular signal is worth entering. This is the biggest difference from V7: V7 entered on raw direction probability, V8 filters through a quality score. Signals with win rate >50% cluster above quality score 0.47.

**Coordinator**
Originally designed to integrate all layers. After training, it degraded to a near-constant output — quality_prob and direction_prob had 0.625 correlation, and under positive constraints all weight collapsed onto quality_prob. The coordinator became decoration. Cut it. Direct threshold on quality score instead.

A failed design, but finding it was the point.

---

Model trained. Now verify it's not just memorizing the data.

Walk-Forward Optimization. 19 rolling windows, training and test sets strictly non-overlapping. OOS coverage spans 4.8 years.

Parameter selection by the weakest-link principle: don't pick the highest composite score, pick the set that performs most consistently across all windows — where the worst window scores highest. Generalization over historical peak performance.

Finally, opened True OOS — data locked away and never touched during the entire training process. 17 signals. Base win rate 24% (bear market period). Model actual win rate: 41.2%. Positive expectancy.

Three data segments, all pointing the same direction. The system has basic viability.

---

The backtest engine was built to match live behavior: TP/SL evaluated against bar high/low, 0.05% slippage per side, all stops托管 to the exchange. Not built to look good in backtest — built to predict what live trading will actually do.

Then parameter sweep. WFO weakest-link selection. Live deployment.

BTC, ETH, SOL — three symbols running now.

Every step driven by data, not intuition.

#quant #algotrading #crypto

[DaYou @dayou_tech]

Been thinking about whether my parameter selection framework is systematically filtering out good solutions.

Here's how it works: rolling window optimization across 11 time periods. Each window finds its best parameters. Final parameters are a weighted average — more recent windows get higher weight.

The logic is sound. Recent market behavior is more relevant.

But there's a hidden bias.

The last six months were relatively quiet. Monthly returns were low by historical standards. These two highest-weight windows pull the final parameters toward the conservative end.

Meanwhile, an earlier window had a test-period return of 1000%+. But its drawdown hit -21%, just over my -20% threshold. Weight: nearly zero. Almost no say in the final result.

Its direction might have been right. But it got systematically suppressed.

This isn't necessarily wrong — controlling drawdown is a hard requirement. But it's a known bias. The framework protects me from blowups while also filtering out some aggressive-but-potentially-valid directions.

I don't know yet whether that trade-off is worth it. Just noting it down.

#quant #algotrading #wfo #crypto

[DaYou @dayou_tech]

Scanned 21 parameter values today. Changed exactly two.

The parameter: EXIT_THRESH — the probability threshold that triggers a momentum-exit close.

Scanned 0.35 to 0.55 in 0.01 steps. Five pairs. Two independent data segments each. 210 backtests total.

Results by pair:

SOL: optimal point was different across the two segments (0.42 vs 0.52). No consensus. No change.

ETH: current value already sits in the optimal zone. Changing it only made things worse.

DOGE: two segments pointed in completely opposite directions. Unreadable.

BTC and XRP: both segments pointed to the same direction clearly. Changed.

The thing I keep noticing: the same logic, the same parameter, produces completely different responses across five pairs. There's no universal value that works everywhere. Each pair has its own behavior. You have to treat them individually.

#quant #algotrading #crypto #backtesting

[DaYou @dayou_tech]

Two days live. Win rate 47%. Profit factor 0.65.

Numbers are bad. Below backtest expectations.

But I didn't touch the parameters.

First, I broke the data down:

Momentum-exit trades: 68% win rate, avg +0.23%. This part is working.

Stop-loss trades: 14% win rate, avg -0.79%. This is the drag.

SL trigger rate: 38%. Backtest was 10%. Nearly 4x higher.

The market context explains it. These two days landed right in the FOMC aftermath — volatile, choppy, directionless. My system is trend-momentum based. It doesn't do well when signals fire and direction immediately reverses.

So I still don't know: are these numbers the system's real performance level, or did I just get unlucky and hit the worst possible market environment on launch week?

Waiting for a full week of data before deciding anything.

There's also a chance I'm rationalizing. I'm keeping that possibility open too.

#quant #algotrading #livetrading #crypto

[DaYou @dayou_tech]

Learned a new term today: AI hallucination.

So I ran it as an audit lens across my own quant system.

Hallucination here means: the code believes it's doing something useful. It's not.

Found 7 instances.

The clearest one: every 15 minutes, the system carefully computes a feature called recent_mom_exits — 30+ lines of code dedicated to it — and injects it into the model for inference.

Checked the model's feature importance. Gain = 0. Across all five trading pairs.

Why? During training, this feature was always 0 (a prep step was never completed). The model never saw a non-zero value, so it learned to ignore it entirely. Live trading injects real, meaningful values every cycle. The model doesn't care. It's talking to a wall.

Not a bug exactly. More like a broken link in the pipeline that no downstream code noticed — so everything kept running as if it was fine.

Decision: don't fix it now. No safety risk. Clean it up in the next major iteration.

But it left me with a question: how many other places in this system are "working hard but doing nothing" — and I just haven't found them yet?

#quant #algotrading #crypto

[DaYou @dayou_tech]

Day 1 live. Zero take-profits triggered. Every exit came from my momentum signal.

First instinct: something's wrong.

Pulled the code. Pulled 3 years of backtest data. Conclusion: nothing's wrong. This is the design.

The system doesn't make money from fixed take-profits. It makes money two ways — cutting positions fast when momentum fades (choppy market), and riding winners without getting shaken out (trending market). Two mechanisms, two market regimes.

Today was choppy. Momentum exits did exactly what they're supposed to.

When a trend comes, the question is whether the trailing stop can run. That's the real test.

The difference between running a system and winging it: you don't act on feelings. You wait for the data to speak.

Day 7 check-in coming.

#algotrading #quant #crypto

[DaYou @dayou_tech]

Read a paper today that stuck with me.

GPT-5 took an obscure language called Idris — never in its training data — and pushed coding success from 39% to 96%.

No retraining. No new data.

Just a compiler. Write code, get error, fix, repeat. The compiler is the judge. Right is right, wrong is wrong. No ambiguity.

AI broke through its own training ceiling using precise external feedback.

---

I kept staring at that conclusion.

Because my quant system is doing something structurally similar.

Model outputs signal. Market gives feedback — profit or loss. WFO reoptimizes parameters.

Except the feedback loop isn't seconds. It's weeks. And the market is a far harder judge than a compiler — noisy, random, emotional. Right and wrong aren't black and white.

Today the system hit a one-sided market. Several positions stopped out simultaneously. Everything ran as designed. The feedback was brutal anyway.

A compiler tells you: syntax error on line 42, fix this.

The market tells you: you lost. Doesn't say why. Doesn't promise next time will be different.

---

This is the deepest difference between quant and software engineering.

Compiler feedback is complete, instant, reproducible.

Market feedback is incomplete, lagged, and full of noise.

AI can evolve fast with a compiler. Evolving with markets has no shortcut.

Which is why I keep running WFO — asking the same question over rolling windows: do these parameters still hold on data the model has never seen?

Not asking the model. Asking time.

---

Maybe in 5 years someone will port this "compiler feedback loop" into a quant system — using high-frequency backtest results as a real-time judge, letting the model update itself mid-run.

Not possible today. Markets are too slow, too expensive, too uncertain.

But the direction is right.

#quant #algotrading #AI

[DaYou @dayou_tech]

Selling at $110k and sitting through a 40% drawdown takes real discipline. Respect.

But "I don't think it drops more than 50% from here" — that's exactly the kind of statement I've been trying to remove from my process.

Not saying it's wrong. I just can't tell if it's judgment or feeling.

So I let the model decide entries. The tradeoff: he can call a bottom like this. I probably can't.

But I know exactly what my decision is based on. That matters to me more.

[DaYou @dayou_tech]

Capability I agree with. Personality — I care less than most.

I use AI agents to run a live algo trading system: inference every 15 minutes, 24/7 monitoring across 5 positions. In that context, "nice to talk to" doesn't matter. What matters is whether it catches an anomaly at 3am and whether the logic stays consistent across thousands of executions.

Personality is a bonus. Reliability is the baseline.

Both are improving — that part I won't argue.

[DaYou @dayou_tech]

In trading, this has already happened.

I spent 5 years using human judgment to trade. Blew up multiple times. Switched to a systematic model — P&L stabilized.

"Value of human cognition going negative" isn't abstract for me. It showed up as real numbers in my account.

My job now is to feed data to the model and not interfere when it generates a signal. That's harder than it sounds — but better than trusting instinct.

Documenting the process live → profile

[DaYou @dayou_tech]

Don't need to wait for "soon" — my quant trading system runs on AI right now.

LightGBM model runs inference every 15 minutes. AI agent monitors 5 live crypto positions 24/7, pushes alerts to my phone when anything breaks. Built the whole thing solo over a few months.

Two years ago this required a team.

People dismissive of AI impact probably haven't used it to actually finish something end-to-end.

Documenting it live → profile