TON Blockchain
Toncoin custody on The Open Network for Bicrypto's Ecosystem addon — per-user wallet contracts, Toncenter-backed deposit detection, and on-chain withdrawals signed from the user's own address.
The TON Blockchain addon extends Ecosystem's custody layer to The Open Network. Once it is licensed, enabled and configured, an ECO wallet holding TON gets a real TON account address, deposits to that address are detected and credited, and withdrawals are signed and broadcast by this install.
It is one of four licensed non-EVM chains — the others are Solana, Tron and Monero — and it follows the same two-gate activation model as all of them: a licence file on disk, and a row toggled on in the database.
What it requires
TON is a chain service that plugs into Ecosystem. It has no admin screens of its own, no user-facing pages of its own, and no wallet type of its own. Everything it does is done through Ecosystem's existing deposit, withdrawal and master wallet machinery.
| Requirement | Why | If it is missing |
|---|---|---|
| Bicrypto core | The platform itself | Nothing runs |
| Ecosystem addon | ECO wallets, deposit monitors, the withdrawal queue, the vault | TON has nothing to plug into |
| An activated TON licence | lic/55715370.lic must exist |
Enabling the chain returns 403; the service reports "not active" |
| A Toncenter-compatible JSON-RPC endpoint | Every balance read, deposit poll and withdrawal | Deposits are never seen, withdrawals never confirm |
| The unlocked Ecosystem vault | Decrypting the key material that signs | Address generation and withdrawal signing both fail |
You do not need ScyllaDB for custody alone. Scylla is Ecosystem's order book store — it matters only if you also intend to run a TON market. Deposits, balances and withdrawals work without it.
What it actually supports
The service handles native Toncoin only.
Deposits are recorded as NATIVE, the deposit parser reads the incoming
message's value in nanotons, and the withdrawal path calls a plain wallet
transfer denominated in nanotons. There is no jetton wallet derivation, no
jetton master address on the token record, and no jetton transfer parsing
anywhere in the deposit or withdrawal code. The seeded token list carries
exactly one TON entry, and it is Toncoin.
Nothing stops you creating an ecosystem_token row with chain = TON and a
PERMIT or NO_PERMIT contract type — and if you do, address generation falls
through to the EVM derivation path. Every user asking for that token gets an
Ethereum-style 0x… address written into the TON slot of their wallet address
map.
That address is presented as a TON deposit address. It is not one. Anything sent
to it is unrecoverable, and no monitor will ever look at it. Keep TON to the
single NATIVE Toncoin row.
How TON differs from the chains you already run
Four differences change day-to-day operation, and each has its own page.
Addresses come from a wallet contract, not a key. A TON address is derived from the public key and the wallet contract code. The bundled TonWeb version creates v3R1 wallets, so a mnemonic exported from this platform and imported into a modern mobile wallet shows a different address with a zero balance. See Deposit addresses and detection.
There is no memo or comment to collect. Every user gets their own account address, so deposits are attributed by destination address alone. Users sending from an exchange that insists on a memo field should leave it blank — the platform never reads it.
Withdrawals are signed by the user's own address, not the master wallet. Unlike EVM tokens, no gas payer is involved. The network fee comes out of the same TON balance being withdrawn, which is why a "withdraw everything" attempt fails. See Withdrawals and fees.
There is no explorer integration. The admin overview explicitly marks TON as having no explorer API, and the generic chain transaction fetcher throws for TON — history comes from the Toncenter RPC itself, via the chain service.
Rate limits are the operational risk
Anonymous Toncenter is limited to roughly one request per second. Everything about TON on this platform is shaped by that number: the deposit poll runs once a minute, the background scanner is capped at half a request per second for TON specifically, and the withdrawal confirmation loop makes up to ten polls at ten second intervals.
Run without an API key and those loops start losing races. The
withdrawal confirmation loop failing is the expensive one
— it can mark a withdrawal FAILED and refund the user after the coins have
already left the chain.
Where to start
The two gates, the four environment variables, the master wallet and the token row — in the order that avoids a half-configured chain.
Wallet versions, the bounceable flag, why there is no memo, and exactly when a deposit becomes a balance.
What the user pays, what the network takes, and the confirmation window that decides whether a broadcast withdrawal is recorded as one.
Every variable and token field the runtime reads, and the ones it does not.
Chain inactive, deposits not crediting, "Invalid address format", withdrawals stuck in PROCESSING.
Related Ecosystem reading
This addon inherits the whole custody model from Ecosystem. Read these once before you go live rather than after:
- Master wallets and the vault — the passphrase trade-off, and why losing the vault key is terminal.
- Deposit wallets and custody — the detection paths, the crediting job and the withdrawal queue that TON plugs into.
- Supported blockchains — the licensed non-EVM family and the requirements console.