A convert on Ecosystem balances, and the coins that cannot be converted there
Why an Ecosystem convert is limited to single-chain pooled currencies, what a user sees for every other coin, how the result is withdrawn, and what happens when you enable a second chain for a currency Convert has traded.
An Ecosystem convert looks exactly like a Spot one: the same widget, with the Ecosystem toggle selected, the same preview, the same held price. What differs is which coins can take part, and the reason is where the coins are.
A converted balance has no chain
When a user converts ECO BTC into ECO USDT, no coin moves on any chain. Four ledger entries move: the user's BTC to the house, the house's USDT to the user. The user now holds a USDT balance that is not attached to a chain; they choose a chain only when they withdraw, and the withdrawal is paid from whatever that chain holds.
That is safe for exactly one kind of currency: one with a single enabled withdrawal chain, whose coins sit in a pool any address on that chain can pay from. Then the pool that pays the user's withdrawal is the pool the seller's coins went into, and in aggregate everything stays backed. The pooled families are:
| Family | Examples |
|---|---|
| UTXO coins | BTC, LTC, DOGE, DASH |
| EVM tokens | USDT or USDC enabled on one EVM chain only |
| TRC-20 tokens | USDT enabled on TRON only |
| TRX | native TRON |
The rule is enforced in code, on both sides of the pair, whatever the asset row in the console says. An operator can switch an asset off that the code allows; ticking one on that the code refuses produces a refusal that says why, not a convert.
What a user sees for everything else
| The coin is | As the currency received | As the currency given |
|---|---|---|
| Native EVM (ETH, BNB, POL…), SOL, an SPL token, or enabled on more than one chain | Convert to ETH is only available as Send, with a Send it to an address instead link when Convert & Send is open for it, and Sending to an address is not offered on this platform. when it is not | Convert on Ecosystem is not available for ETH |
| TON, XMR, or anything the platform cannot sign for | Convert on Ecosystem is not available for XMR | the same |
| Not enabled on any chain | the same | the same |
The reasons, briefly:
- A native coin or an SPL token can only be paid out by the address that holds it. A user credited ETH by a ledger entry would ask to withdraw it, and their own deposit address, which holds nothing, would be asked to pay. Convert & Send solves this by paying from the house's own address instead, on the chain the user picks at quote time.
- A multi-chain token (USDT enabled on Ethereum, BSC, TRON and Solana) converted into a balance could be withdrawn on whichever chain the house holds nothing, paid from other customers' coins there.
- As the currency given, the house may only buy what it can collect. A native coin it bought would stay on the seller's own address and be spent by the seller's next withdrawal.
The gates that close the whole tab
Every one of these must hold, or the Ecosystem side refuses with Convert on Ecosystem balances is not available right now and the log says which:
- the Ecosystem extension is enabled;
- it is licensed;
- the ecosystem withdrawal queue has not been handed to the Rust backend.
When one of the gates above is shut, or no Ecosystem asset is listed (none passes the rules above and none is a coin offered only through Send), the user's asset list carries no Ecosystem row. The page then shows no Spot/Ecosystem toggle at all, and the widget shows Spot balances only.
Withdrawing the result
A converted pooled balance is an ordinary Ecosystem balance. The user withdraws it through the normal Ecosystem withdrawal, on its one chain, with the normal fee and two-factor rules (Ecosystem withdrawals have no manual-approval step).
Or they can do both at once. Choosing An address under To on an Ecosystem convert into a pooled coin gives Convert and withdraw: the convert, then a standard withdrawal request of the result, in one click. Every precondition of that withdrawal (the address, the token's precision, the withdrawal fee, the withdrawal policy) is dry-run before the convert, so a refusal comes before any money moves. See Convert & Send and convert-and-withdraw.
Enabling a second chain later
Suppose Convert has traded ECO USDT while USDT was enabled on TRON only, and you now enable USDT on BSC. Balances Convert credited without a chain could then be withdrawn from the BSC pool, which holds other customers' coins.
So every admin endpoint that enables or adds an ecosystem token (the status
switches, the edit, the create and the import) refuses a change that would give
a currency another withdrawal chain, with a 409 naming the currency, as long as
Convert has touched it on Ecosystem balances (any convert order with it on an
ECO side, or a house ECO balance of it). The token screen then asks you to
confirm (Close Instant Convert for USDT?). Enable and close Convert sends
acknowledgeConvertClosure, enables the chain, and in the same transaction
switches off every Ecosystem asset row of that currency in Convert. Converts
in it stop; balances already converted stay where they are and withdraw
normally.
Restoring a deleted token counts too: a token that was enabled when it was
deleted comes back enabled, which would add its chain. So when a restore would
give such a currency a second chain, the token comes back disabled and the
answer says so. Enable it afterwards from the token list, which asks you to
confirm the same way. An API call can instead pass
acknowledgeConvertClosure=true with the restore to bring it back enabled and
close Convert for the currency at once.
Custom EVM chains count too, because turning a custom chain on enables its native coin as an Ecosystem token. Creating an enabled chain whose native currency Convert has touched (an EVM chain whose gas coin is BTC or ETH, say), enabling such a chain, or changing an enabled chain's native currency to such a currency is refused the same way, and the custom chain screens ask you to confirm. Confirming closes Convert for the currency first, then saves the chain and enables its native token. A chain the server would not save (an RPC URL it refuses, a chain ID too large to store, a value too long for its field) is refused before you are asked, so nothing is closed for it. Disabling or deleting a chain is never refused for this.
The server also writes those native tokens itself, for every enabled custom chain, each time it starts and each time a chain is saved. Nothing can be confirmed at that point, so a native token that would give such a currency another withdrawal chain is created or kept disabled, and the log says so: Native token BTC on BOTANIX kept disabled: Instant Convert has BTC orders on Ecosystem balances, and enabling it would give BTC 2 withdrawal chains. To enable it, enable it from the token list, which asks to confirm closing Instant Convert for BTC on Ecosystem balances. Saving such a chain says the same. Enable the token from the token list, which asks you to confirm the same way.
Pricing without an exchange provider
An Ecosystem convert does not need an exchange provider. With none configured it
is priced from the keyless order books of two public venues
(convertNoProviderVenues: Automatic (Binance and OKX), or
Two venues I choose on the settings page): the route is walked
on both, the rate worse for the house is quoted, the two must agree within the
reference deviation, and the spread is never below
convertNoProviderMinSpreadBps (default 100 bps). Nothing can be hedged in that
mode, so every Ecosystem convert counts against the unhedged exposure cap. See
Pricing.