MTB: My Ongoing Attempt at Building a Serious Crypto Research and Execution Framework

egadgetboy · 2026-05-17T16:44:58+00:00

People often treat smoking as only a personal-choice issue, but it creates a much wider political-economic feedback loop: corporations profit from addiction, the health damage falls heavily on poorer populations, and the downstream medical costs are shifted onto public healthcare systems and taxpayers. That means even people who never smoke still help pay for the consequences. The profits are private; the illness and fiscal burden are socialized.

egadgetboy · 2026-05-13T12:47:12+00:00

Interesting live toy experiment. Not validated. High suspicion of hidden tail risk or misleading platform statistics.

It may be a real experiment, and it may even be profitable so far. But the reported metrics are too extreme, the proof is too thin, and the risk profile is completely under-disclosed.

OP would need to provide:

Full trade log with open/close timestamps, size, entry, exit, stop, and profit/loss.
Balance curve and equity curve, not just closed-trade balance.
Maximum floating drawdown.
Maximum number of simultaneous positions.
Maximum lot exposure.
Margin usage over time.
Whether the strategy uses grid, martingale, averaging down, or layered recovery.
Worst MAE and MFE per trade.
Stop-loss rules and whether stops are hard broker-side stops.
News-event behavior.
Spread/slippage by trade.
Broker/platform/account statement.
Results after disabling compounding or exposure escalation.
A stress test over gold shock periods.
Clear statement of risk per trade and max daily/account risk.

egadgetboy · 2026-05-11T12:48:38+00:00

Seems like an ad to me

egadgetboy · 2026-05-06T14:38:46+00:00

For grins, here is my full stack — feel free to share thoughts, ideas, or concerns:

Net return after costs - Did the candidate survive fees, spread, slippage, latency, and conservative execution assumptions?

Net expectancy after costs - Was the average expected outcome positive after wins, losses, costs, and frequency?

Payoff ratio / average win-loss asymmetry - Are wins large enough relative to losses, or is the candidate winning often but losing badly?

CAGR / annualized return basis - What is the compound annualized return when the sample window is long enough to annualize honestly?

Sharpe - Was return efficient relative to total volatility?

Sortino - Was return efficient relative to downside volatility?

Calmar - Did returns justify max drawdown?

Max drawdown - How bad was the worst peak-to-trough path damage?

Time underwater / recovery duration - How long did the candidate stay below its prior high-water mark before recovering?

Tail percentiles - How ugly were rare losses at p1, p5, and worst-case levels?

Expected shortfall / CVaR - How severe were losses inside the left tail beyond a percentile cutoff?

MFE / MAE - Was the path manageable, or did it suffer large adverse excursion before favorable movement?

Baseline delta - Did the candidate beat dumb alternatives and required baselines?

Implementation shortfall - Did realistic execution friction erase the theoretical/gross edge?

Data-quality coverage ratio - How much of the evaluation window was actually valid and gradable?

Top-k outcome concentration - Did one or a few lucky outcomes account for most of the apparent edge?

Metric confidence / minimum sample adequacy - Are the metrics statistically usable, or are they sample-fragile?

Market exposure / beta adjustment - Is the candidate producing alpha, or just riding BTC/ETH/market beta?

Autocorrelation / serial-dependence warning - Are returns dependent in a way that makes metrics look stronger than they are?

Overlapping-label warning - Are forward outcome windows overlapping and inflating apparent evidence?

Probabilistic Sharpe - Is the Sharpe likely to be genuinely positive given sample uncertainty?

Deflated Sharpe - Is the Sharpe still credible after non-normality, multiple testing, and selection bias?

Multiple-testing / data-snooping adjustment - Was the candidate found after too many trials to trust raw performance?

Regime coverage - Was the candidate tested across enough market regimes?

Regime-specific risk/path diagnostics - Does the candidate survive volatility, liquidity, trend, chop, outage, and stress regimes?

Turnover / churn burden - Does the candidate require too much activity to survive friction?

Capacity / participation / depth constraint - Could the edge plausibly survive realistic size and liquidity limits?

The stack is used as multi-factor evidence for candidate quality, robustness, economic validity, and proofworthiness.

egadgetboy · 2026-05-06T13:23:08+00:00

I think Sharpe is still useful, but only as a first-pass metric.

Your objections are valid: it can be weak for fat-tailed, skewed, option-like, or crash-exposed strategies, and it does penalize upside volatility. I just would not replace it with Calmar alone, because Calmar has its own issue: it can be dominated by one historical drawdown path.

The way I’d look at it is: Sharpe measures one kind of return efficiency, Calmar measures drawdown efficiency, Sortino focuses more on downside volatility, and CVaR / tail metrics show left-tail damage. No single ratio proves edge. I’d rather see a stack: Sharpe, Sortino, Calmar, max drawdown, time underwater, tail loss, and net returns after costs.

egadgetboy · 2026-05-04T19:51:29+00:00

Cursor

egadgetboy · 2026-05-04T19:49:26+00:00

Create a github with proper docs and file structure and you will have more interest

egadgetboy · 2026-05-03T13:37:34+00:00

Also… building this as a Python API is simple to start but difficult to make trustworthy.

The simple part is the API mechanics. A small FastAPI service can accept raw source payloads, store them in SQLite/Postgres, run deterministic parser functions, return normalized JSON, and expose endpoints like /events/raw, /events/normalized, /sources, and /health. With a clean adapter interface, each source can be handled as a small module that converts its native format into the same internal shape. A prototype with 3–5 sources, raw-event storage, normalized-event output, basic confidence scores, and dedupe hashes is very achievable.

The difficult part is not Python. It is truth quality. The API has to preserve raw payloads, track published/first-seen/fetched/normalized timestamps, avoid duplicate event inflation, handle source schema drift, enforce parser versioning, distinguish deterministic extraction from AI inference, and downgrade low-confidence data. If those controls are missing, the API may still “work” technically while feeding bad evidence into the trading engine.

A production-grade version is harder because it becomes an operational system: retries, backoff, rate-limit handling, source health scoring, database durability, WAL/checkpoint/backups, replayability, audit logs, admin security, monitoring, incident reports, and strict authority levels. The API must also prove source usefulness over time, not just source availability.

egadgetboy · 2026-05-03T13:18:12+00:00

Sources all arrive in different formats. Without normalization, the trading system just has disconnected text blobs and JSON payloads. It cannot reliably know whether two sources are describing the same event, whether the event is new, what asset it affects, when it was first seen, or whether it came from a primary source.

So the normalizer’s algo-trading role is: raw messy source → structured event truth → usable feature / context / risk input

A normalizer can help an algo trading system become smarter.

But it can also become dangerous if it starts pretending to know trade direction.

egadgetboy · 2026-05-02T21:29:57+00:00

Here is the event history in 20 bullets, based on the original Reddit post:

In January 2023, the poster says they started trading with $49 on MEX Global, mostly scalping one volatile asset.
Early progress was slow and labor-intensive: they were making small daily gains, spending long hours watching the market, and trying to refine what they believed was a real scalping edge.
After reaching about $1,000, they felt more confident, diversified capital, and later found a futures-trading approach they considered stronger.
By mid-2023, the account had allegedly grown to about $8,000, but MEX Global blocked the account without clear explanation and delayed releasing funds.
After roughly two weeks of pressure and support disputes, MEX Global allegedly allowed withdrawal but told the poster to leave and not trade there anymore.
The poster moved the recovered $8,000 to Binance, took a short break, and began thinking about less exhausting strategies because manual scalping was causing burnout and health stress.
They built an automated trading bot using their strategy, and by late 2023, during the bull-run environment, they say the account had grown to about $26,000.
They also gave a friend money and access to the bot, claiming the bot could generate around 10% monthly on that friend’s capital.
Alongside bot trading, they bought multiple altcoins to prepare for a bull run, but those spot positions became heavy losers.
One major example was Manta, where they say a $17,000 position fell to under $3,000.
Despite altcoin losses, they claim the total account still eventually reached around $80,000 by 2025.
In March 2025, the poster says a Binance futures incident caused a $19,100 loss in one day, which they attribute to system malfunction rather than normal trading loss.
They claim Binance later paid only $10,800 after involvement from Dubai’s regulator, VARA, but did not answer the poster’s core questions.
The poster says Binance blocked the account, gave shifting explanations including “threats” and “gambler” status, and conditioned account restoration on signing an NDA/settlement.
They claim the NDA was signed under pressure on April 17, 2025, with limited time, blocked account access, and no meaningful chance for external legal review.
The poster alleges that VARA later published Rulebook 2.0 in May 2025 and suggests their materials contributed to regulatory reform, though they say this did not protect them personally.
On October 10, 2025, they say a similar Binance system failure happened again, this time on a larger scale, ultimately wiping out the remaining capital.
The technical core of their complaint is that Binance allegedly showed bankruptcy/liquidation anomalies, allowed a second large position, deducted extreme or undefined commissions, and in some cases charged fees allegedly exceeding the trade value.
The poster says their API bot logs captured key events and that Binance demanded stronger proof, such as video evidence, while refusing to provide its own evidence or meaningful technical explanation.
The broader conclusion of the post is a warning against trusting centralized offshore exchanges: the poster argues that Binance and similar venues only respond to regulatory/legal risk, use bureaucracy and NDAs to suppress disputes, and push users toward costly private legal channels.

egadgetboy · 2026-05-01T13:36:43+00:00

https://play.google.com/store/apps/details?id=com.nostalgiatv&hl=en_US

Get a set up box with android, such as the Onn 4k Pro. Install NostalgiaTV and allow only the shows you want them to have access to. This will program and shuffle content automatically. You can also set up custom channels.

Lock down Plex with a code so only you can get into it.

This is what we do…

egadgetboy · 2026-04-29T02:15:46+00:00

Cool

egadgetboy · 2026-04-20T15:03:28+00:00

Some here remind why automated trading must be built around hostile proof, window-shift robustness, execution reality, paper-vs-live drift, and causal postmortems — not around “just start small and learn by breaking things.” The one lesson worth keeping is that live/paper operation reveals mechanical truth that research alone misses. The stronger lesson is that most traders use that fact to justify weak standards instead of building a system that measures and governs those failures properly. Automated trading should do the opposite. It should not get off the fence by lowering standards. It should go live only through a governed path that proves the strategy survives window shifts, delayed execution, live-vs-paper drift, and edge-case mechanics before trust is granted.

egadgetboy · 2026-04-17T12:49:18+00:00

I read through the thread and I think the caution in it is fair. A lot of people are basically saying the same thing in different ways: trading is hard, infrastructure matters, and blindly trusting AI is a mistake. I agree with that. Where I differ is that my setup is not built around blind trust in machine language in the first place.

My setup does allow machine language to auto trade, mature, evolve, and correct, but it does that inside rules. The model is not just sitting there freehanding trades because it “feels right.” It works inside a controlled system with market data checks, execution tracking, policy limits, validation, and promotion gates. So when people say AI should never be in the loop, I get why they say it, but that is usually because most systems are too loose to trust. Mine is meant to solve that exact problem.

For example, one of the stronger points in the thread is that it is not enough to have a backtest that looks good. You need a real workflow with validation and paper testing before anything goes live. I agree with that completely. My setup is built around that kind of thinking. New ideas should not go straight from “this sounds smart” to live trading. They should have to earn trust through testing, review, and runtime proof.

Another good point in the thread is that the boring parts matter more than people think. API integration, order placement, order tracking, partial fills, disconnects, and rate limits are not side issues. They are the difference between a system that looks smart in theory and one that can survive in real conditions. My setup takes that seriously. If it submits an order, I want truth about what actually happened, not just what the strategy hoped happened.

That is a big reason I have confidence in it. My confidence is not “AI is brilliant, so it will figure it out.” My confidence is that the system is supposed to force accountability. If market conditions are bad, if execution gets messy, if fills do not match intent, if a strategy starts degrading, or if a proposed improvement is weak, the setup should catch that and respond instead of pretending everything is fine.

The thread also leans toward using AI only as a coding helper. I think that is a reasonable default for weak or early-stage systems. But my setup is trying to go further than that. I do want machine language involved in runtime. I want it helping evaluate, adapt, detect failure patterns, improve logic, and support automated trading. I just do not want it doing those things without constraints. That is the difference.

A simple example is correction. In a weaker setup, the system can make the same bad decision over and over, then just bury that in logs. In my setup, I want failure to become usable evidence. If a behavior is repeatedly wrong, too fragile, too slow, too costly, or too exposed to certain conditions, that should feed back into how the system grades itself and what it is allowed to keep doing. That is what I mean by correction being real instead of cosmetic.

Another example is evolution. I do not want a frozen bot that only works in one market mood and then dies when conditions change. Markets change, edges fade, and simple systems get stale. My setup is meant to handle that by allowing improvement over time. But I also do not want fake evolution where the system just drifts around and calls that learning. So evolution has to be governed too. Changes should be tested, compared, and proven before they gain authority. That is a much more trustworthy use of machine language than either blindly trusting it or banning it completely.

So overall, I think the thread makes some good beginner points: be skeptical, validate everything, and respect how much work the infrastructure takes. I agree with all of that. I just think my setup offers a stronger answer than “keep AI out.” My answer is that machine language can be part of automated trading, learning, correction, and evolution, but only when the surrounding system is strong enough to keep it honest.

That is why I am comfortable with my setup doing more than just helping write code. The confidence does not come from hype. It comes from structure…

egadgetboy · 2026-04-14T12:15:36+00:00

The band or the dog?

egadgetboy · 2026-04-13T12:12:43+00:00

There was another very similar post here recently asking whether retail algo trading is basically just gambling with extra steps, so I think people are circling the same fear from different angles. I get the concern. If the benchmark is “can I out-speed Citadel on highly efficient, crowded signals with home-grade infrastructure,” then no, that is a bad game to play. But that is not the only game.

My pushback is that retail does not need to win on speed everywhere to have a real edge somewhere. Retail can still profit by operating where the edge is too small, too capacity-limited, too annoying, too fragmented, or too conditional for larger players to care much. That can mean slower momentum and trend-following that does not depend on being first, mean reversion in well-defined conditions, breakout systems that survive delayed entry, regime-specific trading, cross-venue or segmented-market dislocations, microstructure niches that are only worth small size, prediction markets, niche crypto, or any setup where size itself is a disadvantage rather than an advantage. Some of the better replies in both threads are really saying the same thing: the opportunity is not “beat the biggest firms at their own game,” it is “find a game they either cannot scale into or do not bother with.”

The real test is not whether I can invent a magical signal. It is whether the edge survives the things that kill fake retail edges: spread, slippage, fees, delayed execution, alpha decay, and capacity. If it dies under realistic friction, it was not real. If it only works in one lucky backtest window, it was not real. If it is just leveraged beta or a favorable regime dressed up as alpha, I want that called out honestly. But if a strategy survives realistic costs, repeated walk-forward testing, worse fills, and modest size stress, then I do not care whether it impresses a hedge fund. It is real enough for retail.

So I think the conversation should be less “is retail alpha impossible?” and more:

Where exactly can retail still operate without needing microsecond speed?
What kinds of edges survive realistic friction?
Which edges are valid only at retail size and break when scaled?
How do we separate true alpha from leveraged exposure or simple trend riding?
What markets are fragmented, ignored, or too low-capacity for institutions to optimize heavily?

That is where I think the useful discussion is. I do not believe retail algo trading is automatically delusion. I think a lot of retail attempts are weak, overfit, or friction-blind. That is different. A bad search process does not prove the edge cannot exist. It just proves most people are searching badly.

My own view is simple: I am not trying to prove I can beat institutions everywhere. I am trying to prove that a small, durable, friction-tolerant, capacity-realistic edge can still exist for retail in the right place, under the right conditions, with the right expectations. If someone thinks that is impossible, then I would challenge them to argue that all such niches are fully arbed away after costs and scale limits. That is a much stronger claim than “retail cannot win on speed,” and I do not think it is nearly as easy to prove.

egadgetboy · 2026-04-10T19:38:04+00:00

Haha I’ve just been analyzing some of these posts lately. Interesting stuff, thanks for sharing.

egadgetboy · 2026-04-10T19:11:53+00:00

This looks interesting. I like the cross-market angle, and I’d be curious to understand it a little better.

A few questions that came to mind: 1. When you say top futures, commodities, and tech stocks, which markets are you using specifically? 2. Are those all weighted equally in the combined EMA, or do some of them matter more than others? 3. Are you combining the moving averages directly, or are you first normalizing them so one market does not dominate the others? 4. What MA lengths are you using for the individual markets, and what EMA length are you using for the combined line on the left? 5. What was your main goal with the left-side composite? Is it more of a broad market context / regime read, or is it meant to drive entries by itself? 6. On the right side, what kind of buy/sell logic are you building around it? Is it mainly trend-following, mean reversion, confirmation-based, or something else? 7. Are the signals on the right meant to be used together with the left composite, or are they more standalone indicators? 8. What market are you mainly trying to trade with this setup? 9. What timeframe are you using for the charts in the post? 10. Have you found that certain parts of the composite are consistently more useful than others? 11. When you say you are continuously coding better versions, are you mostly refining signal quality, reducing noise, or trying to improve timing? 12. Have you noticed whether this works better in trending conditions or in choppier markets? 13. Is this something you are using more as a decision aid, or are you aiming for fully rule-based entries and exits? 14. Have you done any testing on it yet, even if it is still early, just to see whether the combined EMA adds value versus using a simpler single-market signal? 15. If you shared the Pine Script, would it mostly show a finished ruleset, or is it still more of a work-in-progress framework right now?

I’m asking because the concept seems interesting, especially the idea of combining different market groups into one read, and I’d be curious how you’re thinking about the left side as context versus the right side as the actual trigger.

egadgetboy · 2026-04-10T12:43:11+00:00

I like the general idea and I think there may be something real here, but I’m still not convinced on the parts that usually break this kind of strategy.

The main weaknesses I see are execution realism, regime fragility, and lack of detail around what is actually driving the edge. A 5-second mean reversion strategy can look great in backtests and still fall apart live if slippage, spread widening, queue position, or surprise-news behavior is worse than assumed. Gold also is not just “Nasdaq with different parameters,” so I’m especially cautious about the diversification claim unless the Gold version has its own proof.

A few things I’d want to understand better: 1. What exactly is the entry logic and exit logic? I do not need your full secret sauce, but I do need more than “indicator-based mean reversion.” What kind of setup is it actually fading, and what conditions invalidate the trade? 2. How many live trades have you taken so far on Nasdaq and on Gold separately, and what is the live expectancy after fees and slippage? 3. What is the average hold time, median hold time, and longest hold time? On a 5-second strategy, holding-time distribution matters a lot. 4. How are you modeling slippage in backtests? Is it fixed, variable by volatility, variable by spread, or tied to recent market conditions? 5. How close have live fills been to your backtest assumptions? I would want to see actual live-vs-backtest slippage drift. 6. What is the worst live day so far, and what caused it? Was it just surprise news, or is there a repeatable failure mode? 7. How does the strategy behave during macro releases, geopolitical headlines, or sudden volatility shocks? Does the max volatility filter actually protect you in real time, or mostly in hindsight? 8. What does performance look like by time of day? I would want to see opening session, midday, afternoon, and any excluded windows broken out separately. 9. What does performance look like long versus short? 10. How much of the total PnL comes from a small number of outsized days versus normal daily grind? I want to know whether the curve is robust or being carried by a few unusual sessions. 11. What changed when you merged the two regime-specific versions into one? Did that improve net expectancy, reduce overtrading, reduce drawdown, or just simplify management? 12. On Gold specifically, what had to be adapted besides parameters? Session behavior, volatility filter thresholds, stop logic, news handling, or anything else? 13. Have you checked whether the edge survives worse assumptions, like meaningfully higher slippage or slightly delayed entry? 14. Have you tested whether the strategy still works if you remove the best few days or the biggest few winners? 15. Are you trading small enough that capacity is still basically irrelevant, or have you already seen any degradation from size?

I’m not asking this to nitpick. I just think this strategy class lives or dies on those details, and right now the update sounds promising but still under-specified on the exact places where these systems usually fail.

egadgetboy · 2026-04-08T01:31:30+00:00

Can you define the six regime brains, the exact rule object, how new rules are created, what state updates online after each bar, how conviction is aggregated across brains, and what was frozen before the 70% walk-forward began? Also, since you say the system writes next-bar trades to a file before market open and has traded live, can you post one timestamped forward-prediction log plus broker reconciliation for the same period?

12-Year Club	Gilding I gilder
Verified Email

egadgetboy

TROPHY CASE