MMashDiv

Installing the Binance provider

Activate the licence, add the API credentials, restart, enable the provider and verify the connection — in the order that avoids a green toggle over a dead connection.

9 min readUpdated 26 August 2026install, licence, env, verify, proxy

There is no package to unzip by hand. Installing this product means five things, in order: activating the licence, installing the release from the Extension Manager, putting credentials where the backend can read them, restarting so it reads them, and switching the provider on.

The order matters. The enable switch stays disabled until the licence is activated, the release is not on the server until Install has been pressed and applied, and the credentials are only picked up at process start — so enabling before restarting gives you an active provider with no working connection.

Before you begin

  • A working Bicrypto install — backend, frontend and cron running
  • Your purchase code for Binance (product ID 38650585), from your MashDiv dashboard
  • A Binance account with API access and identity verification completed
  • The public egress IP of the server, not the IP your domain resolves to
  • Shell access to the project root, to edit .env, run pnpm updator and restart processes
  • Admin panel access with the edit.exchange and create.license permissions

1. Activate the licence

Open Admin → System → Extension Manager and switch to the Exchanges tab, or go straight to /admin/system/extension?type=exchange. The page heading is Add-ons & Integrations; every exchange provider is a card in the grid, carrying its version, a licence chip and an enable switch. Until the licence is activated the Binance chip reads Activate and the switch is disabled — its tooltip reads Activate license first. Click the card to open the product page.

  1. The Binance card — click it to open the product page
  2. KuCoin, like every other provider, reads Activate — only one exchange can be on at a time

On the product page press Activate License. The licence screen — Secure License Activation, heading Activate Your License — shows the product name and Product ID 38650585. On the Purchase Code tab paste the code from your MashDiv dashboard, optionally an email address for update notifications, and press Activate License. The screen confirms License Activated! and returns you to the product page a couple of seconds later.

If the server has no outbound access, use the License File tab on the same screen instead: download the licence certificate from your MashDiv dashboard, place it as license.txt in the lic folder at the project root, and press the button on that tab. The tab shows the Expected Product ID it will accept.

  1. Paste the purchase code here
  2. Activate License — then wait for the redirect back to the product page
  3. The License File tab, for a server with no outbound HTTPS
  4. The Product ID — it must read 38650585

Activation writes the machine-bound licence file lic/38650585.lic under the project root; keep that folder in your backups, because a restore or redeploy that loses it leaves the provider reporting itself unlicensed on the next page load (Troubleshooting covers that case).

POST/api/admin/system/license/activatepermission: create.license
Activates a licence for any product, including exchange providers. This is the call behind the Activate License button on the licence screen.

2. Install the release

Back on the product page — now the licensed view, with Licensed and Inactive chips, an Enabled/Disabled switch in the heading and the Overview, Releases and Capabilities tabs — the Overview tab has a release panel showing Current Version. When the licence server has a newer build than the one recorded on this install it reads Update Available with a Latest Version line and an Install v… button. Press it. If the panel says Up to date on a provider you have only just licensed, press Check for Updates once — it asks the licence server again instead of reading the ten-minute cache — then install whatever it offers. The Releases tab holds the notes for the version being offered; read them first.

Install downloads that version from the licence server, verifies its SHA-256 and extracts it over the project root. It runs no migrations, installs no dependencies, builds nothing and restarts nothing, so finish it from a shell on the server:

pnpm updator

That is the finalise chain — stop, dependencies, schema, seed data, frontend build, start. Updates are applied one version at a time; if several are pending the panel offers the next one and re-checks after each. If the panel still says Up to date after the check there is nothing to download — the release already on the server is current — and you move on to the API key.

  1. Check for Updates, then Install v… when it is offered
  2. Releases — the notes for the version you are about to install
  3. The Enabled switch — step 6, not yet

3. Create the Binance API key

Do this before you touch .env. The permissions and the IP allowlist decide which half of the platform works, and getting them wrong produces failures that look like configuration errors rather than permission errors.

Full walkthrough: Binance API keys.

4. Add the credentials

Both variables go in the project root .env. Binance uses a two-part credential — there is no passphrase, unlike KuCoin.

APP_BINANCE_API_KEY="your_api_key"
APP_BINANCE_API_SECRET="your_api_secret"
APP_BINANCE_API_KEYtype: secret
Binance API key. Read at connection time from the environment; never stored in the database.
APP_BINANCE_API_SECRETtype: secret
Binance API secret.

The backend never contains those literal names. It builds them from the active provider's alias:

APP_${PROVIDER}_API_KEY
APP_${PROVIDER}_API_SECRET
APP_${PROVIDER}_API_PASSPHRASE

So the connector reads APP_BINANCE_API_KEY because the provider alias is binance. A typo in the variable name is indistinguishable from a missing key: the connector logs that credentials are missing and falls back to a public connection.

There is one more variable, and it is not what most people assume:

NEXT_PUBLIC_EXCHANGEtype: stringdefault: binscope: rebuild
First three letters of the exchange alias. Read by the frontend only — the TradingView chart component uses it to pick the symbol prefix, and the market-data WebSocket service uses it to pick the order-book depth ladder the browser requests. Zero backend readers — it does not select the trading connection, and setting it wrong does not break trading. Requires a frontend rebuild.

5. Restart the backend

.env is read once, at process start. The connector also caches one live Binance instance per provider name for the lifetime of the process, so editing credentials without a restart changes nothing at all. (pnpm updator in step 2 restarted everything too — but that was before .env held the keys.)

pm2 restart backend cron

Restart cron as well. The currency price job, the deposit verifier and the withdrawal reconciler all build their own connections in that process.

6. Enable the provider

Back on Admin → System → Extension Manager → Exchanges, turn the switch on the Binance card on — it is usable now that the licence is verified. The Enabled switch in the heading of the product page is the same control. This is what makes Binance the platform's active exchange: Admin → Finance → Exchange Providers now shows it as the active provider, and the spot trading, deposit and withdrawal paths build their connections against it. From now on clicking the Binance card in the Extension Manager opens that hub rather than the product page, which stays reachable at /admin/system/extension/38650585.

PUT/api/admin/finance/exchange/provider/{id}/statuspermission: edit.exchange
Enables or disables a provider — both switches call it. Enabling one switches every other provider off in the same action.

Two behaviours to expect:

  • Until the licence is activated the switch is disabled (Activate license first), and a direct call to the endpoint answers 403 with licenseRequired: true — the provider stays off.
  • Enabling Binance disables KuCoin and XT in the same action; only one exchange provider can be active. If you are migrating between providers, the switch is atomic but the market and currency data are not — see Currencies and markets.

Turning Binance off later is the same switch. It leaves the licence in place, so switching it back on needs no reactivation.

7. Verify the connection

Open Admin → Finance → Exchange Providers (/admin/finance/exchange) and press Verify Credentials.

POST/api/admin/finance/exchange/provider/{productId}/verifypermission: edit.exchange
Builds a throwaway connection with the saved credentials, loads markets, fetches the account balance and closes. Never on the audit trail — it reads, it does not change anything.

The check does three things in sequence, and each one can fail differently:

  1. Synchronise the clock — it brackets a fetchTime call to measure drift against Binance's clock, then signs from just behind the server. A failure here does not stop the check; it falls back to signing a full second behind.

  2. Load markets — this is the first real request. A blocked region answers HTTP 451 and the screen tells you to configure a proxy.

  3. Fetch the account balance — the only step that proves the key and secret are valid and that the request came from an allowlisted IP.

A green result means reading works. It does not prove that withdrawals will: the withdrawal permission is never exercised until the first real payout.

8. If your server's region is blocked

Binance refuses connections from some regions with HTTP 451, and the verify screen recognises it: "Your server's location is blocked by this exchange."

The provider supports an outbound proxy, configured per provider in the Settings tab of the exchange provider hub. http://, https://, socks4:// and socks5:// are all accepted, with optional credentials in the URL.

  1. Open the Settings tab
POST/api/admin/finance/exchange/provider/{productId}/test-proxypermission: edit.exchange
Opens a credential-less connection through the supplied proxy and calls fetchTime. Test before saving — the test uses its own connection and cannot disturb the running site.
PUT/api/admin/finance/exchange/provider/{productId}permission: edit.exchange
Saves the proxy URL for the provider and evicts the cached connection so the next request rebuilds through the proxy.

Two consequences worth planning for. The proxy's IP — not your server's — is what reaches Binance, so that is the address to put on the key's allowlist. And any credentials embedded in the proxy URL are masked before the provider is returned to the browser, so the field you see is not the value that is stored.

Without a proxy the connector forces IPv4 on its outbound agent. That is deliberate: exchange IP allowlists are IPv4, and a dual-stack box that happens to prefer IPv6 presents an address that was never allowlisted.

What is still missing

An enabled, verified provider has no markets. Nothing is tradable until you import currencies and markets and then enable individual pairs.

  1. Import spot currencies, then markets
  2. Enable the pairs you actually want to list
  3. Understand the deposit and withdrawal path before you take real money