Skip to main content

Frequently Asked Questions

This section covers the most popular questions about 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 is workchains better than L1 → L2?​

Workchains in TON, offer a number of advantages over traditional L1 and L2 layer architecture.

  1. One of the key advantages of a blockchain 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 between different parts of the network. This is especially important for applications requiring high speed and low latency.
  2. Workchains support cross-shard activity, which means that users can interact between different shardchains or workchains within the same network. In current L2 solutions, cross-shard operations are often complex and require additional bridges or interoperability solutions. In TON, for example, users can easily exchange tokens or perform other transactions between different shardchains without complex procedures.
  3. Scalability is one of the main challenges for modern blockchain systems. In traditional L2 solutions, scalability is limited by the capacity of the sequencer. If the TPS (transactions per second) on L2 exceeds the sequencer's capacity, it can lead to problems. In workchains in TON, this problem is solved by dividing the shard. When the load on a shard exceeds its capacity, the shard is automatically divided into two or more shards, allowing the system to scale almost without limit.

Is there a need for L2 on the TON?​

At any transaction cost, there will always be applications that cannot sustain such a fee but can function at a much lower cost. Similarly, regardless of the latency achieved, there will always be applications that require even lower latency. Therefore, it is conceivable that there might eventually be a need for L2 solutions on the TON platform to cater to these specific requirements.

MEV​

Is front running possible in TON?​

In the TON blockchain, deterministic transaction order plays a key role in preventing frontrunning. This means that the order of transactions within a blockchain is predetermined and deterministic. No participant can change this order once transactions have entered the pool. This system eliminates the possibility of manipulating the order of transactions for profit, which differentiates TON from other blockchains such as Ethereum, where validators can change the order of transactions within a block, creating opportunities for MEV (maximum extractable value).

In addition, the current TON architecture lacks a market-based mechanism for determining transaction fees. Commissions are fixed and not subject to change depending on transaction priorities, which makes frontrunning less attractive. Because of the fixed fees and deterministic order of transactions, it is non-trivial to do frontrunning in TON.

Block​

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

Blocks produced by Validators. Existing blocks available via Liteservers. Liteservers accessible via Lite Clients. On top of Lite Client built 3rd-party tools like wallets, explorers, dapps, etc.

Additionally, here are three high-level third-party block explorers:

Read more in the Explorers in TON section of our documentation.

Block time​

2-5s

info

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

Time-to-finality​

Under 6 sec.

info

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

Average block size​

max block size param 29
max_block_bytes:2097152
info

Find more actual params in Network Configs.

What is the layout of blocks on TON?​

Detailed explanations on each field of the layout:

Transactions​

RPC method to get transactions data​

Is TON transaction asynchronous or synchronous? Is it possible to access documentation that show how this system works?​

TON Blockchain messages asynchronous:

  • sender prepares the transaction body(message boc) and broadcasts it via Lite Client (or higher-level tool)
  • Lite Client returns status of broadcast, not result of executing the Transaction
  • sender checks desired result by listening target account(address) state or the whole blockchain state

An explanation of how TON asynchronous messaging works is explained using an example related to Wallet smart contracts:

Example for Wallet contract transfer (low-level):

Is it possible to determine if a transaction is 100% finalized? Is querying the transaction level data sufficient to obtain this information?​

Short answer: To ensure the transaction is finalized, the receiver's account must be checked.

To learn more about transaction verification, please see the following examples:

What is the layout of a transaction in TON?​

Detailed explanations on each field of the layout:

Is transaction batching possible?​

Yes, transaction batching on TON can be accomplished in two distinct ways:

  • By utilizing the asynchronous nature of TON, i.e. sending independent transactions to the network
  • By making use of smart contracts which receive task and execute it as a batch

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

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

Standards​

What accuracy of currencies is available for TON?​

9 digits

info

Number of decimal places supported by Mainnet : 9 digits.

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 NFT?​

On TON, all data is transmitted as boc-messages. This means that using NFTs in transactions is not an exceptional event. Rather, it is a regular message that is sent to or received from a (NFT- or Wallet-)contract, much like a transaction involving a standard wallet.

However, certain indexed APIs allow you to view all messages sent to or from a contract, and filter them based on your specific requirements.

To better understand how this process works, please refer 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 the address is a token address?​

For a Jettons contract must implement standard's interface and return data on get_wallet_data() or get_jetton_data() methods.

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

There is a special master blockchain inside a TON called Masterchain. It consists of 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.

Good example is 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.

Account address is generated deterministically from its initial state, which includes initial code and initial data (for wallets, initial data includes public key among other parameters). When any component changes, the address changes accordingly.

Smart contract can exist in uninitialized state, meaning that its state is not available in blockchain but contract has non-zero balance. Initial state itself can be sent to the network later with an internal or external message, so those can be monitored to detect contract deployment.

To protect message chains from being halted at non-existing contracts TON use "bounce" feature. Read more in these articles:

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

Currently, the ability to update smart contracts is a normal practice and is widely used in most modern protocols. This is because upgradability allows for bug fixes, adding new features and improving security.

How to mitigate the risks:

  1. Pay attention to projects with a good reputation and well-known development teams.
  2. Reputable projects always conduct independent code audits to make sure the code is safe and reliable. Look for projects that have several completed audits from reputable auditing firms.
  3. An active community and positive feedback can serve as an additional indicator of a project's reliability.
  4. Examine exactly how the project implements the update process. The more transparent and decentralized the process, the less risk to users.

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

The contract must be verified, this allows you to check the source code and ensure that there is no update logic to ensure it remains unchanged. If the contract does indeed lack mechanisms to change the code, the terms of the contract will remain unchanged after deployment.

Sometimes the logic for updating may exist, but the rights to change the code may be moved to an "empty" address, which also precludes changes.

Is it possible to re-deploy code to an existing address or does it have to be deployed as a new contract?​

Yes, this is possible. If a smart contract carries out specific instructions (set_code()) its code can be updated and the address will remain the same.

If the contract cannot initially execute set_code() (via its code or execution of other code coming from the outside), then its code cannot be changed ever. No one will be able to redeploy contract with other code at the same address.

Can smart contract be deleted?​

Yes, either as a result of storage fee accumulation (contract needs to reach -1 TON balance to be deleted) or by sending a message with mode 160.

Are smart contract addresses case sensitive?​

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

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

The TVM is not compatible with the Ethereum Virtual Machine (EVM) because TON leverages a completely different architecture (TON is asynchronous, while Ethereum is synchronous).

Read more on asynchronous smart contracts.

Is it possible to write on Solidity for TON?​

Relatedly, the TON ecosystem does not support development in Ethereum’s Solidity programming language.

But if you add asynchronous messages to the Solidity syntax and the ability to interact with data at a low level, then you get FunC. FunC features a syntax that is common to most modern programming languages and is designed specifically for development on TON.

Remote Procedure Calls (RPCs)​

API types:

  • Read more about different API Types (Indexed, HTTP, and ADNL)

Node providers partners:

TON directory with projects from TON Community: