Getting started
Overview
What a BitPolaris deployment consists of and how the documentation is organised.
The blocks
Four products share one core: accounts and identity, custody, the ledger, and the operations platform. You license one or several. Each block has a public section here (concepts, integration, APIs) and a private section in the client portal (runbooks, architecture, keys).
Where to look
| Exchange | Markets, order types, market making, trading API, WebSocket feeds |
| Token Launch | Rounds, investor onboarding, vesting contracts, claim flow |
| Payments | Invoices, hosted checkout, webhooks, payouts, plugins |
| Wallet | App distribution, custody policy, Address Shield |
| Custody | Vaults, policy engine, approvals, reserve monitor |
| Operations | Roles, audit log, releases, backups, support |
Environments
Every deployment has at least staging and production. Cloud clients get both from us; self-hosted clients run them on their own infrastructure with our installer. Releases always land on staging first and are promoted after your approval in the portal.
Last updated Oct 2026 · applies to release 4.12
Getting started
From signature to go-live
The five-week plan for an Exchange deployment. Shorter products follow the same shape with fewer steps.
Weeks
| 1 | Kick-off. Scope frozen, environments provisioned, branding applied to web and apps. Markets, fees and limits on staging; KYC vendors connected. |
| 2 | Fiat rails and PSP (if any). Market making tuned per pair. Key ceremony with your officers; custody policy signed off. |
| 3 | Store submission for the apps. Security review. Ops team training. |
| 4 | Dress rehearsal on production with real funds at small limits. Runbooks handed over. |
| 5 | Public launch. 24/7 on-call switches from launch mode to steady state. |
What we need from you
A licence or a clear licensing plan, brand assets, developer accounts for the stores, your KYC and bank/PSP contracts (or a decision to use ours), and two or three people who will run operations.
Last updated Oct 2026 · applies to release —
Getting started
Deployment models
Cloud, self-hosted and source. What runs where, and who holds what.
Comparison
| White-label cloud | Dedicated EU instance on Hetzner. We operate, back up and upgrade. Keys encrypted in the instance with HashiCorp Vault; custody block not available in this model. |
| Self-hosted | Installer runs on your bare metal or cloud account (AWS, Hetzner, others). We have no standing access; support sessions use time-limited credentials you issue. |
| Source code | Full repositories, build pipeline and infrastructure code. 90 days of engineer onboarding. Updates optional. |
Sizing
# self-hosted, minimum footprint (production)
3× app nodes 8 vCPU · 32 GB
2× database 8 vCPU · 64 GB · NVMe, replicated
1× queue/cache 4 vCPU · 16 GB
1× custody signer isolated network, HSM optional
1× monitoring 4 vCPU · 16 GB
# staging: half of the above, single database
Last updated Sep 2026 · applies to release 4.12
Exchange
Trading API
REST for orders and account data, WebSocket for market data and private updates. Keys are per user, scoped, IP-restrictable.
Place an order
POST /v1/orders
Authorization: HMAC-SHA256 <key>:<ts>:<sig>
{
"market": "BTC-USDT",
"side": "buy",
"type": "limit",
"price": "81720.00",
"amount": "0.25",
"time_in_force": "GTC",
"post_only": false
}
201 Created
{ "id": "ord_7f3a…", "status": "open", "filled": "0" }
Market data
wss://api.yourbrand.exchange/v1/ws
{ "op": "subscribe", "channels": ["book.BTC-USDT.10", "trades.BTC-USDT"] }
{ "ch": "book.BTC-USDT.10", "bids": [["81726.1","0.88"], …], "asks": [["81729.0","2.31"], …], "seq": 9182311 }
Order types
| market | Executes against the book immediately; slippage limit optional. |
| limit | Rests at price; GTC, IOC, FOK. |
| stop-limit | Becomes a limit order when the trigger price trades. |
| oco | Two orders, one cancels the other. |
| post-only | Rejected instead of taking liquidity. |
Rate limits
Default 20 requests/second per key for orders, 60/second for reads. Market-maker keys get higher limits on request. Limits and remaining budget are in response headers.
Last updated Oct 2026 · applies to release 4.12
Exchange
Market making
How order books stay deep without parking your capital, and the knobs operators control.
How it works
The engine quotes both sides of each market at real, executable prices derived from external reference venues, with a spread you set per pair. Customer fills are hedged automatically; inventory and exposure limits are enforced around the clock.
Per-market settings
| spread | Basis points added around the reference mid. Typical: 2–10 bps majors, 20–50 bps long tail. |
| depth | Quoted size per level and number of levels. |
| max_inventory | Position limit in base asset before quoting narrows to one side. |
| sources | Reference venues used for this market and their weights. |
| pause | Operators can pause quoting per market with one click; a second approver is needed to resume after an incident. |
Your own market makers
External MMs connect with ordinary API keys with raised rate limits. Fee tiers with rebates are configured in the admin.
Last updated Sep 2026 · applies to release 4.12
Payments
Invoices & webhooks
Create an invoice, send the customer to the hosted checkout, receive a signed event when it is paid.
Create an invoice
POST https://api.pay.yourbrand.com/v1/invoices
Authorization: Bearer sk_live_…
{ "amount": "49.00", "currency": "USD", "pay_currency": "USDT", "network": "tron",
"order_id": "A-10422", "success_url": "https://shop.example/thanks", "webhook_url": "https://shop.example/hooks/pay" }
201 { "id": "inv_4821", "checkout_url": "https://pay.yourbrand.com/i/inv_4821", "expires_at": "…" }
Receive the event
POST /hooks/pay
X-Signature: t=1729170000,v1=9f2a…
{ "type": "payment.confirmed", "invoice": "inv_4821", "amount_paid": "49.000000", "tx": "7f3a…c41e", "confirmations": 19 }
# verify: HMAC-SHA256(secret, t + "." + body) == v1
Events
| payment.detected | Transaction seen on-chain, 0 confirmations. |
| payment.confirmed | Confirmation depth reached; merchant balance credited. |
| payment.partial | Underpaid. Includes remaining amount. |
| payment.expired | Invoice expired without payment. |
| payout.sent | Payout to an approved address broadcast. |
Last updated Oct 2026 · applies to release 2.6
Payments
Shop plugins
WooCommerce and Shopify plugins, rebranded and published under your developer accounts.
WooCommerce
Install the plugin, paste your API key, choose accepted assets. Order status moves to Processing on payment.confirmed. Partial payments set a note and a top-up link on the order.
Shopify
Hosted payment gateway app. Approved through the Shopify Partner review under your account; we prepare the listing. Settles to your merchant balance; Shopify sees a standard gateway.
Magento, OpenCart
Available on request; same event model.
Last updated Aug 2026 · applies to release 2.6
Token Launch
Rounds, vesting, claim
How a sale is configured and what investors see.
Round parameters
| price | Per token, in USD; payments accepted in USDT/USDC at par. |
| hard_cap / soft_cap | Round closes at hard cap; refunds enabled automatically below soft cap. |
| min / max per wallet | Enforced on verified identity, not just on address. |
| whitelist | Optional; CSV or API. |
| vesting | TGE unlock %, cliff, linear duration. Per round. |
| jurisdictions | Blocked countries are stopped at registration and cannot complete KYC. |
Contracts
Standard ERC-20/BEP-20 token and vesting contracts are included and audited. Custom mechanics (supply controls, holder tiers) are a module; we arrange a third-party audit before issuance.
Claim
At TGE the vesting contracts are funded. Investors connect the wallet they verified with and claim unlocked amounts from the portal. Schedules are public.
Last updated Sep 2026 · applies to release 1.9
Custody
Policy engine & approvals
Rules, quorums and the reserve monitor. Self-hosted only.
Policy
# policy.yaml (excerpt)
assets:
BTC:
hot_target: 5%
cold_sweep_above: 8%
approvals:
- below: 10000 USD quorum: 1-of-3 delay: 0
- below: 1000000 USD quorum: 2-of-3 delay: 0
- above: 1000000 USD quorum: 3-of-5 delay: 4h
new_address_delay: 24h
daily_cap: 2500000 USD
Approvals
Every approval is a 2FA event by a named officer. Quorums are per asset and amount band. Break-glass procedures are documented and leave a record.
Reserve monitor
An independent service reads on-chain balances for every address under custody and compares them with the ledger continuously. A mismatch alerts; a check that cannot complete is reported as unknown. Proof-of-reserves exports are available on demand.
Last updated Oct 2026 · applies to release 3.1
Operations
Roles, releases, support
How the operations platform is organised and how changes reach production.
Default roles
| admin | Everything. Approves maintenance windows and policy changes. |
| compliance | KYC queue, country rules, tier limits, audit exports. |
| treasury | Withdrawal approvals, hot-wallet thresholds, reserves. |
| support | Customer timeline, tickets, device/session actions. Sensitive actions need a second approver. |
| viewer | Read-only. Used for auditors and demos. |
Releases
Built from version control, tested (1,000+ automated tests), deployed to staging, posted in the portal with changelog, promoted after your approval. Rollback is one command.
Support SLA
| P1 · outage or funds at risk | 15 min response, 24/7, phone page. |
| P2 · degraded | 1 h response, 24/7. |
| P3 · request | 1 business day. |
| P4 · question | 3 business days. |
Last updated Oct 2026 · applies to release 4.12