FAQ

KapitaalBot is een autonoom crypto trading systeem dat op ruim 600 spotmarkten draait. De engine is multi-regime (bijv. range, trend, high-volatility, low-liquidity) en multi-strategy (bijv. liquidity-, momentum- en volumegerichte strategieën). Deze site toont alleen observability-data over die runtime, geen live orders of realtime signalen.

Tier 1 is bedoeld als observability-laag: transparantie en uitleg zonder realtime signal-gedrag of reverse-engineering te faciliteren. Je ziet run-status, regime- en strategy-overviews, symbol-tellers en geaggregeerde metrics; geen live orderfeed.

Tier 1 is publiek: statusstrip, regimes, strategieën, handelstellers, market/pair summary en demo trades op basis van public_* snapshots. Tier 2 is op aanvraag en voegt extra observability-modules toe, zoals execution- en latencydashboards, uitgebreidere trading-statistieken en shadow-trades. Tier 3 is intern (admin-observability) en bevat volledige lifecycle- en debug-telemetrie.

Ja, de live-runtime draait met echt kapitaal binnen vaste exposure- en risicolimieten. Wat je hier ziet zijn echter alleen read-model snapshots en geaggregeerde observability; er worden geen live posities, exacte balances of strategie-parameters getoond.

Nee. De observability-site beschrijft hoe de engine is opgebouwd en hoe hij zich gedraagt, maar doet geen aanbevelingen en publiceert geen entry- of exit-signalen. De informatie is bedoeld voor technische en operationele transparantie.

Op dit moment niet. De live-engine draait op een beperkt aantal intern beheerde accounts. In de toekomst is een research-samenwerking mogelijk, maar alleen onder strikte afspraken over risk, observability en toegang tot data.

Snapshots worden periodiek vanuit de live-runtime geëxporteerd. De exacte frequentie verschilt per type snapshot (status, regimes, trading, demo trades), maar Tier 1 toont altijd vertraagde en geaggregeerde data, niet de ruwe realtime feed.

De huidige live-variant draait uitsluitend op geselecteerde spot-markten bij Kraken. Binnen die set wordt slechts een deel van alle mogelijke pairs actief gevolgd en nog weer een kleiner deel gebruikt voor daadwerkelijke trading, afhankelijk van regime, liquiditeit en riskfilters.

Nee. KapitaalBot is primair een eigen research- en tradingengine met nadruk op explainability en interne auditbaarheid. Deze site is bedoeld om de techniek, risk-structuur en observability te laten zien, niet als marketing voor een kant-en-klaar retailproduct.

Omdat de architectuur, observability en risk-aanpak beter beoordeeld kunnen worden als ze transparant zijn. Tegelijkertijd blijven strategie-implementaties, exacte drempels en venue-specifieke details bewust abstract gehouden.

Een klassiek performance-dashboard toont vooral P&L-curves, Sharpe-ratio's en backtests. Deze site focust op runtime-gedrag: dataflows, regimes, safety-guards en validatiepaden. Performance-overzichten kunnen later als aparte laag worden toegevoegd, maar zijn geen kern-doel van dit project.

Veel retail-bots zijn parameter-gedreven scripts rond één of enkele indicatoren. KapitaalBot is een state-first runtime met meerdere datafeeds, regimes, strategie-families, safety-lagen en een volledige observability- en validatieketen. De nadruk ligt op controle en uitlegbaarheid, niet op het maximaliseren van trade-frequentie.

Ingest verbindt op meerdere public WebSockets (ticker, trades, L2, L3) en schrijft raw-data in een ingest-DB. Daaruit wordt per run een state-tabel opgebouwd (run_symbol_state). De route-engine en execution lezen alleen uit die state (state-first); observability-snapshots lezen geaggregeerde informatie uit dezelfde database.

In plaats van direct uit raw marketdata te beslissen, wordt eerst een compacte state per symbol opgebouwd en geüpdatet. Evaluatie, regime-detectie, strategie-keuze en execution gebruiken uitsluitend die state. Dat voorkomt meerdere waarheden, maakt safety/freshness beter controleerbaar en maakt auditing eenvoudiger.

De database is het hart van de engine: ingest schrijft ruwe events, een state-bouwer onderhoudt compacte tabellen per run, de route-engine leest alleen uit die state-tabellen en observability leest geaggregeerde views. Er worden geen beslissingen genomen op basis van losse in-memory caches die niet terug te vinden zijn in de DB.

De implementatie gebruikt een beperkt aantal langdurige WS-verbindingen die intern multiplexen op request-IDs. Backpressure wordt afgevangen via bounded queues, prioritering van feedtypes en het tijdelijk afknijpen van niet-kritieke kanalen wanneer de latency of load toeneemt.

Execution leest alleen een beperkt, gecontroleerd read-model (bijv. geselecteerde routes met expliciete expiries en risk-grenzen). Het component kent geen directe koppelingen met ingest of ruwe L2/L3-feeds. Hierdoor kan de rest van het systeem herstarten of worden geüpdatet zonder dat execution op 'spookstate' draait.

Observability is geen add-on maar een eerste klas concern. Voor belangrijke stappen bestaan expliciete logmarkers, metrics en snapshots. Veel tabellen zijn zo ontworpen dat ze zowel voor live-besluiten als voor latere validatie en audit gebruikt kunnen worden.

Schema-wijzigingen lopen via versiebeheerde migraties en worden altijd gekoppeld aan een specifieke release van de engine. Er zijn paden voor zowel online migratie (bijv. additive kolommen) als zwaardere migraties tijdens geplande maintenance-vensters.

De architectuur ondersteunt naast de live-runtime ook observe- en backfill-runs. Die gebruiken dezelfde kerncomponenten maar andere configuratieprofielen en schema-namen, zodat experimenten en analyses de live-state niet vervuilen.

Outages worden gezien als normale events: ingest detecteert timeouts en incomplete feeds, markeert symbolen of venues als degraded en zorgt dat state en route-engine dat expliciet zien. In extreme gevallen schakelt de engine naar exit-only of hard-blocked modes.

Snapshots zijn compacte, samenhangende views die uit DB en logs worden opgebouwd. De ruwe logs blijven leidend voor deep-dives, maar voor dagelijks overzicht en tiered access zijn de snapshots efficiënter en beter te presenteren.

De engine classificeert markten in een paar hoofdregimes, zoals RANGE, TREND, HIGH_VOLATILITY, LOW_LIQUIDITY en CHAOS. Elk regime beschrijft het karakter van de markt (bijv. mean-reverting versus trendend, rustig versus zeer volatiel).

Per regime zijn verschillende strategie-families beschikbaar (bijvoorbeeld liquidity-, momentum- en volumegerichte benaderingen). Voor een symbol kiest de engine een passende strategie op basis van kenmerken van de markt en het regime, zonder dat die keuze als vaste rule-set wordt blootgelegd.

Voor elk symbol worden kenmerken gemeten (liquiditeit, spreads, volatiliteit, stabiliteit van prijsbewegingen, L3-kwaliteit, enz.). De route-engine maakt op basis daarvan één of enkele kansrijke kandidaat-routes per symbol en rangschikt die op verwachte netto-voordeel versus risico en tijd. Per evaluatie-cyclus wordt hoogstens een klein aantal symbols daadwerkelijk geselecteerd.

Het systeem is modulair: sommige onderdelen zijn rule-based met expliciete drempels, andere gebruiken datagedreven scoring of filters. Waar mogelijk wordt gekozen voor eenvoudige, uitlegbare beslislogica; complexe modellen worden alleen ingezet als ze duidelijk voordeel bieden en goed te monitoren zijn.

Research-sessies gebruiken out-of-sample periodes, forward-walks en scenario-tests. Daarnaast worden strategiecomponenten pas in de live-engine gebruikt als ze in meerdere regimes en condities stabiel gedrag laten zien. Observability en validatie helpen om regressies snel te detecteren.

Ja. Regimes, strategie-families en zelfs complete route-typen hebben feature-flags en safety-guards. Bij twijfel kan een component tijdelijk in observatie- of shadow-modus worden gezet, waarbij hij wel signalen produceert maar geen live orders meer triggert.

Symbolen met structureel lage liquiditeit, extreem brede spreads of sterk instabiele orderboeken worden in een strengere suitability-filter gezet. In veel gevallen worden ze volledig uitgesloten of alleen in niet-agressieve regimes toegestaan.

De route-engine aggregeert signalen tot een kleine set kandidaat-routes per symbol. Die worden gescoord op onder meer verwacht voordeel, risico, execution-complexiteit en resourcegebruik. Uiteindelijk wordt er per evaluatie-cyclus hoogstens een beperkt aantal routes geaccepteerd.

De meeste strategieën werken met expliciete lifecycle-logica: entry, management en exit worden als samenhangend proces gezien. Sommige routes zijn kortdurende microstructure-trades, andere zijn trager en kijken meer naar regime-wissels.

Een regime is een samenvattende classificatie van meerdere signalen tegelijk (bijv. volatiliteit, trendsterkte, liquiditeit, microstructure-noise). Het is geen enkelvoudige indicator maar een compacte beschrijving van het speelveld waarbinnen strategieën keuzes maken.

De live engine gebruikt vaste limieten voor o.a. maximale inzet per trade en totaal beschikbaar kapitaal. Daarnaast zijn er safety-modi (normal, exit-only, hard-blocked) die symbolen tijdelijk of permanent uitsluiten wanneer de data of marktcondities niet betrouwbaar genoeg zijn.

Voor elke evaluatie wordt state ververst. Bovendien gelden per route-type maximale leeftijden voor data; als die overschreden worden, wordt een route geblokkeerd en logt de engine dit expliciet. Daarnaast bewaakt een generatie-gate dat execution alleen gebeurt op state die zichtbaar en recent is op de decision-DB.

Naast per-trade en per-symbol limieten bestaan er globale guardrails. Bij extreme events kan de engine overschakelen naar een strengere modus, exposure terugbrengen of nieuwe entries stoppen. De focus ligt dan op het gecontroleerd afbouwen van risico in plaats van nieuwe kansen najagen.

Wanneer ingest of execution verbinding verliezen, detecteert de engine dit via heartbeats en freshness-metrics. Nieuwe entries worden dan gestopt en waar nodig worden bestaande posities via failsafe-logica gecontroleerd afgebouwd zodra er weer een betrouwbaar venster is.

Nee, de huidige live-variant draait alleen op spot zonder leverage. Dat reduceert het risico op liquidatie-events en maakt risk- en margin-management eenvoudiger en transparanter.

Er zijn caps per symbol, per assetcluster en in totaal. Daarnaast worden correlaties tussen assets meegenomen in exposure-profielen, zodat niet alle risico impliciet in één thema stapelt.

Naast deze observability-site zijn er interne dashboards voor latency, error-rates, safety-events en exposure. Alerts slaan aan als bepaalde drempels of combinaties van events worden overschreden, zodat er snel handmatig kan worden ingegrepen.

Belangrijke paden zijn defensief geprogrammeerd met sanity-checks, limieten en invariants die bij overtreding hard blokkeren. Daarnaast zijn er test-runs, observe-modi en validatie-scripts die nieuwe wijzigingen eerst in een gecontroleerde omgeving doorlopen.

Ja. Zowel op systeemniveau als op exchange-accountniveau kunnen alle nieuwe orders worden geblokkeerd en bestaande posities gecontroleerd worden afgebouwd of dichtgezet. Deze paden worden regelmatig getest als onderdeel van het runbook.

Het systeem draait op een gecontroleerde serveromgeving met monitoring, logging en back-ups. Procedures voor deploys, configuratiewijzigingen en incident-response zijn vastgelegd in het runbook; wijzigingen lopen via versiebeheer en worden niet ad hoc op de live-omgeving gedaan.

Tier 1 leest public_status_snapshot.json, public_regime_snapshot.json, public_strategy_snapshot.json, public_market_snapshot.json, public_trading_snapshot.json en public_demo_trades.json. In volgende iteraties komen daar tier2_* snapshots en admin_observability_snapshot bij, die meer detail bevatten maar niet publiek zijn.

Tier 2 biedt extra dashboards rond execution, latency, safety en shadow-trades. In plaats van alleen geaggregeerde tellers per run kun je daar de verdeling van execution-uitkomsten, latency-profielen en safety-events per module zien. De precieze strategie-logica blijft daarbij abstract.

Demo trades in Tier 1 zijn afgeleide voorbeelden gebaseerd op echte fills, maar worden zodanig versimpeld en geaggregeerd dat individuele orders, exacte timestamps en venue-details niet te reconstrueren zijn. Ze dienen om gedrag te illustreren, niet om exacte signalen te publiceren.

Sommige observability-lagen tonen gevoelige informatie, zoals latency-profielen, safety-events op detailniveau of bijna-live distributies van execution-uitkomsten. Die zijn relevant voor technische en compliance-doeleinden, maar niet geschikt als publiek dashboard.

De statusstrip en de belangrijkste kaarten geven aan of ingest, evaluatie en execution recent en consistent zijn geweest. Afwijkende safety-modus, opvallende deltas in trade-tellers of grote gaten in snapshots zijn signalen om dieper in de observability-data en logs te duiken.

Ja, de onderliggende DB en exports bewaren per run en per dag relevante snapshots. De publieke site toont een samenvatting van de meest recente toestand; historisch materiaal wordt vooral intern gebruikt voor analyses en audits.

De chatbot gebruikt een retrievallaag die fragmenten uit de actuele documentatie ophaalt en daarboven een generatief model gebruikt. Het model volgt de docs; wanneer documentatie wordt geüpdatet, verandert de kennisbasis mee.

Voor publiek gebruik zijn diagrammen bewust geabstraheerd: minder interne details, meer focus op hoofdcomponenten en dataflows. Meer gedetailleerde weergaven zijn beschikbaar in technische documenten en interne observability-lagen.

Ja. Observability-data is input voor research: welke regimes werken stabiel, waar ontstaan bottlenecks, welke safety-events komen vaak voor. Op basis daarvan worden prioriteiten gesteld voor nieuwe releases.

De observability-site is één van de vensters op de runtime. Daarnaast bestaan er interne rapportages, run logs en validatie-scripts. Samen vormen die een spoor waarmee beslissingen en uitkomsten later gereconstrueerd en beoordeeld kunnen worden.

Het validatiemodel bestaat uit bootstrap-, attach-, evaluation- en lifecycle-proofs. Die combineren logmarkers (bijv. EXECUTION_ENGINE_START, LIVE_EVALUATION_*, DATA_INTEGRITY_*, ROUTE_FRESHNESS_*) met database-tabellen (orders, fills, state) om te laten zien dat een run van start tot fill consistent is.

DOC_INDEX.md en de genummerde laaggidsen 01_ARCHITECTURE t/m 08_OPERATIONS vormen het technische overzicht. Aanvullingen: 00_MODULE_INVENTORY, gespecialiseerde policy-docs en het observability-snapshotcontract met deze site.

Bootstrap-proofs laten zien dat een run correct is gestart vanuit een bekende code- en DB-state. Attach-proofs tonen dat observability en reporting aansluiten op diezelfde state. Lifecycle-proofs leggen vast dat de weg van data-ingest tot en met fills consistent en reproduceerbaar is.

Er zijn controles op ontbrekende of dubbele events, schema-compatibiliteit, typeafwijkingen en onverwachte outliers. Bij problemen worden routes of hele symbolen geblokkeerd totdat de oorzaak begrepen en opgelost is. Validatielogs maken zichtbaar welke checks zijn uitgevoerd.

Ja. Naast live-runs bestaan er observe- en simulation-runs die wel dezelfde data en logica gebruiken maar geen echte orders plaatsen. Die worden gebruikt om nieuwe strategiecomponenten en riskregels te testen voordat ze de live-engine in gaan.

Validatiecode wordt net zo behandeld als de rest van de engine: versiebeheer, code-review waar relevant en duidelijke koppeling aan documentatie. Daarnaast worden validatiescripts periodiek gedraaid op historische data om te controleren of hun gedrag stabiel is.

Runbooks beschrijven de praktische stappen voor starten, stoppen, upgraden en ingrijpen. Het validatiemodel beschrijft welke sporen daarbij achterblijven in DB en logs. Samen zorgen ze dat handelingen reproduceerbaar zijn en achteraf gecontroleerd kunnen worden.

In principe wel, via gecontroleerde toegang tot documentatie, observability-snapshots en geselecteerde log- en DB-views. Deze site is juist ontworpen om die dialoog eenvoudiger te maken zonder gevoelige strategie-informatie te hoeven delen.

Nieuwe releases worden getest tegen bestaande datasets en scenario's waarbij bekende uitkomsten verwacht worden. Afwijkingen worden onderzocht voordat een release live gaat. Validatie-scripts en observability-vergelijkingen helpen om subtiele regressies te vinden.

De documenten op deze site worden automatisch gesynchroniseerd met de hoofdrepository van de bot. Belangrijke wijzigingen worden vastgelegd in de changelog. Daarmee is er een directe koppeling tussen code, docs en wat hier gepresenteerd wordt.

Nee. Teksten, dashboards en FAQ beschrijven technische architectuur, observability en risk-principes. Het is geen aanbeveling om te kopen of verkopen, geen persoonlijk financieel advies en geen uitnodiging tot deelname.

Geen. Publieke en Tier 2-snapshots zijn geaggregeerd en bevatten geen identificeerbare accountdata, geen volledige order-id’s en geen reproduceerbare strategieparameters.

De site is bedoeld voor inzicht in het systeem. Hergebruik van teksten is mogelijk met bronvermelding en zonder suggestie van samenwerking of endorsement tenzij schriftelijk overeengekomen.

Crypto is zeer volatiel; de site bevat risicowaarschuwingen conform het beleid van het project. Dit vervangt geen juridisch advies; operators en bezoekers blijven zelf verantwoordelijk voor naleving van toepasselijke wet- en regelgeving.

Dat voorkomt signal-leakage, beschermt operationele veiligheid en beperkt het risico op misbruik van geaggregeerde maar gevoelige informatie. Observability is bewust vertraagd en gesommeerd.

De inhoud volgt de gesynchroniseerde engine-docs en snapshots; bij afwijking is de repository en runtime-export leidend. De site wordt ‘as is’ aangeboden voor transparantie, niet als garantie op winst of foutloze werking.

Ja. Donaties helpen om verder te bouwen en te testen: ontwikkeltijd, infrastructuur, tooling en testruns. Het is géén aankoop van rendement of signalen — het is steun aan een research- en engineeringtraject.

Dat kan, maar het is geen automatische koppeling. Bijdragers kunnen in aanmerking komen voor uitgebreidere toegang (zoals Tier 2-dashboards), afhankelijk van beschikbaarheid en inhoudelijke match. Dat bespreek je via contact of een Tier 2-aanvraag; vermeld kort dat je wilt bijdragen.

Onder meer server- en runtimekosten, testomgevingen, observability-export, en gefocuste tijd om features te bouwen, regressies te testen en de engine betrouwbaar te houden — niet voor massamarketing.

Nee. Je koopt geen equity en er is geen belofte op winst of terugverdientijd. Een donatie is een vrijwillige bijdrage aan techniek en transparantie; Tier 2-toegang is een mogelijke vervolgstap in overleg, geen ‘product’ dat je koopt.

Gebruik het contactformulier op deze pagina of het Tier 2-toegangsformulier. Vermeld dat je over een donatie of structurele bijdrage wilt praten; dan kan er inhoudelijk worden afgestemd zonder verwachtingen over tradingresultaten.