Binance Exchange Provider
Back the platform's spot markets with your own Binance account — what an exchange provider is, how it differs from Ecosystem, and what an operator takes on by running one.
An exchange provider points the platform's entire spot stack at somebody else's order book. With this product licensed and enabled, every spot market, ticker, chart, order, deposit address and withdrawal on your install is a call to your Binance account.
That is the whole product. There is no matching engine to install and no
blockchain node to run. What you are buying is the right to switch the binance
row on, plus the update channel for it — the connector code itself is part of
the core backend and speaks to Binance through ccxt.
What it requires
| Requirement | Why | If it is missing |
|---|---|---|
| Bicrypto core | Everything. This is a provider for the core's spot stack, not a standalone app | Nothing to enable |
| A Binance account with API access | It is the account that holds the float, fills the orders and pays the withdrawals | The provider connects but every authenticated call fails |
APP_BINANCE_API_KEY / APP_BINANCE_API_SECRET in .env |
Credentials are read from the environment at connection time, never from the database | The provider silently degrades to public-only data |
| An allowlisted server IP on the Binance key | Binance requires it for withdrawal-enabled keys | Withdrawals fail; unrestricted keys also expire on Binance's own schedule |
Nothing else. It does not need Ecosystem, ScyllaDB, a master wallet or a vault key, and it does not conflict with them — an install can run Binance-backed spot markets and its own Ecosystem markets side by side, because they use different wallet types and different order paths.
Binance, KuCoin and XT all write to the same exchange table and the platform
resolves exactly one row with status = true. Enabling one runs a transaction
that switches every other provider off. There is no per-market provider
selection, and no failover between providers.
Rented markets, not your own book
This is the distinction that decides whether you want this product or Ecosystem, and getting it wrong is expensive.
| Binance provider | Ecosystem | |
|---|---|---|
| Where the order book lives | Binance's servers | ScyllaDB on your own box |
| Who fills a customer's order | Binance's counterparties | your other customers |
| Where the coins actually sit | one Binance account you control | per-user addresses this install derived and signs for |
| The market list | imported from Binance, thousands of pairs | pairs you define from tokens you added |
| Wallet type on the customer's balance | SPOT |
ECO |
| Price and volume data | Binance's, passed through | produced by your own trades |
| What you own if the integration dies | nothing but the ledger | the whole venue |
The practical reading: with this provider you get real liquidity and real prices on day one without holding a single private key, and in exchange every customer position on your platform is a claim against one exchange account. The platform's own record of a customer's balance is an internal ledger row. The asset backing it is a number in your Binance account, and Binance decides whether you can move it.
What it actually powers
Once the provider is live, these stop returning empty and start working:
- Market list and tickers —
/market, and the ticker stream that feeds it. For Binance the platform pollsfetchTickerswith every enabled symbol on a one-second cadence rather than opening a watch stream. - The trade screen —
/trade?symbol=BTC-USDT. Per-symbol price, candles and order book arrive over Binance's own WebSocket feeds. - Order placement — a customer's order is validated against the market's
imported precision and limits, then placed on your Binance account with
createOrder. The customer's SPOT wallet is debited, credited or put on hold from what Binance reports back. - Spot deposits — the deposit screen shows your Binance deposit address for the chosen currency and network. See Deposits and withdrawals.
- Spot withdrawals — approved withdrawals call
withdrawon your Binance account. - The admin finance screens — exchange balance, fee comparison, chart cache, currency and market import.
Where to start
Licence, credentials, enable, restart, verify. In that order — the toggle is gated on a licence file and the credentials are only read at boot.
Which permissions to tick, which to leave alone, and why the IP allowlist is not optional.
The two imports, in the order they have to run, and why every imported market arrives switched off.
How a customer's coins get into — and out of — your Binance account, and the single field that links a deposit to a person.
Clock sync, instance caching, rate limits and the Redis key that can silently mute the entire spot stack.
The failure messages you will actually see, and what each one means.
Three things worth knowing on day zero
Credentials live in .env and are read at connection time. They are never
stored in the database and never shown in the admin panel. The names are built
at runtime from the provider alias, so grepping the source for
APP_BINANCE_API_KEY finds nothing even though it is load-bearing. Changing
them requires a backend restart — see
the core environment reference.
A bad connection degrades quietly rather than failing loudly. If the authenticated market load fails for a reason that is not a rate limit or a clock skew, the platform builds a second, credential-less Binance instance so public data keeps flowing. Charts and tickers carry on looking healthy while the currency import returns nothing and deposit addresses cannot be issued.
Your Binance account is the float. Nothing reconciles it for you. The admin balance screen reads the real account, but no screen sums what your customers are owed against it. If customers hold more BTC in the ledger than the account holds, the shortfall surfaces on the first withdrawal that cannot be paid.