Does lumibot work with Binance.US?

The lumibot README does not name Binance.US directly, but it names ccxt, the exchange library that ships a Binance.US adapter. Whether the bot's own code handles Binance.US's rules (symbols, order types, rate limits) is not something a README scan can tell. We did not run the bot against Binance.US: this page reports what the public code says and what the exchange itself publishes.

Binance.US facts

CoinGecko trust score: 9 / 10 · rank 14
Country: United States
Established: 2019
24h volume (BTC, normalized): 0
Tradable pairs: 265
Quote currencies: BTC, USD, USDC, USDT
Order types (BTCUSD): LIMIT, LIMIT_MAKER, MARKET, STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT, TAKE_PROFIT_LIMIT
Markets: spot only: no futures, no margin
Puerto Rico residents: Accepted, in writing (source, 2026-09-17)
Fees: 0 % maker / 0.02 % taker on spot (source, April 2026)
Official API: Yes: REST and websocket, HMAC-signed private endpoints (source, 2026-09-17)

Exchange data: CoinGecko public API and the exchange's own endpoints, 2026-09-17. More on the Binance.US page.

What the audit says about running it live

From the lumibot audit (2026-09-17), the controls that matter most once a live API key is connected:

Control	Verdict	Evidence
API key permissions	Not verified	GET /search/code?q=withdraw+repo:Lumiwealth/lumibot+path:lumibot/brokers -> 3 hits (alpaca.py, broker.py, and one more), not individually inspected line-by-line within the session budget.
Orphaned stop-loss	Not verified	No queried directly: would require reading each broker adapter's order-submission code (alpaca.py 84 KB, schwab.py 158 KB, tradier.py 104 KB, etc.) to see whether stop-loss orders are placed as broker-native conditional orders or simulated in-process.
Websocket and data reconnection	Partial	docs/FAST_ORDER_LIFECYCLE_GUIDE.md, section 'Schwab Profile': 'uses account-activity WebSocket messages as a wake-up signal... performs an active-order reconciliation after login or reconnect and retains a 30-second broad order-history poll only as a healing fallback' and 'Schwab 429 responses suppress more reads... for the server's Retry-After interval, or bounded exponential backoff with jitter when that header is absent.'
Order rejection handling	Partial	docs/FAST_ORDER_LIFECYCLE_GUIDE.md testing matrix explicitly lists 'rejected hedge and bounded retry' as something a regression suite 'should cover', and states 'the strategy still owns its deadline, replacement, hedge, and conflict policy. Do not turn one strategy's timeout or risk rule into a global LumiBot default.'
Position reconciliation with the exchange	Partial	docs/FAST_ORDER_LIFECYCLE_GUIDE.md: the order state machine includes 'a bounded exact-order reconciliation read after a missed callback, restart, reconnect, or ambiguous mutation result', confirmed implemented for Schwab ('performs an active-order reconciliation after login or reconnect').

Before you connect a key

Create the API key with trading enabled and withdrawals disabled, and restrict it to your server's IP if Binance.US allows it.
Start in paper or dry-run mode if the bot has one (the README mentions it).
Decide the maximum loss per day before the first order and check the bot can enforce it: see the circuit breaker control. If it cannot, the watchdog enforces it from outside with a read-only key.