TON Integration for Crypto Exchanges — Toncoin and Jettons

TON Integration Overview

TON (The Open Network) is a layer-1 blockchain with deep integration into the Telegram messenger ecosystem. With Telegram’s massive global user base and the growing adoption of TON-based mini-apps and wallets, TON has emerged as a blockchain with genuine organic demand — not just speculative trading interest.

Codono’s crypto exchange software provides complete TON support, enabling you to list Toncoin and Jetton tokens and serve users coming from the Telegram ecosystem.

Supported Assets

Toncoin (TON)

• The native coin of The Open Network
• Full deposit and withdrawal support
• Used as gas for all TON transactions and Jetton transfers
• Available as a trading pair base or quote currency

Jettons

• TON’s fungible token standard (functionally analogous to ERC-20)
• Stablecoins issued on TON (USDT on TON, jUSDC, etc.)
• Project tokens and utility tokens from TON-native dApps
• Any Jetton contract can be listed via its master contract address

How TON Differs from EVM Chains — Key Technical Points

TON’s architecture diverges significantly from Ethereum-family chains. Understanding these differences matters for exchange operations:

Jetton Wallet Contracts

On EVM chains, a single ERC-20 contract holds all holder balances in an on-chain mapping. On TON, each Jetton creates a separate “Jetton wallet” smart contract for every address that holds that token. When your exchange queries a user’s Jetton balance, it must resolve the user’s Jetton wallet address first, then query that contract. Codono handles this automatically — but it is worth knowing when troubleshooting discrepancies.

Comment/Memo Fields

TON transactions support an optional comment (text message) attached to the transfer. This is commonly used in two deposit patterns:

1. Unique address per user — No comment needed; the receiving address identifies the user. This is the default Codono approach.
2. Shared deposit address with memo — A single exchange address receives all deposits, and the comment field contains a user identifier. This reduces key management complexity but requires strict enforcement of the comment on the user side.

For most exchange deployments, unique address per user is the cleaner model.

Address Format

TON addresses are represented in a URL-friendly base64 encoding (e.g., EQ… or UQ… formats). The EQ prefix denotes a bounceable address; UQ denotes a non-bounceable address. Exchanges should always use non-bounceable addresses for user deposit addresses to prevent funds from being returned on failed smart contract calls.

Wallet Architecture

User Deposit Addresses

The platform generates a unique TON address for each user. Incoming Toncoin and Jetton transfers to these addresses are monitored by the wallet layer. Once a deposit reaches the configured confirmation count, the exchange balance is credited.

Sweep and Gas Management

Toncoin is required to pay gas for Jetton transfers. When sweeping Jetton balances from user deposit addresses to the hot wallet, the platform first ensures the deposit address has sufficient TON for the outbound Jetton transfer. This “gas top-up” step is handled automatically, but operators should maintain an adequate TON reserve in the sweep wallet.

Hot and Cold Wallet Split

Large TON and Jetton holdings should be kept in cold wallet storage with manual authorization for cold-to-hot transfers. The admin panel supports configurable thresholds for automatic vs. manual withdrawal approval.

Integration Methods

Blockgum Integration

Blockgum provides managed TON infrastructure:

• Wallet address generation and management
• Real-time deposit monitoring for TON and Jettons
• Balance synchronization with confirmation tracking
• Withdrawal processing with fee estimation
• Jetton wallet resolution and querying
• Webhook callbacks for confirmed deposits and withdrawals

Blockgum abstracts the operational complexity of TON node management and Jetton wallet resolution.

Direct TON Node Integration

For advanced deployments requiring full control:

• Connect to a self-hosted TON node (liteserver or full node)
• Complete visibility into transaction data
• No third-party API dependencies
• Suitable for high-volume operations with custom monitoring requirements

Running Your Own TON Node — Infrastructure Guide

Managed infrastructure (Blockgum) covers most exchange deployments, but high-volume operators may want direct node access for latency, rate-limit independence, or data control. TON’s node landscape differs from EVM chains, so here’s what self-hosting involves.

Liteserver vs. Full Node vs. Archive

• Liteserver — the standard exchange integration point. Serves current state, account data, and transaction submission with modest hardware. Codono’s direct-integration mode connects to a liteserver.
• Full node — validates the chain and serves liteserver clients. This is what you actually run when “self-hosting a TON node.”
• Archive node — a full node configured to retain complete history. Needed only if you require historical transaction lookup beyond recent blocks (audit tooling, deep support queries); storage requirements are substantially higher.

Hardware Baseline

TON’s published full-node recommendations call for a modern multi-core CPU, 16 GB+ RAM, and fast NVMe SSD storage with headroom for chain growth — check the current TON documentation before provisioning, as requirements rise with chain state. HDDs are not suitable; TON’s sharded state access is I/O-intensive. Validators are a different class entirely (higher CPU/RAM and strict uptime requirements) and are not needed for exchange operations — a full node serving liteserver queries is the right target.

Sync and Bootstrap

A fresh node syncs from network snapshots and catches up on recent blocks — expect hours rather than days on adequate hardware and bandwidth, faster than most EVM archive syncs. Plan bootstrap before you need the node in production, and keep it permanently online: deposit monitoring depends on the node being current.

Operational Notes

• TON nodes communicate over ADNL (TON’s own network protocol) — ensure outbound connectivity isn’t blocked by a restrictive firewall policy
• Monitor sync status and expose health checks to your alerting; a silently-lagging node means missed deposit detection
• Keep a managed fallback (e.g., Blockgum or a public liteserver config) so node maintenance never halts withdrawals
• Track TON software releases — the network upgrades regularly, and outdated nodes can fall out of consensus

Managed vs. Self-Hosted

Start on managed infrastructure. Move to your own full node when third-party rate limits, latency requirements, or data-control policies justify the operational overhead — and keep the managed endpoint configured as fallback even then.

Performance Characteristics

TON uses a sharded architecture designed for throughput at scale. For exchange purposes, the relevant characteristic is that transaction confirmation is fast — deposits are typically ready to credit within 30–60 seconds after broadcast.

Why TON Matters for Exchange Operators

Telegram User Funnel

TON Space (the built-in Telegram wallet) and third-party TON wallets like Tonkeeper make it easy for Telegram’s users to hold and transfer TON and Jettons. An exchange that supports TON can market directly within Telegram communities, TON-based mini-apps, and the growing ecosystem of Telegram-native projects.

Stablecoin Demand

USDT issued on TON has seen growing adoption as an alternative to USDT-TRC20 for users in regions where Telegram is popular. Listing USDT on TON gives your exchange access to this transfer demand.

Token Launch Activity

TON has become an active platform for new project launches, from GameFi to DeFi to social applications. Early listing of relevant Jettons can attract users before those projects migrate to larger venues.

Which Exchanges Benefit Most from TON Support

• Exchanges targeting CIS, Southeast Asian, and Middle Eastern markets — These regions have high Telegram penetration and growing TON user bases.
• Community-focused exchanges — TON’s Telegram roots make it popular with crypto communities that organize on Telegram.
• Multi-chain platforms — Adding TON alongside EVM chains differentiates your listing offer.

Listing Jetton Tokens — Operator Guide

Jettons are TON’s fungible token standard (defined in TEP-74), and listing them is where most TON-related operator questions land. The process is simpler than it looks, but a few TON-specific details matter.

Finding the Jetton Master Address

Every Jetton has a single “Jetton master” (minter) contract whose address is the token’s canonical identifier. You will see it referenced in TON explorers (TONScan, Tonviewer) and in the project’s official channels. Always take the master address from the project’s official website or verified explorer entry — TON has no central token registry, and lookalike Jettons with identical names and symbols are common.

Verifying Metadata Before Listing

Jetton metadata (name, symbol, decimals, logo) is published under TEP-64, either on-chain or via a linked JSON file. Before listing, verify:

• Decimals — most Jettons use 9 (like Toncoin) or 6 (stablecoins); a wrong decimals setting misprices every order
• Symbol and name — compare against the project’s official announcement, not just the on-chain field
• Total supply and mintability — a master contract that can still mint changes your risk assessment
• Admin controls — some Jettons allow the issuer to freeze or upgrade wallet contracts; decide whether that fits your listing policy

Adding the Jetton in the Admin Panel

Once verified, add the Jetton by pasting its master contract address in the admin panel, then confirm the decimals and symbol against your own verification before enabling the market. From there it behaves like any other listed asset: set confirmation thresholds, withdrawal minimums, and fee tiers per token.

Jetton vs ERC-20 — What Changes for Operators

The practical takeaway: listing diligence on TON is about verifying the master contract, and operations are about managing TON gas reserves for Jetton sweeps. Everything else — deposits, withdrawals, trading pairs — works the same as on any other supported chain.

Admin Capabilities

• Enable or disable TON and individual Jetton trading pairs
• Add Jettons by master contract address with automatic metadata fetch
• Configure deposit confirmation thresholds per asset
• Set withdrawal limits, minimum amounts, and approval workflows
• Monitor TON gas balance in the sweep wallet with low-balance alerts
• View transaction history with TON explorer deep-links

Getting Started

TON support is included in the Codono exchange package. Typical setup steps:

1. Configure Blockgum credentials or connect a self-hosted TON liteserver
2. Generate the master wallet and secure the seed backup
3. Add Toncoin and initial Jetton listings via the admin panel
4. Configure confirmation thresholds, sweep settings, and withdrawal limits
5. Test end-to-end deposit and withdrawal flows
6. Go live on TON mainnet

Contact our team for TON integration assistance and configuration guidance.