FAQ

KapitaalBot est un système de trading crypto autonome qui tourne sur plus de 600 marchés au comptant. Le moteur est multi-régime (ex. range, tendance, haute volatilité, faible liquidité) et multi-stratégie (ex. liquidité, momentum, volume). Ce site n'affiche que des données d'observability sur cette runtime, pas d'ordres en direct ni de signaux en temps réel.

Le Tier 1 sert de couche d'observability : transparence et explication sans faciliter le comportement des signaux en temps réel ou l'ingénierie inverse. Vous voyez le statut de run, les régimes et stratégies, les compteurs de symboles et des métriques agrégées ; pas de flux d'ordres en direct.

Le Tier 1 est public : bandeau de statut, régimes, stratégies, compteurs de trades, résumé marché/paires et démo trades à partir des snapshots public_*. Le Tier 2 est sur demande et ajoute des modules d'observability (dashboards exécution et latence, statistiques de trading étendues, shadow trades). Le Tier 3 est interne (observability admin) et inclut la télémétrie lifecycle et debug complète.

Oui, la runtime live opère avec du capital réel dans des limites fixes d'exposition et de risque. Ce site affiche uniquement des snapshots read-model et de l'observability agrégée ; pas de positions live, de soldes exacts ni de paramètres de stratégie.

Non. Le site explique l'architecture et le comportement du moteur, mais ne publie pas de signaux d'entrée/sortie et ne donne pas de recommandations d'investissement. L'objectif est la transparence technique et opérationnelle.

Pas actuellement. Le moteur live tourne sur un nombre limité de comptes gérés en interne. Des collaborations de recherche peuvent être envisagées, avec des règles strictes sur le risque, l'observability et l'accès aux données.

Les snapshots sont exportés périodiquement depuis la runtime live. La fréquence dépend du type de snapshot (statut, régimes, trading, démo trades), mais le Tier 1 reste toujours différé et agrégé.

La version live actuelle opère uniquement sur des marchés spot sélectionnés chez Kraken. Dans cet univers, seule une partie des paires est activement surveillée, et une sous-partie encore plus petite est effectivement tradée.

Non. KapitaalBot est avant tout un moteur interne de recherche et de trading, centré sur l'explicabilité et l'auditabilité. Le site vise à montrer la technique, la structure de risque et l'observability.

Parce que l'architecture, l'observability et l'approche risque sont mieux évaluées lorsqu'elles sont transparentes. Les détails sensibles (implémentations, seuils exacts, spécificités venue) restent volontairement abstraits.

Un dashboard classique met surtout l'accent sur P&L, Sharpe et backtests. Ici, le focus est le comportement runtime : flux de données, régimes, safety-guards et validation. La performance peut être ajoutée séparément.

Beaucoup de bots retail sont des scripts paramétriques autour de quelques indicateurs. KapitaalBot est une runtime state-first avec multiples feeds, régimes, familles de stratégies, couches de sécurité et chaîne complète d'observability/validation.

Ingest se connecte à plusieurs WebSockets publics (ticker, trades, L2, L3) et écrit les données brutes dans une DB ingest. Une table d'état (run_symbol_state) est construite par run. Le moteur de routage et l'exécution ne lisent que cet état (state-first) ; les snapshots d'observability lisent des informations agrégées depuis la même base.

Au lieu de décider directement à partir des données de marché brutes, un état compact par symbole est d'abord construit et mis à jour. L'évaluation, la détection de régime, le choix de stratégie et l'exécution n'utilisent que cet état. Cela évite les sources de vérité multiples et simplifie le contrôle de la sécurité et de la fraîcheur.

La base est au cœur du système : ingest écrit les événements bruts, un builder maintient des tables d'état compactes, le route-engine lit uniquement ces tables, et l'observability consomme des vues agrégées.

L'implémentation utilise un petit nombre de connexions WebSocket durables avec multiplexage interne des requêtes. Le backpressure est géré via files bornées, priorisation des feeds et throttling temporaire des canaux non critiques.

L'exécution lit un read-model restreint et contrôlé (routes sélectionnées avec expirations/limites explicites). Elle n'est pas directement couplée aux flux bruts L2/L3, ce qui évite une dépendance à un état non traçable.

C'est un élément de conception de premier plan. Les étapes clés possèdent des log markers, métriques et snapshots explicites, exploitables autant pour l'opérationnel live que pour l'audit.

Les migrations sont versionnées et liées à des releases précises du moteur. Les changements additifs peuvent être faits en ligne ; les changements lourds passent par des fenêtres de maintenance planifiées.

Oui : live, observe et backfill. Le socle est commun, avec des profils de configuration/schémas distincts pour éviter toute contamination de l'état live.

Les pannes sont traitées comme événements normaux : détection de timeouts/feeds incomplets, marquage degraded des symboles/venues, et adaptation explicite côté state/route-engine.

Les snapshots sont des vues compactes et cohérentes construites à partir de la DB et des logs. Les logs restent la source la plus fine pour les investigations profondes.

Le moteur classe les marchés en quelques régimes principaux (RANGE, TREND, HIGH_VOLATILITY, LOW_LIQUIDITY, CHAOS). Chaque régime décrit le caractère du marché (ex. mean-reverting vs tendanciel, calme vs très volatil).

Par régime, différentes familles de stratégies sont disponibles (ex. liquidité, momentum, volume). Pour un symbole, le moteur choisit une stratégie adaptée selon les caractéristiques du marché et du régime, sans exposer cette décision comme règle fixe.

Pour chaque symbole, des caractéristiques sont mesurées (liquidité, spreads, volatilité, stabilité des mouvements de prix, qualité L3, etc.). Le moteur de routage produit une ou quelques routes candidates par symbole et les classe selon le bénéfice net attendu vs risque et temps. Par cycle d'évaluation, seul un petit nombre de symboles est réellement sélectionné.

Le système est modulaire : certaines briques sont rule-based, d'autres data-driven (scoring/filtrage). La priorité reste une logique explicable ; les modèles plus complexes ne sont utilisés que si leur valeur ajoutée est claire et monitorable.

Les tests de recherche couvrent des périodes out-of-sample, des forward-walks et des scénarios variés. Une composante n'entre en live que si son comportement reste stable sur plusieurs régimes.

Oui. Regimes, familles de stratégies et types de routes disposent de feature flags et safety guards. En cas de doute, un module peut passer en mode observation/shadow.

Les symboles avec faible liquidité structurelle, spreads extrêmes ou carnets instables subissent des filtres de suitability plus stricts, voire une exclusion totale.

Le route-engine fusionne les signaux en quelques routes candidates puis les score selon gain attendu, risque, complexité d'exécution et coût ressources. Seule une fraction est validée par cycle.

Oui, avec une logique de cycle de vie explicite (entrée, gestion, sortie). Certaines routes sont très courtes, d'autres s'appuient sur des changements de régime plus lents.

Un régime est une classification synthétique basée sur plusieurs signaux (volatilité, trend strength, liquidité, bruit microstructure). Ce n'est pas un seul indicateur isolé.

Le moteur live utilise des limites fixes (mise max par trade, capital total disponible). Il existe des modes de sécurité (normal, exit-only, hard-blocked) qui excluent temporairement ou définitivement des symboles lorsque les données ou conditions de marché ne sont pas assez fiables.

L'état est rafraîchi avant chaque évaluation. De plus, par type de route des âges max de données s'appliquent ; en cas de dépassement, une route est bloquée et le moteur le logue. Une gate de génération garantit que l'exécution ne s'appuie que sur un état visible et récent sur la DB de décision.

En plus des limites par trade/symbole, des guardrails globaux existent. En phase extrême, le moteur peut réduire l'exposition, passer en mode plus strict et stopper de nouvelles entrées.

Des contrôles heartbeat/freshness détectent la dégradation. Les nouvelles entrées sont stoppées et les risques existants sont gérés via logique failsafe dès qu'une fenêtre fiable revient.

Non. La variante live actuelle est spot-only sans levier, afin de réduire les risques de liquidation et simplifier le contrôle du risque.

Des caps existent par symbole, cluster d'actifs et globalement. Les corrélations entre actifs sont prises en compte pour limiter les concentrations implicites.

En plus de ce site, des dashboards internes suivent latence, taux d'erreur, événements safety et exposition. Des alertes déclenchent en cas de seuils ou combinaisons critiques.

Les chemins critiques sont défensifs (sanity checks, limites, invariants bloquants). Les nouveautés passent d'abord par tests, modes observe et scripts de validation.

Oui. Au niveau système et compte, les nouvelles orders peuvent être bloquées et les positions existantes réduites/fermées de façon contrôlée.

L'exploitation s'appuie sur un environnement serveur contrôlé, monitoring, logs et sauvegardes. Les changements passent par des workflows Git traçables, sans patchs manuels hors process.

Le Tier 1 lit public_status_snapshot.json, public_regime_snapshot.json, public_strategy_snapshot.json, public_market_snapshot.json, public_trading_snapshot.json et public_demo_trades.json. Les snapshots tier2_* et admin_observability_snapshot viendront ensuite ; plus de détail, non publics.

Le Tier 2 offre des dashboards supplémentaires (exécution, latence, sécurité, shadow trades). Au lieu de compteurs agrégés par run, vous voyez la répartition des résultats d'exécution, profils de latence et événements de sécurité par module. La logique de stratégie précise reste abstraite.

Les démo trades Tier 1 dérivent de fills réels mais sont simplifiés/agrégés pour empêcher la reconstruction d'orders exactes, timestamps précis ou détails venue.

Ils contiennent des informations plus sensibles (latence détaillée, événements safety fins, distributions quasi live) utiles en technique/compliance mais inadaptées au public.

Le bandeau de statut et les cartes principales indiquent la fraîcheur/cohérence d'ingest, évaluation et exécution. Des écarts marqués signalent la nécessité d'une analyse plus profonde.

Oui. Les DB et exports conservent des états pertinents par run/jour. Le site public présente surtout la vue la plus récente ; l'historique sert surtout aux analyses et audits.

Le chatbot s'appuie sur une couche de retrieval des documents actuels puis génère une réponse. Les mises à jour documentaires se répercutent donc sur la base de connaissance.

Pour le public, les diagrammes sont volontairement abstraits afin de privilégier les composants et flux majeurs. Les détails plus fins restent dans les docs techniques et vues internes.

Oui. Elles alimentent les priorités de recherche et d'évolution (robustesse des régimes, points de friction, événements safety récurrents).

Le site est une vue de synthèse. Avec les logs de run, scripts de validation et rapports internes, il forme une piste d'audit cohérente et reconstituable.

Le modèle de validation comprend les preuves bootstrap, attach, evaluation et lifecycle. Elles combinent des marqueurs de log (ex. EXECUTION_ENGINE_START, LIVE_EVALUATION_*, DATA_INTEGRITY_*, ROUTE_FRESHNESS_*) et les tables (orders, fills, state) pour montrer qu'un run est cohérent du début au fill.

DOC_INDEX.md et les guides de couches numérotés 01_ARCHITECTURE à 08_OPERATIONS forment l'épine technique. Ajouts : 00_MODULE_INVENTORY, documents de politique spécialisés et le contrat de snapshot d'observabilité avec ce site.

Les bootstrap proofs confirment un démarrage correct depuis un état code/DB connu. Les attach proofs confirment que reporting/observability se branchent sur ce même état. Les lifecycle proofs démontrent la cohérence de la chaîne ingest → fills.

Le système vérifie événements manquants/dupliqués, compatibilité de schéma, anomalies de types et outliers. En cas de problème, des routes/symboles sont bloqués jusqu'à résolution.

Oui. Des runs observe/simulation utilisent la même logique centrale sans passer d'ordres réels, pour sécuriser les changements avant live.

Le code de validation suit les mêmes standards que le code moteur (versioning, documentation, revue). Des replays réguliers sur données historiques vérifient sa stabilité.

Le runbook décrit les opérations (start/stop/upgrade/incident). Le modèle de validation décrit les traces attendues dans DB/logs. Ensemble, ils garantissent reproductibilité et auditabilité.

Oui, sous accès contrôlé à la documentation, snapshots et vues log/DB sélectionnées. C'est précisément l'objectif d'une observability structurée.

Chaque release est testée sur des jeux/scénarios de référence avec résultats attendus. Les écarts sont analysés avant mise en production.

Les docs du site sont synchronisées avec le dépôt principal du bot ; les changements importants sont consignés dans le changelog, assurant un lien direct code/docs/site.

Non. Textes, tableaux de bord et FAQ décrivent l’architecture technique, l’observability et les principes de risque. Ce n’est pas une recommandation d’acheter ou vendre, ni un conseil financier personnalisé, ni une invitation à participer.

Aucune. Les instantanés publics et Tier 2 sont agrégés : pas de données de compte identifiables, pas d’identifiants d’ordre complets, pas de paramètres de stratégie reproductibles.

Le site vise la compréhension du système. Réutilisation avec attribution et sans suggérer partenariat ou approbation, sauf accord écrit.

Les crypto-actifs sont très volatils ; le site comporte des avertissements selon la politique du projet. Ce n’est pas un avis juridique ; visiteurs et opérateurs restent responsables de la conformité.

Pour limiter la fuite de signaux, protéger l’exploitation et réduire l’abus d’informations agrégées mais sensibles. L’observability est volontairement retardée et synthétisée.

Le contenu suit la doc moteur et les snapshots synchronisés ; le dépôt et l’export runtime font foi. Le site est fourni « tel quel » pour la transparence, sans garantie de gain ni d’absence d’erreurs.

Oui. Les dons aident à poursuivre le développement et les tests : temps d’ingénierie, infrastructure, outillage et campagnes de test. Ce n’est pas l’achat de performance ou de signaux — c’est un soutien à la R&D et à l’ingénierie.

C’est possible, mais ce n’est pas automatique. Les contributeurs peuvent être éligibles à un accès élargi (ex. tableaux Tier 2), selon capacité et adéquation. À clarifier via contact ou demande Tier 2 ; indiquez que vous souhaitez contribuer.

Coûts serveur et runtime, environnements de test, export d’observabilité et temps pour livrer des fonctionnalités, lancer des régressions et garder le moteur fiable — pas pour du marketing de masse.

Non. Pas d’equity, pas de promesse de gain ou de remboursement. Un don est un soutien volontaire à la technique et à la transparence ; l’accès Tier 2 peut suivre au cas par cas, pas comme produit acheté.

Utilisez le formulaire de contact ou la demande d’accès Tier 2. Précisez que vous voulez parler d’un don ou d’un soutien régulier — sans attentes sur les résultats de trading.