Instant delivery

Lifetime updates

1 domain license

Addonv6.4.4

Ecosystem for Bicrypto

Name: Ecosystem for Bicrypto
Brand: MashDiv
SKU: ecosystem
Price: 849.00 USD
Availability: InStock

Your own matching engine and your own on-chain custody — the addon that turns a brokerage into an exchange.

4.90218 sales

$849$999Save 15%

You'll also need Bicrypto

On its own, Ecosystem for Bicrypto won't work — it only runs if you already own Bicrypto. Open the Requirements tab to see exactly what you need and add it to your order.

See it working Live demo Documentation View on CodeCanyon

Your own order books — limit and market orders match in-house
Stop orders rest outside the engine until their trigger is crossed
Price-time priority: the oldest order at a price fills first
Maker and taker rates you set per market, charged in the quote asset
Every fee lands in a wallet you hold and books an admin-profit row
Order book, ticker, tape and 13 candle intervals, live over WebSockets
20 chains in code: 12 EVM, 4 UTXO, 4 licensed blockchain addons
Add any EVM chain from the panel — RPC and chain ID tested first
Deploy a token contract from the panel, or import one by address
A deposit address per customer per chain — NO_PERMIT tokens use a shared contract
Private keys AES-encrypted behind a vault passphrase only you hold
UTXO payouts batch up to 20 recipients into one network fee

Inside Ecosystem

The fill happens on your server

An in-house matching engine with order books of its own, on-chain custody across twenty configured chains, and the maker/taker take on every trade landing in a wallet you hold.

In detail

Ecosystem gives your install the two things a brokerage cannot fake: an order book of its own, and the keys to the coins. Orders match in an engine running in your own process, fills settle against wallets you control, and the maker/taker take on every trade lands in a wallet on your own account.

How it works

A market is two of your tokens, with your precision, your size and value limits, and your maker and taker rates. Limit and market orders go into the matching engine and fill on price-time priority — best price first, and at the same price the oldest order first, which holds across a restart because the ordering is a property of the table rather than of memory. Stop-limit and stop-market orders are accepted on the same endpoint but rest outside the engine until their trigger price is crossed. Every fill writes the order book, the trade tape and all thirteen candle intervals, streamed live over WebSockets; the ticker is computed from the running daily candle rather than stored.

What you can run

Surface	What ships
Order types	limit, market, stop-limit, stop-market
Chart intervals	13, from 1m to 1w
Built-in EVM chains	12
UTXO chains	4, each with its own confirmation depth
Licensed chains	Solana, Tron, Monero, TON — one addon each
Custom EVM chains	any number, added from the panel

What operators control

Deploy a token contract from the panel, or import an existing one by address
Fees, precision, order-size and minimum-value limits, per market and per token
Master wallets per chain, custodial contracts, the private ledger and unspent outputs
Forty-one permission keys seeded, twenty-six of them enforced by a route, all shipped ungranted
The vault passphrase that unlocks every encrypted key on the install

Every customer gets their own deposit address per chain, with one exception named below. The master wallet is a gas tank that pays network fees and signs deployments, not a pooled reserve. Futures, NFT Marketplace, Copy Trading and AI Market Maker all build on this engine.

Ecosystem is an addon: it needs a Bicrypto install to extend, plus ScyllaDB and Redis alongside the standard stack, and ScyllaDB is not covered by the built-in database backup — orders, candles and the trade tape are yours to snapshot. Per-customer addresses have one exception: an EVM token flagged `NO_PERMIT` cannot sign for its own gas, so it deposits into a shared custodial contract the platform deployed instead of to the customer's own address. Native coins, permit-capable tokens, every UTXO chain and all four licensed chains use the customer's own address. A new market has no chart until someone trades it, because nothing imports price history. And if the vault passphrase is lost, every address on the install becomes unreadable with no recovery path.

List your own asset, and it trades on your own book

Deploy a token contract from the admin panel or import one that already exists by address, pair two of them, and you have a market. You set the precision, the order-size and minimum-value limits, and the maker and taker rates — a rate of zero is a valid configuration and is honoured. From the first fill the market produces its own order book, ticker, trade tape and thirteen candle intervals, streamed live over WebSockets.

There is no imported price history: a new pair shows nothing until somebody trades it. If you need a market quoted from day one, that is the separate AI Market Maker product.

Every fill pays you, in the quote asset, into a wallet you hold

You set a maker and a taker rate per market, and both sides of a fill are charged their own — the maker being whichever order set the execution price. The take is credited to an ecosystem wallet on your own account in the market's quote currency, and a revenue row is written against that credit naming both order ids, so every figure on the report is money that actually moved rather than a number that was calculated. There is no conversion step: a MYT/USDT market pays you USDT and a MYT/BTC market pays you BTC.

A rate of zero is a valid configuration and is honoured — the placement path checks whether a rate is set, not whether it is non-zero. Your own orders and the market maker's are excluded before anything is collected, because charging them would credit the wallet the money came from. Withdrawal fees are a separate setting per token, booked only after the send succeeds.

A stop rests outside the book, and something has to keep the promise

Limit, market, stop-limit and stop-market are the four order types. The two stops are not orders the matcher can see — they live in a store of their own, so the funds are reserved when the stop is placed rather than when it fires, and a monitor is what turns one into a real order. It fires on the fill that crosses it, with a two-second sweep behind that and a reconcile every minute that recovers a stop the index lost.

Six states, and two of them exist because a cancel and the monitor can reach the same stop at the same moment: exactly one of them wins the claim. A stop whose funds cannot be reserved is marked FAILED rather than left resting, because a stop that is not held is a protection the trader does not actually have. There is no admin screen that lists resting stop orders.

Every customer's coins sit at their own address

The master wallet is not a pooled reserve — it is a gas tank. It pays the network fee when the platform moves a token for a customer, and it signs token and custodial-contract deployments. The coins themselves live at each customer's own address, issued per chain, watched for deposits and credited once they reach the required confirmations: twelve on EVM chains, three on Bitcoin, six on Litecoin, Dogecoin and Dash.

One token shape is the exception: an EVM token flagged NO_PERMIT cannot sign for its own gas, so it deposits into a shared custodial contract the platform deployed rather than to the customer's own address. Native coins, permit-capable tokens, every UTXO chain and all four licensed chains use the customer's own. Every private key is AES-encrypted with a vault key your passphrase unlocks, and the encrypted blob is the only copy that exists — lose the passphrase and no support process can recover those addresses.

Twenty chains in the code, and any EVM chain you add

Twelve EVM chains and four UTXO chains are configured in the source and need nothing but their environment variables and a master wallet. Solana, Tron, Monero and TON are the other four, and each is a separate blockchain addon. Anything else EVM-compatible you add yourself from the panel: the create form probes the RPC, WebSocket, chain ID and explorer before the row is saved, then hydrates the chain into the live registry with no code change.

The four licensed chains are gated twice — the licence, and the chain's service module actually being installed. Budget for the addon if your customers deposit on those networks. Every chain, licensed or not, ships off until you configure it.

Twenty Bitcoin payouts can leave on one network fee

Bitcoin, Litecoin, Dogecoin and Dash do not spend like an account balance — every payment is built out of previous receipts. The payout queue uses that: withdrawals waiting on the same chain are gathered into a single transaction with up to twenty recipients and up to a hundred inputs, signed once and broadcast once, so the network fee is paid once instead of twenty times. On the operator's side it is just the queue moving rows from PENDING to COMPLETED.

Nothing is held back to fill a batch: whatever is queued together goes together, and the accumulation window that would deliberately wait for company is off unless you set it. Two sends on the same chain are kept at least five seconds apart. A payout to an address belonging to another customer of yours never reaches a chain at all — it settles internally and costs nothing.

You find a shortfall on a screen, not from the customer

The custody console compares what customers are owed against what the addresses actually hold, less whatever the withdrawal engine has already committed — and rates every asset covered, partial or unbacked. The list is sorted worst first rather than by size, so a small asset that is fully unbacked leads and does not get buried under the big ones that are fine. Beside it sits the withdrawal pipeline by status, per-chain readiness, and a flag on any master wallet running low on gas.

The number this screen does NOT show you is the master wallet balance, and that is deliberate — the master wallet is a gas payer, not a reserve, so its balance backs nothing and reading it as solvency is the mistake the console exists to prevent. Sixteen screens sit under Admin → Ecosystem, plus the order desk in Finance, five scheduled jobs and six repair scripts that are all dry-run by default.

chains configured in code: 20
order types accepted: 4
candle intervals: 13
permission keys enforced: 26

Everything included

139 capabilities, in 12 areas

Every item below exists in the source you receive. Nothing here is a roadmap.

The matching engine

Order books that fill in your own process, not on somebody else's venue.

In-house matching engine running inside your own backend
Limit and market orders matched against your own book
Price-time priority — best price first, oldest first within a price
Partial fills, with every execution recorded on the order itself
Funds held on the wallet row at placement, never debited early
Market-order liquidity check that refuses rather than half-filling
Price improvement refunded to the customer as each fill settles
Cancel one order, or every open order under a single lock
Order placement served by any process in a multi-process deployment
Resident order window per side per market, sized by you
Aggregated order book reconciled against real orders every five minutes

Order types, holds and stop orders

Four order types: limit, market, stop-limit and stop-market
Three order states: OPEN, CLOSED and CANCELED
Stop orders rest in their own store, outside the matcher
Six stop states, including the transient claim states
Trigger direction derived from a reference price at placement
Slippage headroom reserved on a stop-market buy, released at trigger
Stops fire on the fill that crosses them, plus a two-second sweep
A minute-by-minute reconcile that recovers an unindexed stop
Crash recovery that never re-places an interrupted trigger
Every market limit enforced on a stop at placement, not at trigger
Per-user order throttle sized for active traders, not for checkouts
The platform's trading verification gate, enforced before any order type

Markets and token listing

What trades, and every dial on it.

Deploy a token contract from the panel — ERC20, BEP20, HRC20, CRC20 or SPL
Import an existing contract by address on any configured chain
Import a chain's native coin as a tradable, withdrawable asset
Three token contract types: NATIVE, PERMIT and NO_PERMIT
Per-token deposit and withdrawal minimums and maximums
Per-token display precision, enforced on withdrawal
On-chain holders list per token contract
Markets built from any two active tokens, one row per pair
Per-market amount and price precision
Per-market order-size, price and total-value limits
Trending and Hot flags for the market list
Status toggles on both tokens and markets — the reversible way to retire an asset
Bulk delete from the table toolbar, with an open-copy-trade guard on a single market

Fees and where the revenue lands

Maker and taker rates per market; a rate of zero is honoured
Maker or taker decided at placement, against the real book
Fee charged per side, always in the quote asset
Fee credited to a wallet on your own account, one per quote currency
A profit row per fee, reconcilable back to both sides of the fill
Market-maker orders and your own side excluded from the profit report
A separate on-chain withdrawal fee per token: a percentage with a floor
Withdrawal fee booked only after the send succeeds
Both fee types on the platform's revenue analytics screen

Market data and charts

Produced by your own fills — there is no upstream feed.

Candles built from your own fills, thirteen intervals from 1m to 1w
Every fill writes all thirteen intervals at once
Ticker derived from the live daily candle against the previous close
Public trade tape, with market-maker prints flagged apart from customer fills
Trade-tape retention in days, or kept forever
Historical chart endpoint with gap filling and lookback projection
Four live channels: market, all-markets ticker, a user's own orders, deposits
Per-symbol subscriptions for ticker, trades, depth and OHLCV, each with its own depth or interval
Candle repair for duplicate and discontinuous series

Custody, keys and the master wallet

Where the coins are, and what unlocks them.

AES-256-GCM vault key, unlocked by a passphrase you hold
Vault state and unlock prompt on the admin console masthead
Unattended unlock at boot, or a manual unlock per restart — your choice
One master wallet per chain, key material encrypted the moment it is created
Master wallet as gas payer, token deployer and custodial-contract owner
Live master-wallet balances and on-chain transaction history
Enable or disable a master wallet to stop deriving on a chain
A deposit address per customer per chain, derived at the next unused index
Shared custodial contracts for EVM tokens that cannot pay their own gas
Custodial wallet states: ACTIVE, INACTIVE and SUSPENDED
Sweep native coin or a token out of a custodial contract
Address self-heal that reissues a missing or wrong-format entry

Deposits

Live deposit monitor over WebSocket while the customer's page is open
Background scanner for every address seen in the last 72 hours
A per-chain rate budget, so a provider limit holds regardless of user count
A dedicated Bitcoin scanner on its own minute cycle
Zero-confirmation detection over ZMQ against a self-hosted Bitcoin node
Seven deposit monitors: UTXO, Solana, Tron, Monero, TON, MO tokens and EVM
Pending deposits held outside the process between detection and crediting
One crediting path: a confirmation-depth watchdog on a minute cycle
Per-chain depth — 3 on Bitcoin, 6 on Litecoin, Dogecoin and Dash, 12 elsewhere
A custodial address held for the deposit session, releasable early

Withdrawals and the payout queue

The path out, and everything that stops it going wrong twice.

Per-chain address validation before anything is debited
Decimal precision checked against the token's own setting
Step-up two-factor on a payout, when the platform's policy asks for it
Debit under a row lock, alongside a pending transaction row
A queue moving each payout PENDING, PROCESSING, COMPLETED
Boot-time sweep that re-enqueues every orphaned pending row
A five-minute watchdog and a thirty-minute pass, coalesced onto one run
A payout already broadcast is promoted, never re-broadcast
Rows recovery will not classify are left for a human and counted on the console
A maximum-withdrawable figure for the customer's form
A payout to another customer's address settles internally, off-chain
A payout to the customer's own address refused outright
A five-second minimum gap between sends on the same chain

The UTXO chains

Bitcoin, Litecoin, Dogecoin and Dash do not behave like the rest.

Four UTXO chains, each with its own provider
Provider choice per chain: a public explorer, BlockCypher, or your own Bitcoin node
Tracked unspent outputs in three states: UNSPENT, LOCKED and SPENT
Four output origins: DEPOSIT, CHANGE, CONSOLIDATION and SYNC
Locked inputs tagged with the broadcast that reserved them
Pooled coin selection across every deposit address for the currency
Up to 100 inputs in one transaction
PSBT batching — up to 20 recipients on a single network fee
A batch window that parks a lone payout so a later one can join it
Per-recipient failure isolation inside a batch
Bitcoin fee-tier selection, checked by the chain diagnostics
Reconciliation that backfills confirmed outputs missing from the record
Automatic consolidation when the pool is too fragmented to spend
A refusal that names the maximum possible withdrawal right now

Chains and networks

Twenty chains configured in the source, every one of them off until you enable it
Twelve built-in EVM chains, enabled by their environment variables
Four licensed non-EVM chains: Solana, Tron, Monero and TON
Any number of operator-defined EVM chains, added from the panel
A create form that probes RPC, WebSocket, chain ID and explorer before it saves
A custom chain hydrated into the live registry with no code change
The custom chain's native coin registered as a token for you
Guards against shadowing a built-in symbol or duplicating a chain ID
Confirmation depth and display precision per custom chain
A requirements console listing every variable the runtime reads, required or optional
Dead keys named as dead — read by nothing, safe to remove
Live diagnostics reporting readiness per flow: deposits, withdrawals, history
A transaction-history provider chain, tried in the order you set
Custody guards on deleting a custom chain — master wallet, or customer balances

The private ledger and internal transfers

Money that moves between customers without moving a coin.

Transfer between two customers' ecosystem wallets without touching a chain
The recipient's wallet and its addresses provisioned on demand
Paired outgoing and incoming rows, each carrying the balance before and after
Both wallet rows locked in a fixed order, under an idempotency key
A private ledger recording what an address has already paid away
That figure subtracted before the engine will source a payout from an address
The same figure subtracted before the console reports coverage
Ledger rows editable, with the account holder shown beside the number
Ledger view scoped to the network each chain is configured for

The admin console, jobs and repair tools

What you need to run an exchange on a Tuesday afternoon.

Sixteen screens under Admin → Ecosystem, plus the ecosystem order desk in Finance
A custody overview rating every asset covered, partial or unbacked
The withdrawal pipeline by status, with the stuck rows broken out
Per-chain health: RPC configured, extension enabled, custody held, gas in the tank
An order desk with book-state, flow-over-time and liquidity analytics
Corrupted-order cleanup, with a dry-run scan first
A per-customer Ecosystem tab on the CRM record
41 seeded permission keys, 26 of them enforced across the addon's own routes
Five scheduled jobs on the platform's cron screen, each stoppable
Six repair scripts, every one of them dry-run by default
An index check that exits non-zero on drift — usable as a deploy gate
Engine tuning: book source, resident window, backfill pause, tape retention, pool size
Disabling the extension stops the engine, the jobs and the deposit scanners

Licence: Addon licence, activated in the extension manager and bound to the install
Requires: A working Bicrypto core install. Ecosystem is an addon and cannot be enabled without it.
Runs on: Your own Linux server. There is no hosted tier.
Extra services: ScyllaDB for the trading keyspace, and the core's Redis worked harder. Neither is set up by the platform installer.
Processes: No new process. The engine boots inside the backend, and exactly one process in the deployment holds the matching lease.
Admin surface: 16 screens, plus the ecosystem order desk under Finance
Access control: 41 seeded permission keys, 26 enforced on the addon's routes — all shipped ungranted
Chains: 20 in the source — 12 EVM, 4 UTXO, 4 licensed — plus any EVM chain you add from the panel
Trading surface: 4 order types, 13 candle intervals, 4 live WebSocket channels, 5 scheduled jobs
Storage: 8 MySQL tables of its own, plus 7 tables and 4 views in the ScyllaDB trading keyspace
Other products that need it: Futures, NFT Marketplace, Copy Trading, AI Market Maker, Trading Bot and the Hummingbot Connector all trade or settle through this engine. The Solana, Tron, Monero and TON addons extend its custody.
ScyllaDB is not optional for trading: Without it the trading endpoints answer 503. Wallets, deposits and withdrawals still work, but there is no book, no chart and no tape.
ScyllaDB is in no backup this product takes: The built-in database backup covers MySQL, and so does mysqldump. Orders, candles, the order book, the trade tape and resting stop orders have no backup path in the product — you own those snapshots.
The four licensed chains are separate purchases: Solana, Tron, Monero and TON each need their own addon licence and their service module installed. Every chain, licensed or not, ships off until you configure it.
Custom chains are EVM only: The panel adds any EVM-compatible chain from data alone. Anything that is not EVM-compatible needs a blockchain addon, and there are four.
No price feed, no imported history: Every candle, ticker and print comes from a fill on your own book. A new pair shows nothing until somebody trades it; quoting from day one is the separate AI Market Maker product, which has to run in the same process as the engine.
Lose the vault passphrase and every key is unreadable: The encrypted blob in the database is the only copy of every private key on the install. There is no recovery, no partial recovery and no support workaround — and a database backup without the .env that decrypts it is not a backup.
The admin panel cannot cancel a customer's order: The order desk is read-only by construction. Cancellation is the customer's own action, or a consequence of deleting the market. There is also no screen anywhere that lists resting stop orders.
Chain settings are read at boot: There is no configuration reload for a built-in chain: change a chain variable and the backend has to restart. Operator-defined EVM chains are the exception and take effect immediately.
Revenue accrues in the quote asset: There is no conversion. A BTC/USDT market pays you in USDT and a MYTOKEN/BTC market pays you in BTC, each into its own wallet on your account.