برنامج المنصة 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:
- Unique address per user — No comment needed; the receiving address identifies the user. This is the default Codono approach.
- 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
| Metric | Value |
|---|---|
| Block time | ~5 seconds (shardchain blocks) |
| Finality | Fast; typically a few blocks |
| Recommended confirmations | 3–5 for standard deposits |
| Gas token | TON (Toncoin) |
| Token standard | Jetton (TEP-74) |
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
| Aspect | ERC-20 (EVM) | Jetton (TON) |
|---|---|---|
| Balance storage | One contract, internal mapping | Separate wallet contract per holder |
| Balance query | Call the token contract | Resolve the user’s Jetton wallet address first |
| Transfer gas | Paid in ETH/native coin by sender | Paid in TON; exchange may need to top up deposit addresses |
| Metadata | Usually on-chain (name/symbol/decimals) | TEP-64: on-chain or off-chain JSON |
| Addressing | Single hex address format | Bounceable (EQ…) vs non-bounceable (UQ…) — use non-bounceable for deposits |
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:
- Configure Blockgum credentials or connect a self-hosted TON liteserver
- Generate the master wallet and secure the seed backup
- Add Toncoin and initial Jetton listings via the admin panel
- Configure confirmation thresholds, sweep settings, and withdrawal limits
- Test end-to-end deposit and withdrawal flows
- Go live on TON mainnet
Contact our team for TON integration assistance and configuration guidance.