# 260629 Bot Umsetzungsplan (extrahiert)

Bericht: Ausbau des Crypto_Agent zum autonomen Hyperliquid-Trader und Anlage-Assistenten

Kurzfazit

Der aktuelle Crypto_Agent ist auf dem richtigen Weg, aber er muss von einem Signal-/Paper-Bot zu einem echten Portfolio- und Trading-System weiterentwickelt werden. Das Hauptproblem war bisher nicht nur die API oder die Strategie, sondern die Art der Entscheidungslogik: Der Bot hat zu oft einen späten Entry genommen, also nach einem Pump gekauft, kurz bevor Momentum erschöpft war. Genau das muss jetzt systematisch gelöst werden.

Meine klare Empfehlung:

v76 strict bleibt die Hauptstrategie für kurzfristiges Hyperliquid-Trading, aber sie muss um vier Ebenen erweitert werden:

Anti-Chase-/Retest-Logik, damit er nicht am lokalen Top kauft.

vollständiger Stop-/TP-/Trailing-Paper-Lifecycle, damit Paper wirklich live-nah wird.

Multi-Timeframe- und Marktregime-Engine, damit er nicht jedes Signal gleich behandelt.

Portfolio-/Holding-Modul, damit er nicht nur Daytrading macht, sondern auch Swing- und längerfristige Positionen verwalten kann.

Parallel dazu sollte Copytrading nicht direkt live kopieren, sondern als Research- und Shadow-Copy-System laufen.

1. Aktueller Stand des Projekts

Aus den bisherigen Berichten ergibt sich ein klares Bild: Der Bot hat sich von einfachen Dip-/Rebound-Ideen wegentwickelt. Die alten Rebound- und Mean-Reversion-Varianten waren anfällig; der sinnvollste Kern ist inzwischen Confirmed Squeeze Breakout + konservatives Risk-/Exit-Management. Das deckt sich mit dem ursprünglichen Konzept, das v66/v69/v75 als frühe Alpha-Quellen identifiziert hatte, aber wegen WLD-Leakage und kleinem Sample noch nicht live gehen wollte.

Jarvis meldet nun für v76 strict deutlich stärkere Paper-Zahlen:

Trades: 16’800

Netto-Paper-PnL: +2’835.00 USDC

PnL ex-WLD: +2’474.38 USDC

Top-Coin-Share last 30: 20%

Marktregime: breakout_confirmed

Das ist viel besser als der frühere Zustand. Früher war das Hauptproblem: WLD dominierte fast alle Gewinne. Jetzt sieht es laut Jarvis so aus, als ob die Strategie breiter funktioniert. Trotzdem gibt es einen entscheidenden Haken: Jarvis selbst sagt, dass der Paper-Exit noch nicht realistisch genug ist, weil erwartete Bewegung und Kosten verrechnet werden, aber nicht der vollständige echte Trade-Lifecycle simuliert wird.

Das ist der wichtigste Punkt: Eine gute Paper-PnL ist erst dann belastbar, wenn Entry, Fill, Stop, Trailing, Take-Profit, Funding, Slippage, Time-Exit und Reconcile wirklich wie im Livebetrieb modelliert werden.

2. Was im GitHub-Repo auffällt

Das öffentliche GitHub-Repo wirkt weiterhin wie ein älterer Stand. Der öffentliche AutoTrader.py verwendet direkt ccxt.hyperliquid, lädt die Wallet-/Private-Key-Konfiguration und ruft exchange.load_markets() auf. Auffällig ist auch exchange.session.verify = False, was für produktive Systeme ein Sicherheits-/Qualitätsproblem ist.

Der alte AutoTrader.py verwendet zwar Hyperliquid-WebSocket allMids und candleSnapshot, aber er ist monolithisch und nicht die finale v76-Architektur. Er holt metaAndAssetCtxs, Volumen, szDecimals und Positionen, was als Rohmaterial gut ist. Gleichzeitig enthält er direkte Live-Orderstellen für Exit und Entry via create_order, was genau der Grund ist, warum dieser alte Code nicht mehr der Live-Kern sein darf.

Positiv: Es gibt im Repo bereits read-only Account-Logik, die offene Perp-Positionen, PnL, Spot-USDC, freie USDC und Margin-Auslastung ermittelt. Diese Logik ist ein guter Baustein für Reconcile/Portfolio-Status.

Konkrete Schlussfolgerung:Der öffentliche GitHub-Stand sollte mit dem lokalen v76-Branch synchronisiert werden. Sonst besteht ein Betriebsrisiko: Dokumentation, GitHub und echte Runtime laufen auseinander.

3. Zielbild: Was der finale Bot sein soll

Der finale Bot sollte nicht einfach ein “Trade-Signal-Bot” sein. Er sollte drei Rollen haben:

3.1 Hyperliquid Trading Agent

Er handelt autonom mit einem kleinen, klar abgegrenzten Trading-Wallet auf Hyperliquid. Er nutzt:

v76 strict

+ Anti-Chase-Filter

+ Multi-Timeframe-Regime

+ Funding/OI/Liquiditätsfilter

+ realistischen Stop-/TP-Lifecycle

+ Reconcile Watchdog

+ Daily Loss Gate

+ Portfolio Exposure Limits

3.2 Crypto Portfolio Manager

Er soll nicht nur Minuten-Trades machen, sondern auch entscheiden:

Coin kurzfristig traden?

Coin für Swing-Hold interessant?

Coin für längerfristige Allokation geeignet?

Position reduzieren?

Position halten?

In USDC bleiben?

Wichtig: Längerfristige Holdings sollten möglichst Spot oder sehr niedriger Leverage sein. Perps sind für lange Haltedauer wegen Funding-Risiko nicht immer ideal.

3.3 Anlage-Assistent für dein Gesamtportfolio

Für Aktien, ETFs und Krypto, auf die er keinen Trading-Zugriff hat, soll er Empfehlungen geben:

Kaufen

Halten

Reduzieren

Verkaufen

Rebalancing

Risiko reduzieren

Watchlist

Aber: Er soll dort nicht automatisch handeln, sondern auf Basis des Jarvis-Finanzdashboards Empfehlungen ausgeben.

4. Datenquellen: Was er wirklich braucht

4.1 Hyperliquid als Primärquelle

Hyperliquid bleibt die wichtigste Quelle, weil dort gehandelt wird. Die Info API liefert Exchange- und User-Daten; wichtig ist, dass Accountdaten mit der echten Master-/Subaccount-Adresse abgefragt werden und nicht mit der Agent-Wallet-Adresse. (Hyperliquid Docs)

Zu verwenden:

Preise / allMids

Candles 1m, 3m, 5m, 15m, 1h, 4h, 1d

L2Book / Orderbuch

Trades / Tape

Funding

Open Interest / active asset context

Open Orders

Order Updates

User Events

User Fills

Clearinghouse State

Portfolio / Account Equity

Hyperliquid-WebSocket unterstützt genau die relevanten Feeds wie allMids, clearinghouseState, openOrders, candle, l2Book, trades, orderUpdates, userEvents und userFills. (Hyperliquid Docs)

Wichtig: REST darf nicht wild gepollt werden. Hyperliquid dokumentiert ein aggregiertes REST-Weight-Limit von 1200 pro Minute; l2Book, allMids, clearinghouseState und orderStatus haben Weight 2, andere Info-Requests teilweise Weight 20. (Hyperliquid Docs)

4.2 CoinGecko als Markt-/Fundamental-Kontext

CoinGecko sollte als zweite Basisquelle kommen, nicht für schnelle Entries, sondern für Kontext:

Market Cap

Market-Cap-Rank

24h Volume

1h/24h/7d/14d/30d/200d/1y Performance

Supply / FDV

ATH-/ATL-Abstand

Trend-/Kategorie-Zuordnung

Der /coins/markets-Endpoint liefert genau solche Marktdaten wie Preis, Market Cap, Rank, Volume, High/Low 24h, Supply, ATH/ATL und Preisveränderungen über verschiedene Zeiträume. (CoinGecko API)

Nutzen:

illiquide Coins meiden

zu kleine Coins begrenzen

FDV/Market-Cap-Risiko erkennen

Momentum über mehrere Tage bewerten

längerfristige Holdings besser einordnen

4.3 CoinGlass oder ähnliche Derivatives-Daten

Für Perps wäre ein Derivatives-Datenanbieter sehr hilfreich. CoinGlass bietet nach eigenen Angaben Futures-, Spot-, Options-, L2/L3-Orderbook-, Liquidation-, Funding- und Market-Snapshot-Daten; es deckt auch Hyperliquid ab. (coinglass)

Wichtig wären:

Open Interest Change

Funding Rate History

Liquidation Heatmaps

Long/Short Ratio

Exchange-wide OI

Liquidation Clusters

Basis / Perp Premium

Diese Daten helfen gegen das Problem “Bot kauft am Top”:

Wenn Preis stark gepumpt ist, OI steigt und Funding extrem positiv:

→ crowded long

→ kein Entry oder nur Retest abwarten

Wenn Preis aus Squeeze ausbricht, OI moderat steigt und Funding neutral:

→ gesünderer Breakout

Wenn Preis fällt, OI fällt und Liquidationen durch sind:

→ möglicher Rebound nach Reclaim

4.4 TradingView Webhooks

TradingView ist nützlich, aber nur als Signalquelle, nicht als Trade-Autorität. TradingView-Webhooks senden bei Alerts POST-Requests an eine URL; TradingView weist selbst darauf hin, keine sensiblen Daten in Webhook-Bodies zu senden und sichere/authentifizierte Endpunkte zu verwenden. (TradingView)

Empfehlung:

TradingView Gaussian Channel: Paper-only sammeln

Supertrend/EMA/MACD/Bollinger-Signale: als Confluence

TradingView Ideas: Sentiment/Research, nicht Trading

4.5 Social-/Sentiment-Daten

Santiment wäre für On-chain- und Social-Metrics interessant. Die Santiment API nutzt GraphQL und ist darauf ausgelegt, gezielt benötigte Daten abzufragen statt alles zu überladen. (academy.santiment.net)

Mögliche Signale:

Social volume spike

Sentiment extrem positiv/negativ

Developer activity

Exchange inflows/outflows

Whale movement

Network activity

Aber: Sentiment ist Kontext, nicht Entry-Signal. Ein Coin, über den alle reden, ist nicht automatisch ein Kauf.

5. Indikatoren und Marktinformationen, die der Bot nutzen sollte

Der Bot sollte keine Strategie aus einem einzelnen Indikator bauen. Stattdessen braucht er eine Score Engine, die mehrere unabhängige Dimensionen kombiniert.

5.1 Trend Score

Ziel: Nicht gegen den Markt handeln.

Daten:

EMA 20/50/200

SMA fast/slow

VWAP / Anchored VWAP

Higher highs / higher lows

BTC/ETH Trendfilter

1h/4h Richtung

Regel:

Long nur aggressiv, wenn 5m/15m Trend positiv und 1h nicht klar risk_off.

Bei 1m-Signal gegen 1h-Trend nur halbe Größe oder kein Trade.

5.2 Momentum Score

Ziel: Kauf nicht nach erschöpftem Pump, sondern bei frischem Momentum.

Daten:

RSI

MACD

Rate of Change

Volume Spike

Breakout candle strength

Relative Strength Rank gegen Watchlist

MACD ist klassisch dafür gedacht, Änderungen in Stärke, Richtung, Momentum und Dauer eines Trends zu zeigen. (Wikipedia)

Wichtig: Momentum darf nicht “zu spät” sein. Darum braucht es den Anti-Chase-Filter.

5.3 Volatility / Squeeze Score

Ziel: Breakouts aus echter Kompression erkennen.

Daten:

Bollinger Band Width

ATR %

Keltner Channel / TTM-Squeeze optional

Donchian Channel

Range Compression

Bollinger Bands werden zur Darstellung von Preis und Volatilität genutzt; die Bandbreite ist besonders nützlich, um Kompression und spätere Expansion zu erkennen. (Wikipedia)

5.4 Liquidity / Execution Score

Ziel: Nur handeln, wenn der Trade real ausführbar ist.

Daten:

Spread %

Top-of-book depth

Top-5-depth

Orderbook imbalance

Slippage estimate

Minimum notional

Tick/lot rounding

L2 instability

Hyperliquid bietet l2Book-Snapshots und WebSocket-Feeds, die für Spread, Depth und Slippage-Schätzung genutzt werden können. (Hyperliquid Docs)

5.5 Derivatives / Crowding Score

Ziel: Nicht in überfüllte Trades einsteigen.

Daten:

Funding Rate

Funding Trend

Open Interest Change

Long/Short Ratio

Liquidation Clusters

Basis / Perp Premium

Beispiele:

Preis pumpt + OI pumpt + Funding extrem positiv

= FOMO Long, erhöhtes Top-Risiko

Preis bricht aus + OI steigt moderat + Funding neutral

= gesünderer Breakout

Preis fällt stark + Liquidationen hoch + Reclaim über VWAP

= möglicher Rebound, aber nur bestätigt

5.6 Regime Score

Ziel: Strategie je Marktphase anpassen.

Regime-Kategorien:

risk_on

risk_off

choppy

squeeze_building

breakout_confirmed

failed_breakout

rebound_after_flush

no_trade_environment

Konsequenz:

risk_on: Breakout-Strategie normal handeln

choppy: weniger Trades, Retest abwarten

risk_off: keine Altcoin-Longs oder nur BTC/ETH klein

failed_breakout: keine Re-Entries direkt danach

squeeze_building: beobachten, noch nicht kaufen

5.7 Portfolio / Allocation Score

Ziel: Nicht jeden Trade isoliert betrachten.

Daten:

offene Exposures

Coin-Korrelation

Sektor/Kategorie

Top-Coin-Anteil

WLD-/Altcoin-Anteil

max. Gesamt-Notional

max. Risiko pro Coin

USDC Reserve

6. Das Hauptproblem “Entry kurz vor Top” lösen

Das ist der wichtigste Strategie-Fix.

6.1 Kein Kauf direkt nach vertikalem Pump

Regel:

Wenn Coin in den letzten X Minuten > 2.0–2.5 ATR gestiegen ist:

→ kein Market Entry

→ nur Retest/Reclaim handeln

Beispiel:

SOL steigt in 10 Minuten stark

Breakout-Signal feuert

Bot kauft NICHT sofort

Bot wartet, ob der alte Breakout-Level hält

Erst wenn Retest + Käuferreaktion + Volumen passt, Entry

6.2 Retest statt Chase

Neue Entry-Typen:

Breakout Entry:

nur wenn Ausbruch frisch und nicht überdehnt

Retest Entry:

nach Breakout Rücklauf zum Ausbruchsniveau / VWAP / EMA

dann Reclaim mit Volumen

Reclaim Entry:

nach Drop nur, wenn Preis eine wichtige Linie zurückerobert

6.3 Exhaustion-Filter

Blockiere Long, wenn:

RSI 1m/5m extrem hoch und fällt

Volume climax ohne Follow-through

lange obere Wick

Funding zu stark positiv

OI steigt parabolisch

Preis weit über VWAP/EMA/ATR-Band

BTC/ETH gleichzeitig schwach

6.4 MFE/MAE-Auswertung für Entry-Qualität

Für jeden Paper- und Live-Trade muss gespeichert werden:

MFE = maximaler zwischenzeitlicher Gewinn

MAE = maximaler zwischenzeitlicher Verlust

Time to MFE

Time to MAE

Entry distance from VWAP

Entry distance from breakout level

Entry after pump distance in ATR

Daraus lernt Jarvis:

Kaufe ich zu spät?

Sind Retest-Entries besser?

Sind Breakout-Entries ohne Retest profitabel?

Welche Coins brauchen mehr Geduld?

7. Paper-Modell muss live-realistischer werden

Jarvis sagt selbst: Der aktuelle v76-Paper-Exit ist noch nicht sauber genug. Das ist entscheidend.

Aktuell klingt es so, als ob der Paper-Run erwartete Bewegung gegen Kosten verrechnet. Das ist ein guter Screening-Test, aber kein echter Trade-Lifecycle.

Der Bot braucht ein Event-driven Paper Engine:

Entry-Signal

→ simulierte Order

→ Fill oder kein Fill

→ Stop sofort gesetzt

→ Kursverlauf Tick/Candle für Tick/Candle

→ Stop wird ausgelöst oder nachgezogen

→ Take-Profit / Trailing / Time-Exit

→ Funding akkumuliert

→ Fees und Slippage abziehen

→ realistische Netto-PnL

In moderner Trading-Agent-Forschung wird genau diese realistische Simulation betont: order book, maker/taker semantics, Gebührenmodell und reproduzierbare Episoden sind wesentlich, weil naive Agents durch Kosten und Execution-Effekte unterperformen können. (arXiv)

Zusätzlich muss Overfitting aktiv bekämpft werden. Forschung zu Crypto-Trading-Agents weist explizit darauf hin, dass Backtests leicht falsche positive Ergebnisse liefern können und Overfitting geprüft werden muss. (arXiv)

8. Strategie-Architektur: Nicht eine Strategie, sondern drei Horizonte

Jarvis soll nicht nur Daytrading machen. Das ist richtig. Aber verschiedene Zeithorizonte dürfen nicht vermischt werden.

8.1 Intraday Trading Sleeve

Ziel: kleine aktive Gewinne, schnelle Kontrolle.

Strategie:

v76 strict Squeeze/Reclaim

1m/5m Entry

15m/1h Regimefilter

Holding: Minuten bis Stunden

Exchange-Level Stop

Trailing

Dead-Fish-Time-Exit

Kapital:

kleiner Teil des Guthabens

z. B. 20–40% des Crypto-Trading-Wallets

8.2 Swing Trading Sleeve

Ziel: bessere Bewegungen über Tage mit weniger hektischen Entries.

Strategie:

4h/1d Trend

Pullback zu EMA/VWAP

Breakout aus Daily Range

Funding nicht negativ gegen Position

BTC/ETH-Regime positiv

Holding:

1–14 Tage

Nur:

BTC, ETH, SOL, LINK

eventuell SUI/ENA/BCH nach Evidenz

kein hoher Leverage

Exit:

ATR Stop

Trailing auf 4h

Teilgewinn bei 1.5R/2R

Exit bei Regimewechsel

8.3 Portfolio / Holding Sleeve

Ziel: mittelfristige Krypto-Allokation.

Hier sollte Jarvis nicht hektisch per Perps handeln. Besser:

Spot, falls auf Hyperliquid verfügbar

oder sehr niedrige/notional begrenzte Perp-Exposures

hohe USDC-Reserve

keine Funding-Falle

Regeln:

nur große liquide Coins

monatliches oder wöchentliches Rebalancing

kein Kauf nach parabolischem Pump

Kaufzonen über 4h/1d Pullbacks

Stop oder Hedge-Plan

Für kleine 77 USDC ist das praktisch noch nicht wichtig. Bei 250–500+ USDC wird es relevant.

9. Rebalancing und Portfolio-Management

Der finale Bot sollte nicht fragen: “Welcher Trade jetzt?”Er sollte fragen: “Wie soll das Kapital verteilt sein?”

Beispiel für ein kleines Hyperliquid-Wallet:

USDC Reserve: 40–60%

Intraday Trading: 20–30%

Swing Trading: 10–30%

Copy/Research Live: 0%

Bei größerem Wallet:

USDC Reserve: 25–40%

Core Crypto Exposure: 25–40%

Intraday/Swing Trading: 20–30%

Copy/Vault Research Live: 0–10%, erst später

Wichtige Portfolio-Metriken:

max. Risiko pro Coin

max. Risiko pro Sektor

max. Gleichrichtung gegen BTC

max. kumulierter Altcoin-Anteil

max. Wochenverlust

max. Drawdown

USDC-Cashquote

10. Copytrading: Separater Research-Track

Copytrading soll nicht in den v76-Live-Bot gemischt werden.

Hyperliquid Vaults sind interessant, weil man an Gewinnen und Verlusten eines Vaults teilnehmen kann; Hyperliquid warnt aber selbst, dass vergangene Performance keine Garantie ist und bei Withdrawals Slippage/offene Positionen relevant sein können. User Vaults haben laut Docs 1 Tag Lock-up, HLP 4 Tage. (Hyperliquid Docs)

Vault-Leader erhalten 10% Profit Share und müssen mindestens 5% Skin in the Game halten; Vaults können validator-operated Perps handeln, aber nicht Spot oder HIP-3-Perps. (Hyperliquid Docs)

10.1 Copytrading nicht direkt live

Stufen:

Read-only Vault Collector

→ Leader Scorecard

→ Shadow Copy

→ Follower-PnL nach Kosten

→ Regime-Auswertung

→ kleine Live-Copy erst später

10.2 Was Jarvis messen muss

Leader Alter

Realized PnL

Unrealized PnL Anteil

Max Drawdown

Liquidationsnähe

Coin-Abhängigkeit

einzelner Trade PnL Anteil

Style Drift

Korrelation zu anderen Leadern

Performance ab Discovery-Zeitpunkt

Der Punkt “ab Discovery-Zeitpunkt” ist entscheidend, sonst hat man Survivorship Bias.

10.3 Keine Fill-by-Fill-Kopie

Für euren Zeithorizont sollte Jarvis nicht jeden Scalp kopieren. Er soll nur Positionen kopieren, wenn:

Position alt genug ist

Leader nicht schon zu weit im Gewinn ist

Distanz zum Leader Entry vertretbar ist

Spread/Depth gut sind

Funding nicht gefährlich ist

kein anderes Exposure schon gleich ausgerichtet ist

Und immer mit eigenem Stop.

11. Anlage-Assistent für Aktien, ETFs und Krypto

Für dein größeres Portfolio sollte Jarvis nicht blind Tradinglogik verwenden. Das ist ein anderes Produktmodul.

11.1 Was er sehen darf

Aus dem Finanzdashboard:

Bestände

Einstandskurse

aktueller Wert

Asset-Klasse

Region

Währung

Sektor

Gewinn/Verlust

Dividenden/Erträge

Krypto-Anteil

ETF-Anteil

Einzelaktien-Anteil

Cash

11.2 Was er berechnen soll

Gesamtallokation

Konzentrationsrisiko

Sektor-Klumpen

Währungsrisiko

Volatilität

Drawdown

Korrelation

Kostenquote bei ETFs

Performance vs Benchmark

Rebalancing-Abweichung

11.3 Empfehlungen

Für jede Position:

Kaufen

Halten

Reduzieren

Verkaufen

Aufstocken bei Rücksetzer

Nur beobachten

Jede Empfehlung muss enthalten:

Zeithorizont

Begründung

Risiko

Kurs-/Bewertungsniveau

Makro-/Marktumfeld

Alternativen

Trigger für Änderung

Wichtig: Jarvis soll hier Empfehlungen geben, nicht selbst außerhalb von Hyperliquid handeln.

12. Best Practices für Hermes/OpenClaw-Agenten

Ein autonomer Finanzagent braucht strengere Regeln als ein normaler Bot.

OpenClaw-/Agent-Sicherheitsanalysen zeigen, dass autonome Agents mit breitem lokalem Zugriff eine große Angriffsfläche haben; die Forschung beschreibt insbesondere Risiken durch manipulierte Fähigkeiten, Identität und gespeichertes Wissen des Agents. (arXiv) Berichte zu OpenClaw/Hermes-ähnlichen Workflows empfehlen, Zugriff wie bei einem neuen Mitarbeiter stufenweise zu geben: klein anfangen, Zugriff segmentieren, Verantwortung erst nach Bewährung erhöhen. (TechRadar)

Für Crypto_Agent heißt das:

12.1 Keine freie LLM-Execution für Orders

Der LLM-Agent darf nicht frei sagen: “Ich kaufe jetzt 5 SOL.”

Stattdessen:

LLM = Analyst / Planer

State Machine = Trader

Risk Engine = Entscheider

Executor = nur technische Ausführung

12.2 Tool-Verträge und strukturierte Inputs

Forschung zu Function Calling zeigt, dass Tool-Auswahl, Parameterfehler und unklare Dokumentation reale Probleme bei LLM-Tools sind. (arXiv) Deshalb braucht jedes Tool strikte JSON-Schemas:

trade_proposal_schema

order_intent_schema

risk_decision_schema

reconcile_schema

daily_report_schema

12.3 Modus-System

READ_ONLY

PAPER

TESTNET

SHADOW_LIVE

TINY_LIVE

NORMAL_LIVE

Jeder Modus hat eigene erlaubte Tools.

12.4 Unveränderliche Safety-Invarianten

Diese Regeln dürfen nie durch LLM-Interpretation übergangen werden:

keine Order ohne Stop

keine Order bei Reconcile-Unsicherheit

keine Order bei API degraded

kein Martingale

kein Averaging Down

kein Risiko-Hochdrehen ohne Freigabe

max. Tagesverlust hart

max. Wochenverlust hart

max. offene Positionen hart

12.5 Runtime-Sicherheit

Hyperliquid API-Wallets sollten pro Trading-Prozess getrennt sein, weil Nonces pro Signer verfolgt werden; Hyperliquid empfiehlt separate API-Wallets für unterschiedliche Prozesse/Subaccounts. (Hyperliquid Docs)

Betrieb:

systemd user service oder robuster Supervisor

Restart on failure

Start nur nach Reconcile

persistenter Runtime State

NonceManager persistent

Kill-switch Datei

Secrets nie in Logs

separate API-Wallet für Copytrading

separate API-Wallet für Hauptbot

13. Konkreter Zielbauplan

Phase 1: Repo und Runtime konsolidieren

Ziel: kein Drift mehr zwischen GitHub, lokaler Runtime und Jarvis-Reports.

Aufgaben:

lokalen v76-Stand sauber committen

GitHub aktualisieren oder bewusst als private/local-only markieren

alte AutoTrader.py live-unfähig halten

src/-Architektur als einzige Live-Basis

README: Modi und Startbefehle dokumentieren

Warum: Der öffentliche GitHub-Stand zeigt noch monolithische direkte Orderlogik. Das ist nicht der Zielzustand.

Phase 2: Market Snapshot Layer

Jarvis soll pro Coin regelmäßig ein normalisiertes Snapshot-Objekt erzeugen:

{

"coin": "SOL",

"timestamp": "...",

"price": {},

"ohlcv": {},

"trend": {},

"momentum": {},

"volatility": {},

"liquidity": {},

"derivatives": {},

"fundamentals": {},

"sentiment": {},

"regime": {},

"risk": {}

}

Pflichtquellen:

Hyperliquid

CoinGecko

optional CoinGlass

TradingView Webhooks

TradingView Ideas Track Record

Phase 3: Confluence Score Engine

Pro Coin:

trend_score

momentum_score

volatility_score

liquidity_score

derivatives_score

sentiment_score

portfolio_score

risk_score

final_trade_score

Beispiel:

final_trade_score =

25% trend

+ 20% momentum

+ 15% volatility/squeeze

+ 15% liquidity/execution

+ 10% derivatives/funding/OI

+ 10% market regime

+ 5% sentiment/context

Aber: Die Gewichtung darf nicht sofort live optimiert werden. Sie muss in Paper/Shadow getestet werden.

Phase 4: Entry-Verbesserung

Einführen:

anti_chase_filter

retest_required_after_pump

exhaustion_filter

VWAP distance filter

ATR extension filter

funding/OI crowding filter

upper wick rejection filter

Konkrete neue Regel:

Wenn Preis in kurzer Zeit > 2.5 ATR gestiegen ist:

kein Market Entry

nur Retest/Reclaim Entry

Phase 5: Echter Paper Lifecycle

Aktuelle Priorität 1.

Zu bauen:

entry order simulation

maker/taker classification

partial fills

stop order simulation

trailing stop simulation

take-profit simulation

funding accrual

slippage by depth

gap/slippage on stop

time-exit

post-trade reconciliation

Ohne das bleibt die starke v76-Paper-PnL verdächtig.

Phase 6: Drei Strategie-Sleeves

Intraday v76 strict

Swing trend/retest strategy

Portfolio holding/rebalancing strategy

Jede bekommt eigene Scorecard. Nicht vermischen.

Phase 7: Copytrading Research

ctb_copy read-only bauen

Vault snapshots speichern

Leader scorecard

Shadow-copy

Follower fill model

keine Live-Copy

Phase 8: Portfolio Advisor

Jarvis Finance Dashboard lesen

Aktien/ETF/Crypto Allokation auswerten

Kauf/Halten/Verkaufen-Empfehlungen

Rebalancing-Vorschläge

Risiko-/Konzentrationswarnungen

14. Live-Fähigkeit: Was final erfüllt sein muss

Technisch

Mainnet Reconcile grün

keine vergessenen Positionen

Exchange-Level Stops funktionieren

Order Updates / User Fills funktionieren

WebSocket reconnect robust

REST Rate-Limit eingehalten

NonceManager robust

API Wallet pro Prozess

systemd/Supervisor aktiv

Telegram/Critical Alerts aktiv

Kill-switch getestet

Daily/Weekly loss gates aktiv

Strategisch

v76 strict mit echtem Paper-Lifecycle positiv

pnl_ex_wld positiv

Top-Coin-Share kontrolliert

Profit Factor netto > 1.5

Drawdown kontrolliert

Choppy-Market-Test bestanden

mindestens 3 Coins profitabel/neutral

Live-Tiny-Abweichung zu Paper gemessen

Operativ

19:00 Uhr Tagesbericht

keine Dauer-Spam-Meldungen

Sofortmeldungen nur kritisch

wöchentlicher Strategie-Review

Parameteränderungen versioniert

Risk-Erhöhung nur nach Freigabe

15. Meine konkrete Produktempfehlung

Für sofort

Nicht mehr endlos neue Strategien bauen. Stattdessen:

1. v76 strict als Hauptstrategie behalten.

2. Paper-Lifecycle live-realistisch machen.

3. Anti-Chase/Retest-Filter ergänzen.

4. Market Snapshot Layer bauen.

5. Confluence Score Engine bauen.

6. Copytrading nur read-only/shadow.

7. Portfolio Advisor als separates Modul aufsetzen.

Für Tiny Live

Wenn bereits Tiny Live läuft, dann nur mit:

max 3 Positionen

10–15 USDC Notional pro Trade

1x–2x Leverage

max 2 USDC Tagesverlust

keine Risikoerhöhung

nach 2 Verlusten Pause

kein Trade ohne Stop

Tiny Live darf weiterlaufen, wenn Reconcile/Stops sauber sind. Aber Skalierung auf 250/500 USDC erst nach mindestens mehreren Tagen sauberem Livebetrieb und Vergleich Paper vs Live.

Für den finalen Bot

Der finale Bot sollte so aufgebaut sein:

Crypto_Agent

├── market_data

│   ├── hyperliquid

│   ├── coingecko

│   ├── coinglass_optional

│   ├── tradingview

│   └── sentiment_news

├── feature_store

├── regime_engine

├── signal_engine

│   ├── v76_intraday

│   ├── swing_retest

│   └── portfolio_holding

├── confluence_engine

├── risk_engine

├── execution_engine

├── reconcile_watchdog

├── copy_research

├── portfolio_advisor

└── reports

16. Direkter Auftrag an Jarvis

Diese Anweisung würde ich ihm geben:

Jarvis, Ziel ist jetzt die Finalisierung zum autonomen Hyperliquid-Trader und Portfolio-Advisor.

Bitte nicht weitere zufällige Strategien bauen. Fokus:

1. v76 strict bleibt Hauptstrategie.

2. Baue zuerst den echten Paper-/Live-Lifecycle:

Entry → Fill → Stop → TP/Trailing → Funding → Fees → Slippage → Reconcile → PnL.

3. Ergänze Anti-Chase:

kein Kauf nach überdehntem Pump; Retest/Reclaim bevorzugen.

4. Baue Market Snapshot Layer:

Hyperliquid + CoinGecko + optional CoinGlass + TradingView + Sentiment.

5. Baue Confluence Score:

Trend, Momentum, Volatilität, Liquidität, Funding/OI, Regime, Portfolio-Risiko.

6. Erweitere Strategie-Horizonte:

Intraday, Swing, längerfristige Holding/Rebalancing.

7. Copytrading nur read-only/shadow:

keine Live-Copy, keine Vault-Deposits.

8. Baue Portfolio Advisor:

Aktien/ETF/Krypto Dashboard auswerten, Empfehlungen geben, nicht handeln.

9. Halte Live-Risiko klein:

max. 3 Positionen, max. 10–15 USDC Notional pro Trade, max. 2 USDC Tagesverlust.

10. Tagesbericht 19:00 Uhr:

PnL, offene Positionen, Marktregime, beste/schlechteste Trades, Learnings, geplante Anpassungen.

Wichtig:

Keine Risikoerhöhung ohne Freigabe.

Keine neuen Live-Coins ohne Bericht/Freigabe.

Keine Strategieänderung direkt live.

Keine Mainnet-Order ohne Exchange-Level Stop.

Schlussbewertung

Der Bot ist nicht gescheitert; er war bisher zu sehr Strategie-Sampler und zu wenig Portfolio-Trader. Die v76-strict-Ergebnisse zeigen, dass ein brauchbarer Kern vorhanden sein kann. Der nächste Fortschritt kommt aber nicht durch noch mehr Signale, sondern durch:

bessere Entry-Qualität

realistischere Exit-Simulation

mehr Marktstruktur-Daten

mehr Zeithorizonte

strengere Portfolio-Steuerung

saubere Agent-Governance

Wenn Jarvis das umsetzt, wird aus dem Crypto_Agent ein funktionales Produkt: ein autonomer, risikobegrenzter Hyperliquid-Trader plus Anlage-Assistent für dein Gesamtportfolio. Garantie auf Gewinne gibt es nicht, aber die Architektur kann so weit professionalisiert werden, dass Entscheidungen messbar, kontrollierbar und lernfähig werden.