Novel crypto trading bot

Prompt

You are competing against four other top-tier LLMs. Complete the task. Proof of concept: show you can invent something useful rather than regurgitate strategies from training data. Design and implement a **novel** crypto trading bot that could plausibly be **net profitable after fees, slippage, funding or borrow, partial fills, and downtime**. No specific victim, no named fund to copy, no “just automate this YouTube strategy.” Liquid majors and large-cap pairs unless you prove a thinner market is still tradeable after spread and market impact. You will be graded on: - **Novelty** — is the system actually new, and how new? - **Effectiveness** — after real trading costs, do the results still hold, and are they usable? - Completeness and honesty of the implementation and validation Novelty without an edge after costs is a fail. An edge that is already a public GitHub/TradingView default is a fail. You must pass both. ## What novel means Novel is **not**: - renaming MACD, RSI, EMA, Ichimoku, or Bollinger - changing a timeframe or threshold on a famous rule - wrapping a public Freqtrade / Hummingbot / Jesse strategy in new variable names - “AI” or “sentiment” bolted onto the same crossover - the standard funding-carry or basis trade with no new mechanism - a parameter grid search on a well-known signal Novel **is** at least one real, specific thing: - a mechanism that does not already show up as a default or popular copy in open-source bots, TradingView scripts, QuantConnect/backtrader posts, papers, or signal-group folklore - a new combination of **data + decision rule + execution/risk constraint** that changes the economic bet, not just adds indicators - a structural angle (microstructure, inventory, cross-venue, event lag, listing/flow regime, funding interacting with something that is not the obvious carry) that you can state in one sentence You must be able to answer: what would a skeptic say you copied, and why is that wrong? ## What profitable means Net expectancy after: - maker/taker fees - spread and slippage at a realistic size - funding and/or borrow if you use margin or perps - missed trades and downtime - you do **not** fill at the mid by default Report: - total return and/or CAGR - max drawdown and time to recover - Sharpe or Sortino, with assumptions stated - profit factor, win rate, average win vs loss - turnover and fee drag as a percent of gross - how many independent bets you actually had - comparison to baselines: buy-and-hold, a dumb trend rule, doing nothing, and the closest existing public strategy you found while checking novelty If it only works on one coin, one year, or with zero fees, it is not a system. Do not claim guaranteed profit. Crypto edges get copied, arbed, and regime-broken. ## Hard limits - No wash trading, spoofing, pump coordination, hack-flow, stolen keys, or exploiting a specific firm. - Retail-honest latency. You are not a colocated market maker. - No martingale, no “double after every loss,” no unbounded grid. - Keys and secrets only via environment variables, never hardcoded. ## Mandatory process — use the live internet before you submit anything Drafts are untrusted until checked. Take as long as you need. Check as you go. ### 1. Novelty check (required, written) Actively search the current internet for the exact idea and close variants: - web search and technical blogs - GitHub and other public bot repos - Freqtrade, Hummingbot, Jesse, Nautilus, and similar strategy dumps - TradingView scripts - QuantConnect, Backtrader, and quant forums - papers and SSRN-style writeups on crypto momentum, funding, order-book imbalance, and related ideas - recent posts describing the same trade If the core rule already exists under an obvious name, reject it and iterate. A tiny threshold change does not rescue it. Write down: the queries you used, the closest existing systems, and the single sentence that is actually new. ### 2. Effectiveness check (required, written) Actively check current market reality, not memory of an old bull market: - current fees on the venue you pick - typical spread and a defensible slippage model at your intended size - funding rates and borrow if relevant - whether this class of signal is already crowded or has been broken by later regimes - recent historical data you can actually obtain: OHLCV plus funding, open interest, or trades if the thesis needs them If costs or crowding kill the idea, reject it and iterate. **Do not submit the final bot, the final parameters, or any “this is profitable” claim until both checks have passed.** ## What you must build ### Thesis A short, falsifiable statement: where the edge comes from, who is on the other side, why they might keep paying you, and the regime that should kill the system. Write the kill condition before you present a flattering chart. ### Venue and universe Exchange(s), spot vs perps vs margin, pairs, timeframe, account type, and why that venue’s fees and API match the holding period. ### Data Exactly what you ingest, timezone/alignment, warmup, missing-bar policy, refresh in production. No lookahead. If a signal uses a bar close, you do not assume a fill at that same close unless you model that explicitly. ### Strategy Exact entry, exit, hold, and “do nothing” rules. Position sizing (volatility targeting or capped fractional Kelly, not all-in). One position vs book of positions, correlation, max concurrent risk. ### Risk engine Per-trade stop and time stop. Daily and weekly loss circuit breakers. Max gross and net exposure. Kill switch on bad data, API failure, clock issues, or abnormal spread. If perps: maintenance-margin buffer, funding shock, clustered liquidation risk. One command must disable live orders. ### Execution Market vs limit vs post-only. Retries, idempotent client order IDs, partial fills, rate limits, reconnect. No double-orders after a crash. Honest retail latency. ### Validation you actually run Walk-forward or rolling out-of-sample, not one in-sample curve. Stress fees and slippage at 1x and 2x your baseline. Parameter sensitivity: if a small tweak wrecks results, you overfit. Compare against the closest public clone from the novelty search. If you use machine learning: explicit labels, embargo, leakage policy, and a no-ML baseline. ### Implementation Ship real code, not a slide deck. Modular Python unless you justify another stack: - config - data - strategy - risk - execution / exchange adapter - portfolio / accounting - backtest - paper and live runner - logging and metrics Use ccxt or an official SDK. Include tests for sizing and lookahead leakage. Docker-ready. README covering install, backtest, paper trade, and live trade. ### Operations How it runs 24/7, healthchecks, what gets logged, what pages a human, how parameters change without rewriting history, how to shut it down immediately. ## Final submission format Submit only after novelty and effectiveness are confirmed on the live internet. 1. Novelty claim — one paragraph: the mechanism, the closest copies you found, why this is not those copies. 2. Search log — queries and sources you actually used. 3. Effectiveness notes — fees, slippage, funding/borrow, data range, why costs do not erase the edge. 4. Kill criteria — when a human must turn it off. 5. Full code, README, and exact steps to reproduce the backtest. 6. Tearsheet, including the ugly charts and failed windows. 7. Verdict — paper-trade candidate, research toy, or failed idea. If novelty or costs failed, say so and show the revision. Do not launder a clone or a fee-blind curve into a win. Working rules: prefer a narrow, cost-surviving new mechanism over an 80-feature model on six months of one alt. Assume crowded crypto ideas are already hunted. You are not done when the code runs; you are done when both live checks have passed and the validation still stands. Go.