Skip to main content

FAQ

This section answers the most popular questions about the TON Blockchain.

Overview​

Could you share a brief overview of TON?​

What are some of the main similarities and differences to EVM blockchains?​

Does TON have a test environment?​

TON and L2​

Why are workchains better than L1 → L2?​

Workchains in TON offer several advantages over traditional L1 and L2 layer architecture:

  1. Instantaneous transactions

One of blockchain's key advantages is the instantaneous processing of transactions. In traditional L2 solutions, there can be delays in moving assets between layers. WorkChains eliminate this problem by providing seamless and instantaneous transactions across the network. This is especially important for applications requiring high speed and low latency.

  1. Cross-shard activity

WorkChains support cross-shard activity, allowing users to interact between different ShardChains or WorkChains within the same network. In current L2 solutions, cross-shard operations are complex and often require additional bridges or interoperability solutions. In TON, users can easily exchange tokens or perform other transactions between different ShardChains without complicated procedures.

  1. Scalability

Scalability is a significant challenge for modern blockchain systems. In traditional L2 solutions, scalability is limited by the capacity of the sequencer. If the transactions per second (TPS) on L2 exceed the sequencer's capacity, it can cause problems. In TON, WorkChains solve this problem by dividing a shard when the load exceeds its capacity. This allows the system to scale almost without limits.

Is there a need for L2 on the TON?​

While the TON platform offers highly optimized transaction fees and low latency, some applications may require lower transaction costs or further reduced latency. L2 solutions may be needed to meet specific application requirements in such cases. Thus, the need for L2 on TON could arise.

MEV (Maximum Extractable Value)​

Is front-running possible in TON?​

In the TON Blockchain, deterministic transaction ordering is critical to prevent front-running. Once transactions enter the pool, their order is predetermined and cannot be altered by any participant. This system ensures that no one can manipulate the order of transactions for profit. Unlike blockchains such as Ethereum, where validators can change the order of transactions within a block, creating opportunities for MEV, TON’s architecture eliminates this possibility.

Additionally, TON does not rely on a market-based mechanism to determine transaction fees. Commissions are fixed and do not fluctuate based on transaction priority. This lack of fee variability further reduces the incentive and feasibility of front-running. Due to the combination of fixed fees and deterministic transaction ordering,front-running in TON is not a trivial task.

Block​

What is the RPC method used to retrieve block information?​

Validators produce blocks, and existing blocks can be accessed via liteservers, which are available through lite clients. Additionally, third-party tools like wallets, explorers, and dApps are built on top of lite clients.

To access the core lite client, visit our GitHub repository:

ton-blockchain/tonlib

Here are three popular third-party block explorers:

For more information, refer to our documentation's Explorers in TON section.

Block time​

Block time: 2-5 seconds

info

You can compare TON's on-chain metrics, including block time and time-to-finality, with Solana and Ethereum by reading our analysis at:

Time-to-finality​

Time-to-finality: under 6 seconds

info

Compare TON's on-chain metrics, including block time and time-to-finality, with Solana and Ethereum by reading our analysis at:

Average block size​

max block size param 29
max_block_bytes:2097152
info

For more up-to-date parameters, refer to the Network configs section.

What is the layout of blocks on TON?​

For detailed explanations of each field in the block layout, visit the Block layout.

Transactions​

RPC method to get transactions data​

For details, please refer to the previous answer:

Is the TON transaction asynchronous or synchronous? Can I access documentation that shows how this system works?​

TON Blockchain messages are asynchronous:

  • The sender prepares the transaction body (message BoC) and broadcasts it via the lite client (or a higher-level tool).
  • The lite client returns the status of the broadcast, not the result of executing the transaction.
  • To check the desired result, the sender must monitor the state of the target account (address) or the overall blockchain state.

An explanation of how TON asynchronous messaging works is provided in the context of wallet smart contracts:

Example for wallet contract transfer (low-level):

Can a transaction be determined to be 100% finalized? Is querying the transaction-level data sufficient to obtain this information?​

Short answer: The receiver's account must be checked to ensure a transaction is finalized. For more details on transaction verification, refer to the following examples:

What is the layout of a transaction in TON?​

Detailed explanations of each field in the transaction layout can be found here:

Is transaction batching possible?​

Yes, transaction batching is possible in TON and can be achieved in two ways:

  1. Asynchronous transactions: by sending independent transactions to the network.
  2. Using smart contracts: smart contracts can receive tasks and execute them in batches.

Example of using batch-featured contract (high-load wallet):

Default wallets (v3/v4) also support sending multiple messages (up to 4) in a single transaction.

Standards​

What currency accuracy is available for TON?​

9 digits

info

Mainnet supports a 9-digit accuracy for currencies.

Are there any standardized protocols for minting, burning, and transferring fungible and non-fungible tokens in transactions?​

Non-fungible tokens (NFTs):

Jettons (tokens):

Other standards:

Are there examples of parsing events with Jettons (Tokens) and NFTs?​

On TON, all data is transmitted as BOC (Binary Object Container) messages. Using NFTs in transactions is treated as a regular message, similar to a transaction involving a standard wallet.

Certain indexed APIs allow you to view all messages sent to or from a contract and filter them based on your needs.

To understand this process better, refer to the Payments processing section.

Account Structure​

What is the address format?​

Is it possible to have a named account similar to ENS​

Yes, use TON DNS:

How to distinguish between a normal account and a smart contract?​

How to tell if an address is a token contract?​

To identify a Jetton contract:

  • It must implement the Jetton standard interface (TEP-74)
  • It should respond to:
    • get_wallet_data() — for Jetton wallet contracts
    • get_jetton_data() — for the main Jetton master contract

Are there any special accounts (e.g. accounts owned by the network) that have different rules or methods from the rest?​

Yes. TON includes a special master blockchain called the MasterChain, which holds contracts critical for network operations, including network-wide contracts with network configuration, validator-related contracts, etc.

info

Read more about MasterChain, WorkChains and ShardChains in TON Blockchain overview article: Blockchain of blockchains.

A good example is a smart governance contract, which is a part of MasterChain:

Smart contracts​

Is it possible to detect contract deployment events on TON?​

Everything in TON is a smart contract.

An account address in TON is deterministically derived from its initial state, consisting of the initial code and initial data. For wallets, the initial data typically includes a public key and other parameters. If any part of the initial state changes, the resulting address will also change.

A smart contract can exist in an uninitialized state, meaning it is not yet deployed on the blockchain but may still hold a non-zero balance. The initial state can be submitted to the network later via internal or external messages—these messages can be monitored to detect when a contract is deployed.

To prevent message chains from getting stuck due to missing contracts, TON uses a "bounce" feature. You can read more about it in the following articles:

Does the upgradability of a smart-contract pose a threat to its users?​

The ability to upgrade smart contracts is currently a common practice and widely adopted across modern protocols. Upgradability allows developers to fix bugs, add new features, and enhance security over time.

How to mitigate the risks:

  1. Choose projects with strong reputations and well-known development teams.
  2. Reputable projects typically undergo independent code audits to ensure the smart contract is secure and reliable. Look for multiple completed audits from trusted auditing firms.
  3. An active community and positive user feedback can serve as additional indicators of a project’s trustworthiness.
  4. Review how the project handles updates. The more transparent and decentralized the upgrade process is, the lower the risk for users.

How can users be sure that the contract owner will not change certain conditions via an update?​

The contract must be verified, which means its source code is publicly available for inspection. This allows users to confirm whether any upgrade logic is present. If the contract contains no mechanisms for modification, its behavior and terms are guaranteed to remain unchanged after deployment.

In some cases, upgrade logic may exist, but control over it can be transferred to an "empty" or null address. This effectively removes the ability to make future changes.

Is it possible to redeploy code to an existing address, or must it be deployed as a new contract?​

Yes, updating a contract's code at the same address is possible if the smart contract includes logic—typically through the set_code() instruction.

However, if a contract is not designed to execute set_code() internally or via external code, it is immutable. In this case, the contract's code cannot be changed, and it is impossible to redeploy a different contract to the same address.

Can smart contract be deleted?​

Yes. A smart contract can be deleted in one of two ways:

  • Through storage fee accumulation—if the contract’s balance drops to -1 TON, it will be automatically deleted.
  • By sending a message with mode 160.

Are smart contract addresses case-sensitive?​

Yes, smart contract addresses are case-sensitive because they are encoded using the base64 algorithm. You can learn more about how smart contract addresses work here.

Is the Ton Virtual Machine (TVM) EVM-compatible?​

No, the TON Virtual Machine (TVM) is incompatible with the Ethereum Virtual Machine (EVM). TON uses an entirely different architecture: asynchronous, while Ethereum operates synchronously.

Read more on asynchronous smart contracts.

Can smart contracts be written in Solidity on TON?​

Relatedly, the TON ecosystem doesn't support development using Ethereum's Solidity language.

However, extending Solidity with asynchronous messaging and low-level data access would end up with something like FunC.

FunC is TON's native smart contract language. It features a syntax similar to many modern programming languages and was explicitly built for TON's architecture.

Remote Procedure Calls (RPCs)​

API types:

Learn more about the different API Types available in TON, including Indexed, HTTP, and ADNL.

Node providers partners:

TON Directory Explore a wide range of TON-related projects and tools curated by the community:

Below are two primary resources for accessing information about public node endpoints on the TON Blockchain, including both Mainnet and Testnet.​

Was this article useful?