Skip to content

docs(roadmap): add Bitget as optional venue candidate #248

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Whiteks1 merged 1 commit into from
Apr 2, 2026
Merged

docs(roadmap): add Bitget as optional venue candidate #248

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .agents/current-state.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
1 change: 1 addition & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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`
Expand Down
1 change: 1 addition & 0 deletions docs/roadmap.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
Loading