Instant delivery

Lifetime updates

1 domain license

Blockchainv1.0.0

TON Blockchain Addon

Name: TON Blockchain Addon
Brand: MashDiv
SKU: ton
Price: 89.00 USD
Availability: InStock

Give every Ecosystem wallet its own TON account — deposits credited, withdrawals signed on your own server.

4.8011 sales

$89$99Save 10%

You'll also need Bicrypto and Ecosystem for Bicrypto

On its own, TON Blockchain Addon won't work — it only runs if you already own these products. Open the Requirements tab to see exactly what you need and add them to your order.

See it working Live demo Documentation View on CodeCanyon

A real TON account address per Ecosystem wallet, with the key on your server
Deposits credited on detection — TON settles with no confirmation depth
Attribution by destination address, so there is no memo or tag to support
Withdrawals signed by the customer's own address — no gas tank to keep funded
The first withdrawal deploys the wallet contract and sends in one message
Non-bounceable UQ addresses, so a first deposit lands instead of bouncing
A background scanner finds deposits made after the customer closes the tab
One Toncenter-compatible endpoint — no node, no daemon, nothing to host
Swap in a paid plan or your own gateway by changing one line of .env
A live admin probe that reads the masterchain and grades readiness per flow
Per-token withdrawal fee, precision and limits from the Ecosystem console
Two gates before it can move money: a licence file and the chain row

Inside TON Blockchain

Toncoin custody, signed on your own server

Every Ecosystem wallet holding TON gets a real account on The Open Network — deposits detected and credited without anybody watching, withdrawals signed and broadcast by your install, and the key that spends them encrypted in your vault.

In detail

This extends Ecosystem custody to The Open Network. Every wallet holding Toncoin gets its own TON account address, the coins there belong to that customer, and the key that spends them sits on your server encrypted under your vault. Deposits are found and credited with nobody watching; withdrawals are signed and broadcast by the install itself.

How it works

The first time a customer opens the TON deposit page the platform generates a 24-word TON mnemonic, derives an Ed25519 key pair and builds a v3R1 wallet contract from it. On TON an address is the hash of a contract's initial state, so it exists at once — but a wallet contract is deployed by sending, never by receiving. A fresh address reads as uninitialised on an explorer even while it holds a balance, and the customer's first withdrawal deploys the wallet and sends in one signed message. Deposits are attributed by destination address alone: there is no memo or tag to collect.

What you configure

Setting	What it decides
`TON_NETWORK`	mainnet or testnet — anything but `testnet` is mainnet
RPC URL	the one endpoint every poll, read and broadcast goes through
API key	sent as `X-API-Key`; anonymous is about one request a second
Token fee	a percentage and a minimum, in TON, added to the debit
Token precision	decimal places a withdrawal may carry
Scan rate and TTL	how hard the background scanner works your endpoint

What operators control

The chain moves nothing until two gates pass: the licence file on disk, and the chain row switched on under Admin, Ecosystem, Blockchains. A live requirements probe reads the masterchain through your own endpoint and grades deposit and withdrawal readiness separately, naming every variable it could not find. The Toncoin token row carries the withdrawal fee, precision and per-transaction limits, and switches off without disabling the chain. Session monitors poll a watched address every 60 seconds; a background scanner keeps looking for 72 hours after the tab closes.

Native Toncoin only. There is no jetton support in the deposit or withdrawal path, and a TON token row created with a PERMIT or NO_PERMIT contract type falls through to the EVM derivation and hands your customer an Ethereum-style address as a TON deposit address. Keep TON to the one NATIVE Toncoin row.

Requires Bicrypto and the Ecosystem addon, plus an activated TON licence and an unlocked vault. Configure a Toncenter API key before you take real money: withdrawal confirmation polls ten times at ten-second intervals, and a throttled endpoint that starves it fails the row and refunds the customer while the coins are already on chain.

An address is a contract, and it deploys itself on the way out

On TON an address is the hash of a wallet contract's initial state, not of a key. Every customer gets their own v3R1 contract and the address works the moment it is generated — but a wallet contract is deployed by sending, never by receiving, so a fresh address reads as uninitialised on an explorer even while it holds a balance. The customer's first withdrawal deploys the wallet and sends in one signed message. That is also why the platform hands out the non-bounceable UQ form: a bounceable transfer to an undeployed account is returned to the sender.

The wallet version is part of the address. The same 24 words imported into a phone wallet that defaults to v4R2 or W5 shows a different account with a zero balance — any manual recovery has to select v3R1 explicitly.

The address stays watched after the customer closes the page

While the deposit page is open the platform polls that TON address every 60 seconds, reads its ten most recent transactions and pushes the credit straight back to the page. Closing the tab does not stop it: the same poll runs for another ten minutes, and a background scanner registered when the page opened keeps re-checking the address roughly every two minutes, for 72 hours from the last time the customer opened the page. Once that window lapses nothing polls the address — TON has no socket to subscribe to and there is no node bundled to push events at you. Reopening the deposit page re-registers the address and the first poll reads the same ten transactions, so a deposit that landed while nobody was watching is credited then, and crediting is de-duplicated on the transaction hash so re-reading history cannot pay twice.

The background scanner needs Redis and can be switched off install-wide; with it off, only a live deposit-page session — the open page and its ten-minute grace — finds a deposit. Its sweep is paced per chain, not per address: half an address scan a second across every watched TON address, so a large working set stretches the two-minute cadence instead of exceeding the endpoint's rate limit.

Withdrawals are signed by the address itself, then hunted down

No master wallet and no fee payer are involved. The customer's own key signs, and the network fee comes out of the same balance being sent, which is why a TON address can never send quite all of it — and why there is no gas tank for you to keep topped up. TON's broadcast returns no transaction hash, so the platform stamps every transfer with a unique comment and then polls its own address, up to ten attempts ten seconds apart, until it finds the outgoing message it wrote.

If all ten polls miss, the row is marked FAILED and the queue refunds the customer while the coins are already on chain. A Toncenter API key is what keeps that from happening: the anonymous endpoint, at about one request a second for the whole install, is exactly the condition that starves the loop.

One HTTP endpoint is the whole infrastructure

There is no node to host and no daemon to babysit. Deposit polling, balance reads, signing and confirmation all go through a single Toncenter-compatible JSON-RPC URL you set yourself, and the integration touches only five methods — so a paid plan, another hosted provider or your own gateway in front of your own node substitutes by changing one line. The admin console runs a live read-only probe against whatever you point it at and grades deposit and withdrawal readiness separately.

Native Toncoin only. There is no jetton path anywhere in the deposit or withdrawal code, and a TON token row created with a PERMIT or NO_PERMIT contract type falls through to the EVM derivation and issues an Ethereum-style address as a TON deposit address. Keep TON to the one NATIVE Toncoin row.

wallet contract per customer: v3R1
JSON-RPC methods used: 5
confirmation polls, 10 s apart: 10
gates before it moves money: 2

Everything included

67 capabilities, in 5 areas

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

Addresses and key custody

Every customer gets their own TON account, and you hold its key.

A TON account of its own per Ecosystem wallet, created on the first visit to the deposit page
24-word TON mnemonic, generated and validated by TON's own scheme
Ed25519 key pair, and a v3R1 wallet contract built from the public key
An address that is the hash of that contract's initial state, so it works before anything is deployed
Non-bounceable UQ form issued, so a first deposit lands instead of being returned
Mnemonic, public key and secret key sealed as one AES-256-GCM blob under the Ecosystem vault key
One key row per wallet, keyed on wallet, currency and chain
The address and the network it was generated under written into the wallet's address map
No export path: no screen, endpoint or file ever reveals key material
A TON master wallet of your own, created the same way, with its balance read live
No shared custodial deposit contract — TON is excluded from custodial deployment by name

Deposit detection

Two independent ways a deposit is found, and one way to restart both.

A session monitor polling the customer's address every 60 seconds while the deposit page is open, and for ten minutes after it closes
The ten most recent transactions read per poll, against archival history
A background scanner that keeps re-checking each address for 72 hours from the last deposit-page visit
A TON-specific chain-wide budget in the scanner's token bucket, sized for an anonymous endpoint
Reopening the deposit page restarts the monitor, re-registers the address and re-checks recent history
Attribution by destination address alone — no memo, tag or comment to collect or support
Expected and actual destination compared in raw form, so address format cannot cause a mismatch
Successful transfers credited as a NATIVE deposit, with the value converted from nanotons
De-duplication on the transaction hash in the database, plus a 30-minute in-process memory
Credited at detection — TON deposits are not held for a confirmation count
The credit pushed to the open deposit page over Ecosystem's deposit socket
A poll interval that doubles while the endpoint errors, to a sixteen-minute ceiling
A monitor that stops itself after ten consecutive errors and names the address in the log

Withdrawals and signing

Signed on your server by the customer's own address, then hunted down and recorded.

Withdrawal two-factor policy checked before any balance is touched
A character allow-list on the destination, applied before any TON library sees the string
Address parsed by the TON library: 48-character user-friendly, or the raw workchain:hex form
A destination belonging to another customer here settled as an internal transfer, with no on-chain send
A withdrawal to the customer's own deposit address refused
Decimal places checked against the token's precision
A platform fee of percentage-or-minimum, in TON, added to the debit
A row-locked debit and the PENDING transaction row written in one database transaction
An in-memory queue with a five-second cooldown between withdrawals on the same chain
Signed by the customer's own address: no master wallet, no gas payer, no gas tank to keep topped up
The wallet rebuilt from the stored keys and the stored address, so the contract version can never drift
The sequence number read from the contract — a first send deploys the wallet and transfers in one message
A live balance read against the sending address before anything is broadcast
A unique TON_WITHDRAWAL comment stamped on every transfer, so the platform can find its own transaction
A confirmation hunt of up to ten polls, ten seconds apart, over the sender's last five transactions
The row completed with the on-chain hash, or failed with the reason written onto it
PENDING rows re-enqueued at boot, plus a watchdog for rows the in-memory queue outlived
Stale rows held for manual review rather than re-broadcast, and a row that already carries a hash never failed or refunded
A maximum-withdrawable endpoint that quotes the platform fee

The endpoint you point it at

One HTTP URL is the whole infrastructure.

One Toncenter-compatible v2 JSON-RPC URL behind deposits, balances, signing and confirmation
Five methods in total: transactions, address balance, a get-method call, a broadcast and a masterchain read
Mainnet and testnet URL and key pairs, selected by one variable
The API key sent as an X-API-Key header on every request
A paid plan, another hosted provider or your own gateway substituted by changing the URL
No node to host, no daemon to babysit and no socket to keep open
Scan rate, scan interval and working-set lifetime all settable
Background scanning switchable off install-wide

Activation, diagnostics and the dials you set

What has to be true before it moves money, and the console that tells you.

Two gates before it can move money: the licence file on disk and the chain row switched on
Enabling refused with a 403 while the licence is missing; disabling is never gated
A licence result cached for five minutes, and the active flag re-checked while the chain is off
A missing service module degrading to a 503 instead of crashing the platform
A per-chain requirements report naming every variable read, whether it is set, and what needs it
A live read-only probe reporting the masterchain sequence number and its latency
HTTP 401 (wrong key) told apart from HTTP 429 (rate limited)
An anonymous endpoint labelled as anonymous, and warned about by name
Five prerequisites graded: vault, service installed, licence, master wallet, active tokens
Deposits and Withdrawals graded as separate readiness rows
A per-chain screen carrying licence activation, the current version and one-click install or update
Chain status and per-asset coverage on the Ecosystem overview
One seeded Toncoin token row, off until you enable it
Withdrawal fee percentage and minimum, precision, and per-transaction limits on that row
The token switchable off without disabling the chain
Transaction history for a TON address read straight from your own endpoint

Licence: Addon licence, activated in the admin panel against your purchase code. Product id 55715370; activation is machine-bound, so a server move needs reactivating.
Requires: Bicrypto core and the Ecosystem addon, each licensed separately. TON has no wallets, no queue and no vault of its own — it plugs into Ecosystem's, and the vault must be unlocked before an address can be created or a withdrawal signed.
Runs on: Your own server, inside the Bicrypto tree. One chain-service file behind a guarded import: no separate installer, no service to run, no hosted tier.
Network access: One Toncenter-compatible v2 JSON-RPC URL, and in practice an API key. Five methods are used: getTransactions, getAddressBalance, runGetMethod, sendBoc and getMasterchainInfo — the last by the admin probe only.
Data stores: MySQL for the wallet rows, the encrypted key blobs and the transaction ledger; Redis for the background scanner's working set. ScyllaDB is not needed for custody — only if you also list a TON market.
Processes: None of its own. The service is constructed inside both the API process and the cron process, so an endpoint change means restarting both.
Admin surface: No screens of its own. Administered from six Ecosystem screens: the overview, blockchain requirements, the per-chain detail, master wallets, the token list and the token editor.
Access control: Ecosystem's own permission keys — 13 across blockchain, master wallet and token — with the licence check running after them.
Configuration: Five TON variables (network, two RPC URLs, two API keys) plus the scanner's per-chain rate, interval, lifetime and on-off switch. None of them ship in .env.example.
What customers see: The ordinary deposit, withdraw and history screens, with Toncoin on their Eco wallet. There is no TON page and no TON setting on the customer's side.
Native Toncoin only: There is no jetton derivation, no jetton master field and no jetton parsing anywhere in the deposit or withdrawal path, and the seeded token list carries exactly one TON row. A TON token row created with any contract type other than NATIVE never produces a working TON deposit address — keep TON to the one Toncoin row.
The API key is optional in the code and required in practice: Anonymous Toncenter is about one request a second for the whole install. That is the condition that starves the ten-poll confirmation loop, and a starved loop fails the row and refunds the customer while the coins are already on chain.
No explorer integration, and no confirmation counter: The chain registry marks TON as having no explorer API. History is read from your own endpoint instead, and a TON deposit is credited on detection rather than counted up to a depth.
Polling, not push: There is no socket to the chain and no node bundled. A deposit is found on the next poll of that address — every 60 seconds while the page is open, for ten minutes after it closes, then roughly every two minutes in the background until 72 hours after the customer's last visit. Past that nothing polls it at all, until they open the deposit page again and the first poll re-reads recent history.
A ledger balance is not an address balance: A customer who bought TON on an Ecosystem market holds nothing at their TON address. That withdrawal fails on the balance check — and that path does not refund: the debit and the platform fee both stand until you reverse them by hand.
Turning the chain off needs a restart: Turning it on is picked up within one poll. Once the service has seen TON as active it never re-reads the row, so deposits, balance reads and withdrawal signing keep running until both processes restart.
One customer's key is one row: There is no HD tree and no master seed covering the estate: every address carries its own mnemonic, and the vault key is the only thing that opens any of them. Losing the vault key — or one key row in a restore — makes those coins unspendable by anybody, including you.
Custody, not swaps: This licence covers Ecosystem custody for Toncoin. The Swap addon's TON support is a separate product with its own endpoint and key, and is not gated on this licence.