From f9caaf7babb6e3dc4be4d740bbe7f4acd62c5223 Mon Sep 17 00:00:00 2001 From: Leticia Date: Thu, 2 Apr 2026 14:29:16 +0200 Subject: [PATCH] docs(roadmap): add Bitget as optional venue candidate --- .agents/current-state.md | 1 + README.md | 1 + docs/roadmap.md | 1 + 3 files changed, 3 insertions(+) diff --git a/.agents/current-state.md b/.agents/current-state.md index 14524e5..a3a99c9 100644 --- a/.agents/current-state.md +++ b/.agents/current-state.md @@ -39,6 +39,7 @@ - keep broker execution auditable before any broader live routing or retry logic - preserve paper-session discipline as a prerequisite, not the current bottleneck - keep Kraken as the first implemented execution boundary while positioning Hyperliquid as the first next venue intended for personal connection + - treat Bitget as a later optional comparison venue after Hyperliquid, not a current priority - review whether the current boundary can express Hyperliquid signer, wallet, routing, and websocket semantics without ad hoc adapter leaks - keep the first Hyperliquid supervised submit path intentionally narrow and auditable before adding richer session, status, or websocket execution work - add local operator visibility over canonical Hyperliquid submit sessions before widening execution further diff --git a/README.md b/README.md index f895220..3cb665b 100644 --- a/README.md +++ b/README.md @@ -33,6 +33,7 @@ Execution venue strategy note: - `Kraken` remains the first implemented real-execution backend - `Hyperliquid` is the first next venue intended for personal connection and supervised practical use +- `Bitget` is a later optional comparison venue, after Hyperliquid, not the next default target - this is why `QuantLab web3 app` is now the right public direction, even though the product is still earlier in runtime maturity than that label's end-state implies - `BrokerAdapter` remains the current code name, but the architecture should now be read as an execution-venue boundary, not only a CEX-style broker boundary - a minimal `ExecutionContext` layer now exists in code so future venue work can model signer and routing semantics without overloading `ExecutionIntent` diff --git a/docs/roadmap.md b/docs/roadmap.md index 063de58..bbda40b 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -253,6 +253,7 @@ The first real execution-venue integration should follow this decision framework - define and stabilize `BrokerAdapter` before integrating any exchange-specific backend - keep `Kraken` as the first implemented backend and safety proving ground - move `Hyperliquid` ahead of `Binance` as the first next venue intended for personal connection and supervised practical use +- consider `Bitget` as optional later comparison work after `Hyperliquid`, not the default next venue - treat `Binance` as optional later comparison work, not the default next venue - treat CCXT as optional acceleration for prototypes, smoke tests, or broad exchange experimentation, not as the authority of the execution design