MMashDiv

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.

5 min readUpdated 1 October 2026convert, ecosystem, eco, pooled, withdraw, eligibility

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.