FAQ

KapitaalBot ist ein autonomes Krypto-Trading-System, das auf über 600 Spotmärkten läuft. Die Engine ist multi-regime (z. B. Range, Trend, High-Volatility, Low-Liquidity) und multi-strategy (z. B. Liquiditäts-, Momentum- und volumenorientierte Strategien). Diese Seite zeigt nur Observability-Daten zu dieser Runtime, keine Live-Orders oder Echtzeit-Signale.

Tier 1 dient als Observability-Schicht: Transparenz und Erklärung, ohne Echtzeit-Signalverhalten oder Reverse Engineering zu ermöglichen. Sie sehen Run-Status, Regime- und Strategie-Überblicke, Symbol-Zähler und aggregierte Metriken; kein Live-Order-Feed.

Tier 1 ist öffentlich: Statusstrip, Regimes, Strategien, Handelszähler, Markt-/Pair-Zusammenfassung und Demo-Trades aus public_*-Snapshots. Tier 2 ist auf Anfrage und fügt zusätzliche Observability-Module hinzu (Execution- und Latenz-Dashboards, erweiterte Trading-Statistiken, Shadow-Trades). Tier 3 ist intern (Admin-Observability) und umfasst vollständige Lifecycle- und Debug-Telemetrie.

Ja, die Live-Runtime handelt mit echtem Kapital innerhalb fester Exposure- und Risikolimits. Diese Website zeigt jedoch nur Read-Model-Snapshots und aggregierte Observability; keine Live-Positionen, exakten Balances oder Strategieparameter.

Nein. Die Observability-Seite erklärt Aufbau und Verhalten der Engine, veröffentlicht aber keine Entry-/Exit-Signale und gibt keine Anlageempfehlungen. Die Inhalte dienen technischer und operativer Transparenz.

Aktuell nicht. Die Live-Engine läuft auf einer begrenzten Anzahl intern verwalteter Accounts. Künftige Research-Kooperationen sind möglich, aber nur unter klaren Vereinbarungen zu Risiko, Observability und Datenzugang.

Snapshots werden periodisch aus der Live-Runtime exportiert. Die Frequenz variiert je nach Snapshot-Typ (Status, Regimes, Trading, Demo-Trades), aber Tier 1 zeigt immer verzögerte und aggregierte Daten, nicht den Roh-Realtime-Feed.

Die aktuelle Live-Variante läuft ausschließlich auf ausgewählten Spot-Märkten bei Kraken. Innerhalb dieses Universums wird nur ein Teil der möglichen Paare aktiv überwacht und ein noch kleinerer Teil tatsächlich gehandelt, abhängig von Regime, Liquidität und Risikofiltern.

Nein. KapitaalBot ist primär eine interne Research- und Trading-Engine mit Fokus auf Nachvollziehbarkeit und Auditierbarkeit. Diese Seite zeigt Technik, Risikostruktur und Observability, nicht ein Plug-and-Play-Retailprodukt.

Weil Architektur, Observability und Risikoansatz fairer bewertet werden können, wenn sie transparent sind. Gleichzeitig bleiben Strategieimplementierungen, exakte Schwellen und Venue-spezifische Details bewusst abstrakt.

Ein klassisches Performance-Dashboard zeigt vor allem P&L-Kurven, Sharpe-Werte und Backtests. Diese Seite fokussiert Runtime-Verhalten: Datenflüsse, Regimes, Safety-Guards und Validierungspfade. Performance-Ansichten können später separat ergänzt werden.

Viele Retail-Bots sind parametergetriebene Skripte rund um wenige Indikatoren. KapitaalBot ist eine state-first Runtime mit mehreren Datenfeeds, Regimes, Strategie-Familien, Safety-Layern sowie einer vollständigen Observability- und Validierungskette.

Ingest verbindet sich mit mehreren öffentlichen WebSockets (Ticker, Trades, L2, L3) und schreibt Rohdaten in eine Ingest-DB. Daraus wird pro Run eine State-Tabelle (run_symbol_state) aufgebaut. Route-Engine und Execution lesen nur aus diesem State (state-first); Observability-Snapshots lesen aggregierte Informationen aus derselben Datenbank.

Statt direkt aus Roh-Marktdaten zu entscheiden, wird zuerst ein kompakter State pro Symbol aufgebaut und aktualisiert. Bewertung, Regime-Erkennung, Strategie-Wahl und Execution nutzen ausschließlich diesen State. Das vermeidet mehrere Wahrheitsquellen und macht Safety/Freshness besser kontrollierbar.

Die Datenbank ist der Kern: Ingest schreibt Roh-Events, ein State-Builder pflegt kompakte Tabellen pro Run, die Route-Engine liest ausschließlich daraus und Observability nutzt aggregierte Views. Entscheidungen basieren nicht auf nicht-rekonstruierbaren In-Memory-Zwischenständen.

Die Implementierung nutzt wenige langlebige WebSocket-Verbindungen mit interner Multiplexing-Logik über Request-IDs. Backpressure wird über begrenzte Queues, Priorisierung von Feed-Typen und temporäres Drosseln nichtkritischer Kanäle behandelt.

Execution liest nur ein enges, kontrolliertes Read-Model (z. B. ausgewählte Routen mit expliziten Expiries und Risikogrenzen). Es gibt keine direkte Kopplung an Ingest oder rohe L2/L3-Feeds, sodass keine 'Ghost-State'-Abhängigkeiten entstehen.

Observability ist ein First-Class-Concern und kein Nachbau. Zentrale Schritte haben explizite Logmarker, Metriken und Snapshots. Viele Tabellen sind so gestaltet, dass sie sowohl für Live-Entscheidungen als auch für spätere Audits nutzbar sind.

Schema-Änderungen laufen über versionierte Migrationen und sind an konkrete Engine-Releases gebunden. Es gibt Wege für additive Online-Migrationen und für größere Änderungen in geplanten Wartungsfenstern.

Ja. Neben der Live-Runtime gibt es Observe- und Backfill-Runs. Sie nutzen denselben Kern, aber unterschiedliche Konfigurationsprofile und ggf. getrennte Schemata, sodass Experimente die Live-State nicht verschmutzen.

Ausfälle werden als reguläre Ereignisse behandelt: Ingest erkennt Timeouts und unvollständige Feeds, markiert Symbole oder Venues als degraded und macht das explizit für State und Route-Engine sichtbar. Bei Bedarf schaltet die Engine auf exit-only oder hard-blocked.

Snapshots sind kompakte, konsistente Views aus DB und Logs. Roh-Logs bleiben die tiefste Quelle für Analysen, aber für den täglichen Überblick und tiered access sind Snapshots deutlich effizienter.

Die Engine klassifiziert Märkte in wenige Hauptregimes wie RANGE, TREND, HIGH_VOLATILITY, LOW_LIQUIDITY und CHAOS. Jedes Regime beschreibt den Charakter des Marktes (z. B. mean-reverting vs. trendfolgend, ruhig vs. sehr volatil).

Pro Regime stehen verschiedene Strategie-Familien zur Verfügung (z. B. liquiditäts-, momentum- und volumenorientierte Ansätze). Für ein Symbol wählt die Engine eine passende Strategie anhand von Markt- und Regime-Merkmalen, ohne diese Wahl als feste Regelmenge preiszugeben.

Pro Symbol werden Merkmale gemessen (Liquidität, Spreads, Volatilität, Stabilität der Preisbewegungen, L3-Qualität usw.). Die Route-Engine erzeugt daraus eine oder wenige Kandidaten-Routen pro Symbol und ordnet sie nach erwartetem Nettonutzen vs. Risiko und Zeit. Pro Evaluationszyklus wird höchstens eine kleine Anzahl Symbole tatsächlich ausgewählt.

Das System ist modular: einige Komponenten sind regelbasiert, andere datengestützt (Scoring/Filter). Bevorzugt wird einfache, erklärbare Logik; komplexere Modelle kommen nur zum Einsatz, wenn sie klaren Mehrwert liefern und gut überwachbar sind.

Research-Runs verwenden Out-of-Sample-Perioden, Forward-Walks und Szenario-Tests. Komponenten wechseln erst in Live, wenn sie über mehrere Regimes stabil bleiben. Observability und Validierung helfen, Regressionen früh zu erkennen.

Ja. Regimes, Strategie-Familien und Routen-Typen haben Feature-Flags und Safety-Guards. Bei Unsicherheit kann ein Modul in Observation/Shadow laufen: Signale ja, Live-Orders nein.

Symbole mit dauerhaft niedriger Liquidität, breiten Spreads oder instabilem Orderbuch erhalten strengere Suitability-Filter. Viele werden vollständig ausgeschlossen oder nur in konservativen Regimes zugelassen.

Die Route-Engine verdichtet Signale zu wenigen Kandidaten-Routen pro Symbol und bewertet diese nach Nutzen, Risiko, Execution-Komplexität und Ressourcenbedarf. Pro Zyklus wird nur eine begrenzte Anzahl tatsächlich freigegeben.

Ja, in der Regel über explizite Lifecycle-Logik (Entry, Management, Exit). Manche Routen sind sehr kurzfristig, andere reagieren auf langsamere Regimewechsel.

Ein Regime ist eine kompakte Klassifikation aus mehreren Signalen gleichzeitig (z. B. Volatilität, Trendstärke, Liquidität, Mikrostruktur-Rauschen). Es ist kein Einzelindikator.

Die Live-Engine nutzt feste Limiten für z. B. maximale Einsätze pro Trade und insgesamt verfügbares Kapital. Zusätzlich gibt es Safety-Modi (normal, exit-only, hard-blocked), die Symbole vorübergehend oder dauerhaft ausschließen, wenn Daten oder Marktbedingungen nicht zuverlässig genug sind.

Vor jeder Bewertung wird der State aktualisiert. Zusätzlich gelten pro Routentyp maximale Datenalter; bei Überschreitung wird eine Route blockiert und die Engine protokolliert das explizit. Ein Generation-Gate stellt sicher, dass Execution nur auf State läuft, der auf der Decision-DB sichtbar und aktuell ist.

Neben Limits pro Trade/Symbol existieren globale Guardrails. Bei extremen Marktphasen kann die Engine in strengere Modi wechseln, Exposure reduzieren und neue Entries stoppen. Fokus ist kontrollierte Risikoreduktion.

Bei Verlust von Ingest- oder Execution-Verbindungen greifen Heartbeat- und Freshness-Checks. Neue Entries werden gestoppt; bestehende Risiken werden über Failsafe-Logik kontrolliert gemanagt, sobald wieder verlässliche Daten vorliegen.

Nein, die aktuelle Live-Variante arbeitet Spot-only ohne Leverage. Das reduziert Liquidationsrisiken und vereinfacht Risk-Management.

Es gibt Caps pro Symbol, Asset-Cluster und gesamt. Zusätzlich werden Korrelationen in Exposure-Profilen berücksichtigt, damit Risiken nicht unbemerkt auf ein Thema konzentriert werden.

Neben dieser Seite existieren interne Dashboards für Latenz, Fehlerraten, Safety-Events und Exposure. Alerts schlagen bei Schwellenüberschreitungen oder kritischen Ereigniskombinationen an.

Kritische Pfade sind defensiv mit Sanity-Checks, Limits und harten Invarianten abgesichert. Dazu kommen Test-/Observe-Läufe und Validierungsskripte, bevor Änderungen live gehen.

Ja. Auf System- und Account-Ebene können neue Orders gestoppt und bestehende Positionen kontrolliert reduziert oder geschlossen werden. Diese Pfade sind Bestandteil des Runbooks.

Der Betrieb läuft auf kontrollierter Serverumgebung mit Monitoring, Logging und Backups. Deploys und Konfigurationsänderungen folgen festen Git-basierten Prozessen, keine ad-hoc Live-Edits.

Tier 1 liest public_status_snapshot.json, public_regime_snapshot.json, public_strategy_snapshot.json, public_market_snapshot.json, public_trading_snapshot.json und public_demo_trades.json. In weiteren Iterationen kommen tier2_*-Snapshots und admin_observability_snapshot hinzu; sie enthalten mehr Detail, sind aber nicht öffentlich.

Tier 2 bietet zusätzliche Dashboards zu Execution, Latenz, Safety und Shadow-Trades. Statt nur aggregierter Zähler pro Run sehen Sie dort die Verteilung von Execution-Ergebnissen, Latenz-Profilen und Safety-Events pro Modul. Die genaue Strategielogik bleibt abstrakt.

Demo-Trades in Tier 1 basieren auf echten Fills, werden jedoch bewusst vereinfacht und aggregiert, sodass keine exakten Orders, Timestamps oder Venue-Details rekonstruierbar sind.

Einige Bereiche enthalten sensitivere Details (z. B. Latenzprofile, detaillierte Safety-Events, nahezu live Verteilungen), die für Technik/Compliance wichtig sind, aber nicht voll öffentlich geeignet.

Statusstrip und Kernkarten zeigen, ob Ingest, Evaluation und Execution konsistent und aktuell laufen. Auffällige Safety-Modi, große Snapshot-Lücken oder abrupte Zählerwechsel sind Warnsignale.

Ja. DB und Exporte halten relevante Zustände pro Run/Tag vor. Die öffentliche Seite zeigt primär den aktuellen Überblick; Historie wird vor allem intern für Analysen und Audits genutzt.

Der Chatbot nutzt Retrieval über aktuelle Dokumente und generiert darauf aufbauend Antworten. Wenn Dokumentation aktualisiert wird, aktualisiert sich auch die Wissensbasis des Chats.

Für öffentliche Nutzung werden Diagramme bewusst abstrahiert: Fokus auf Hauptkomponenten und Datenflüsse statt interner Feinheiten. Tiefere Details stehen in technischen Dokumenten und internen Views.

Ja. Observability-Daten zeigen robuste/schwache Regimes, Bottlenecks und häufige Safety-Events. Das beeinflusst die Prioritäten kommender Releases.

Die Seite ist ein Fenster auf die Runtime. Ergänzend existieren interne Reports, Run-Logs und Validierungsskripte. Zusammen entsteht ein nachvollziehbarer Audit-Trail.

Das Validierungsmodell umfasst Bootstrap-, Attach-, Evaluation- und Lifecycle-Proofs. Diese kombinieren Log-Marker (z. B. EXECUTION_ENGINE_START, LIVE_EVALUATION_*, DATA_INTEGRITY_*, ROUTE_FRESHNESS_*) mit DB-Tabellen (Orders, Fills, State), um zu zeigen, dass ein Run von Start bis Fill konsistent ist.

DOC_INDEX.md und die nummerierten Layer-Guides 01_ARCHITECTURE bis 08_OPERATIONS bilden das technische Gerüst. Ergänzungen: 00_MODULE_INVENTORY, spezialisierte Policy-Dokumente und der Observability-Snapshot-Vertrag mit dieser Site.

Bootstrap-Proofs zeigen den korrekten Start aus bekannter Code-/DB-State. Attach-Proofs zeigen, dass Reporting/Observability an dieselbe State andocken. Lifecycle-Proofs belegen die konsistente Kette von Ingest bis Fill.

Es gibt Prüfungen auf fehlende/duplizierte Events, Schema-Kompatibilität, Typabweichungen und Outlier. Bei Problemen werden Routen/Symbole blockiert, bis die Ursache geklärt ist.

Ja. Neben Live-Runs existieren Observe-/Simulation-Runs mit derselben Kernlogik, aber ohne echte Orders. Damit werden Änderungen vor Live-Einsatz abgesichert.

Validierungscode wird wie Produktionscode behandelt: versioniert, dokumentiert und überprüft. Zusätzlich laufen regelmäßige Replays auf historischen Daten zur Stabilitätskontrolle.

Runbooks beschreiben operative Schritte (starten, stoppen, upgraden, eingreifen). Das Validierungsmodell beschreibt die Spuren in DB/Logs. Zusammen sichern sie Reproduzierbarkeit und Nachprüfbarkeit.

Grundsätzlich ja, über kontrollierten Zugriff auf Dokumentation, Snapshots und ausgewählte Log-/DB-Views. Genau dafür ist die Observability-Layer gestaltet.

Neue Releases werden gegen bekannte Datensätze und Szenarien mit erwarteten Ergebnissen geprüft. Abweichungen werden vor Live-Rollout untersucht.

Die Website-Dokumente werden mit dem Haupt-Repository synchronisiert; wichtige Änderungen landen im Changelog. Dadurch bleibt die Kopplung zwischen Code, Docs und Darstellung erhalten.

Nein. Texte, Dashboards und FAQ beschreiben Architektur, Observability und Risikoprinzipien. Keine Empfehlung zum Kauf/Verkauf, keine persönliche Anlageberatung und keine Einladung zur Teilnahme.

Keine. Öffentliche und Tier-2-Snapshots sind aggregiert und enthalten keine identifizierbaren Kontodaten, keine vollen Order-IDs und keine reproduzierbaren Strategieparameter.

Die Website dient dem Systemverständnis. Weiterverwendung mit Quellenangabe und ohne Implikation von Partnerschaft oder Endorsement, sofern nicht schriftlich vereinbart.

Krypto ist stark volatil; die Website enthält Risikohinweise gemäß Projektrichtlinie. Kein Ersatz für Rechtsberatung; Nutzer und Betreiber bleiben für Compliance verantwortlich.

Um Signal-Leaks zu begrenzen, Betriebssicherheit zu schützen und Missbrauch aggregierter Daten zu vermeiden. Observability ist bewusst verzögert und zusammengefasst.

Inhalte folgen synchronisierten Engine-Docs und Snapshots; Repository und Runtime-Export sind maßgeblich. Die Website wird zur Transparenz „wie besehen“ bereitgestellt, ohne Gewähr für Gewinn oder fehlerfreien Betrieb.

Ja. Spenden helfen, weiterzuentwickeln und zu testen: Engineering-Zeit, Infrastruktur, Tooling und Testläufe. Es ist kein Kauf von Rendite oder Signalen — es unterstützt Forschung und Engineering.

Das ist möglich, aber nicht automatisch. Unterstützer können für erweiterten Zugang (z. B. Tier 2-Dashboards) in Frage kommen — abhängig von Kapazität und Passung. Klärung über Kontakt oder Tier-2-Anfrage; kurz erwähnen, dass Sie unterstützen möchten.

Unter anderem Server- und Laufzeitkosten, Testumgebungen, Observability-Export und fokussierte Zeit für Features, Regressionstests und Betriebssicherheit — nicht für Massenmarketing.

Nein. Keine Equity, kein Gewinn- oder Rückzahlungsversprechen. Eine Spende ist freiwillige Unterstützung von Technik und Transparenz; Tier-2-Zugang kann im Einzelfall folgen, nicht als gekauftes Produkt.

Nutzen Sie das Kontaktformular oder die Tier-2-Anfrage. Geben Sie an, dass Sie über Spende oder laufende Unterstützung sprechen möchten — ohne Erwartungen an Trading-Ergebnisse.