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.

3 min readUpdated 3 August 2026binance, exchange-provider, spot, ccxt, liquidity

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 polls fetchTickers with 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 withdraw on your Binance account.
The admin finance screens — exchange balance, fee comparison, chart cache, currency and market import.

Where to start

Install

Licence, credentials, enable, restart, verify. In that order — the toggle is gated on a licence file and the credentials are only read at boot.

Binance API keys

Which permissions to tick, which to leave alone, and why the IP allowlist is not optional.

Currencies and markets

The two imports, in the order they have to run, and why every imported market arrives switched off.

Deposits and withdrawals

How a customer's coins get into — and out of — your Binance account, and the single field that links a deposit to a person.

Connection reference

Clock sync, instance caching, rate limits and the Redis key that can silently mute the entire spot stack.

Troubleshooting

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.