# Security audits (https://docs.ton.org/llms/audits/content.md) The reports below document external security assessments of TON blockchain components. Each report applies to the scope and code version it identifies. Audits do not guarantee that software is free of vulnerabilities. Responsibly report genuine security issues through the [TON Security Bug Bounty program](https://github.com/ton-blockchain/bug-bounty). ## TON Blockchain [#ton-blockchain] * [Trail of Bits audit report](https://raw.githubusercontent.com/ton-community/ton-docs/refs/heads/main/static/audits/TON_Blockchain_ToB.pdf) * [SlowMist audit report](https://raw.githubusercontent.com/ton-community/ton-docs/refs/heads/main/static/audits/TON_Blockchain_SlowMist.pdf) * [CertiK audit report](https://raw.githubusercontent.com/ton-community/ton-docs/refs/heads/main/static/audits/TON_Blockchain_CertiK.pdf) * [CertiK formal verification of masterchain contracts](https://raw.githubusercontent.com/ton-community/ton-docs/refs/heads/main/static/audits/TON_Blockchain_Formal_Verification_CertiK.pdf) ## TON Blockchain library, `tonlib` [#ton-blockchain-library-tonlib] `tonlib` is the native C++ client library for TON blockchain. * [Zellic security assessment](https://raw.githubusercontent.com/ton-community/ton-docs/refs/heads/main/static/audits/TON_Blockchain_tonlib_Zellic.pdf) ## TVM [#tvm] * [Trail of Bits: TVM and Fift audit report](https://raw.githubusercontent.com/ton-community/ton-docs/refs/heads/main/static/audits/TVM_and_Fift_ToB.pdf) * [Trail of Bits: 2023 TVM upgrade audit report](https://raw.githubusercontent.com/ton-community/ton-docs/refs/heads/main/static/audits/TVM_Upgrade_ToB_2023.pdf) # Coming from Ethereum (https://docs.ton.org/llms/from-ethereum/content.md) Learn how to develop and build on TON coming from the Ethereum (EVM) ecosystem. ## Execution model [#execution-model] ### Asynchronous blockchain [#asynchronous-blockchain] A fundamental aspect of TON development is the asynchronous execution model. Messages sent by one contract take time to arrive at another, so the resulting transactions for processing incoming messages occur after the current transaction terminates. Compared to Ethereum, where multiple messages and state changes on different contracts can be processed within the same atomic transaction, a TON transaction represents a state change only for one account and only for a processing of a single message. Even though in both blockchains a signed included-in-block unit is called a "transaction", one transaction on Ethereum usually corresponds to several transactions on TON, that are processed over a span of several blocks. | Action description | Ethereum | TON | | :--------------------------------------------------------------------------------------------- | -------------------------------------- | -------------------------------- | | Single message processing with state change on one contract | Message call or "internal transaction" | Transaction | | Number of state changes and messages on different accounts produced from initial contract call | Transaction | Chain of transactions or "trace" | Consider a practical example: liquidity withdrawal on a DEX. * On Ethereum, it appears as a single atomic transaction with multiple contract calls inside it. This transaction has a single hash and is included in one block. ETH burn * The same operation on TON consists of a sequence of more than 10 transactions. Each arrow on this image represents a distinct finalized transaction, with its own hash, inclusion block, and all the other properties: GRAM burn Executing a large transaction on Ethereum or any other EVM-based blockchain comes with certain limitations: [call depth](https://ethereum.org/developers/docs/evm/#evm-instructions) of 1,024 nested calls and the [block gas limit](https://ethereum.org/developers/docs/blocks/#block-size). With TON's asynchronous execution model, a trace — a chain of transactions — can have any length, as long as there are enough fees to continue it. For example, the [trace](https://tonscan.org/tx/e887503f7dac857be80487e3ed0774db962379d1c153e6df7b9b5313c657ab94) resulting from this message consisted of more than 1.5 million transactions, lasting more than 4,000 blocks until completion. ### On-chain get methods [#on-chain-get-methods] Another difference is in the [get methods](https://docs.ton.org/llms/tvm/get-method/content.md). Both Ethereum and TON support them, allowing data to be retrieved from contracts without paying fees. However, in TON, get methods cannot be called on-chain: a contract cannot synchronously retrieve data from another contract during a transaction. This is a consequence of TON's asynchronous model: by the moment transaction that called a get method would start its execution, data might already change. ### Account model [#account-model] In Ethereum, there are two types of accounts: externally owned accounts (EOA), and contract accounts. EOAs are human-controlled entities, each represented by a private-public key pair. They sign transactions and each has its own balance; the community often refers to them as "wallets". In TON, there is no such separation. Every valid address represents an on-chain [account](https://docs.ton.org/llms/foundations/addresses/overview/content.md), each with its own state and balance, that could be changed through transactions. This means that "wallets" in TON are smart contracts that operate under the same rules as any other contract on the blockchain. The [TON wallet](https://docs.ton.org/llms/contracts/standard/wallets/comparison/content.md) smart contract works as a proxy: handles an external message, checks message is sent by the wallet's owner using regular [public-key cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography), and sends an internal message somewhere further in the network. ### Limited contract storage [#limited-contract-storage] In Ethereum, it's possible to store any amount of data in a single contract. Unbounded maps and arrays are considered standard practice. TON sets a limit to the amount of data a contract can store. This means that ERC-20-like fungible tokens cannot be implemented in the same way as in an EVM chain, using a single map within a single contract. [The limit](https://docs.ton.org/llms/foundations/config/content.md) for contract storage is 65,536 unique cells contract storage, where a cell [stores up to](https://docs.ton.org/llms/foundations/serialization/cells/content.md) 1,023 bits. Messages are constrained by two size limits: 8,192 cells or 221 bits among them, whichever is smaller. Every map that is expected to grow beyond 1,000 values is dangerous. In the TVM map, key access is asymptotically logarithmic, meaning that gas consumption continuously increases to find keys as the map grows. Instead, [sharding](https://docs.ton.org/llms/contracts/techniques/contract-sharding/content.md) should be used. ## Ecosystem [#ecosystem] ### Tooling [#tooling] The recommended programming language for smart contract development in TON is [Tolk](https://docs.ton.org/llms/tolk/overview/content.md). Other established languages also exist and are still used, albeit in legacy status. For off-chain software, TypeScript is the most adopted language in TON. Most of the tooling, bindings and [SDKs](https://docs.ton.org/llms/applications/sdks/content.md) are implemented in TypeScript. | Use case | Ethereum tool | TON counterparts | | :------------------------------------ | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Blockchain interaction | Ethers, Web3.js, Viem | [`@ton/ton`](https://www.npmjs.com/package/@ton/ton), [`@ton-community/assets-sdk`](https://github.com/ton-community/assets-sdk) | | Wallet connection protocol | WalletConnect, Wagmi | [WalletKit](https://docs.ton.org/llms/applications/walletkit/overview/content.md) that works on [TON Connect](https://github.com/ton-blockchain/ton-connect) | | Dev environment framework / scripting | Hardhat, Truffle, Foundry | [Acton](https://github.com/ton-blockchain/acton), [Blueprint (legacy)](https://github.com/ton-org/blueprint) | | Simulation engine | Revm & Reth | [Emulator within Acton](https://github.com/ton-blockchain/acton), [Sandbox](https://github.com/ton-org/sandbox) | For low-level manipulation of TON-specific data structures, there is [`@ton/core`](https://www.npmjs.com/package/@ton/core). ### Services [#services] [TON Explorer](https://explorer.toncoin.org/) is a low-level open-source dev explorer. [TxTracer](https://txtracer.ton.org/) is a set of web tools to trace and analyze TON Blockchain transactions, visualize execution, and inspect and debug smart contracts with a code editor and user-friendly interface. Additionally, TxTracer hosts several interactive playgrounds: * [Assembly Playground](https://txtracer.ton.org/play/) - Experiment with TVM assembly code directly in your browser. Write, test, and debug assembly instructions with real-time execution. * [Code Explorer](https://txtracer.ton.org/code-explorer/) - Compile FunC or Tolk code to assembly and explore the generated bytecode to understand how your smart contracts work under the hood. * [TVM Instruction Table](https://txtracer.ton.org/spec/) - Browse the TVM instruction reference with detailed descriptions, opcodes, stack effects, and control flow information for every instruction. * [Message Emulator](https://txtracer.ton.org/emulate/) - Emulate sending single messages or message batches to see the full transaction tree and trace execution flow. There is no web IDE — instead, use the local [Acton toolchain](https://docs.ton.org/llms/contract-dev/acton/content.md). ### Standards [#standards] Due to significant differences in execution models, most of the standards in TON differ significantly in semantics and general approach compared to their Ethereum analogs. The table maps Ethereum standards and proposals, including ERC and EIP, to their closest TON counterparts: [TON Enhancement Proposals (TEPs)](https://github.com/ton-blockchain/teps). | Description | Ethereum standard | TON Standard (TEP) | | --------------------------------------- | --------------------------------------- | ---------------------------------------------------------------------------- | | Fungible token standard | ERC-20 | [Jettons (TEP-0074)](https://docs.ton.org/llms/contracts/standard/tokens/jettons/overview/content.md) | | Non-fungible token standard | ERC-721 | [NFT standard (TEP-0062)](https://docs.ton.org/llms/contracts/standard/tokens/nft/overview/content.md) | | Token metadata | ERC-4955 (Not exactly, but close match) | [Token Data Standard (TEP-0064)](https://docs.ton.org/llms/contracts/standard/tokens/metadata/content.md) | | NFT royalty standard | EIP-2981 | [NFT Royalty Standard (TEP-0066)](https://docs.ton.org/llms/contracts/standard/tokens/nft/comparison/content.md) | | DNS-like registry | ENS (EIP-137) | [DNS Standard (TEP-0081)](https://docs.ton.org/llms/foundations/web3/overview/content.md) | | Soulbound / account-bound token concept | EIP-4973 | [SBT Standard (TEP-0085)](https://docs.ton.org/llms/contracts/standard/tokens/nft/comparison/content.md) | | Wallet connection protocol | WalletConnect / EIP-1193 | [TonConnect (TEP-0115)](https://docs.ton.org/llms/applications/ton-connect/overview/content.md) | # Get support (https://docs.ton.org/llms/get-support/content.md) Use Ctrl + K to do an indexed search. Supply the `llms.txt` file to an AI agent for accurate context. ## Telegram chats, channels, and bots [#telegram-chats-channels-and-bots] * [Official TON Developers folder](https://t.me/addlist/dyiIa5Skb3JiN2Fk) - main collection of channels to subscribe to: * Mainnet and testnet status updates. * Developer news. * Contests and grants. * Job opportunities. * Ecosystem news. * [TON Dev Chat (EN)](https://t.me/tondev_eng) - main development discussion chat. * [TON Dev Chat (RU)](https://t.me/tondev) - Russian-speaking chat. * [TON Dev Chat (中文)](https://t.me/tondev_zh) - Chinese-speaking chat. * [TON Core](https://t.me/toncore) - channel with updates from the TON Core development team. Validators and nodes: * [TON Validators Support bot](https://t.me/validators_help_bot) - tech support for validators. * [TON Node Help chat](https://t.me/ton_node_help) - tech support chat group for non-validator nodes, like archive nodes or liteservers. APIs: * [TON Center API Tech Support bot](https://t.me/toncenter_help_bot) - tech support for [TON Center APIs](https://toncenter.com). * To get API keys, use the general [TON Center bot](https://t.me/toncenter) Miscellaneous: * [TON Help bot](https://t.me/ton_help_bot) - tech support for TON Core products (bridge, vesting, multisig, etc). ## Bug bounty programs [#bug-bounty-programs] * [TON Security Bug Bounty on GitHub](https://github.com/ton-blockchain/bug-bounty) - description and links to all relevant projects and resources to research vulnerabilities in. * [TON Security Bug Bounty bot in Telegram](https://t.me/ton_bugs_bot) - send general blockchain security reports to this Telegram bot. ## GitHub repositories [#github-repositories] * [Main TON monorepo](https://github.com/ton-blockchain/ton) - source code for the node and validator, `lite-client`, tonlib, Tolk compiler, and other tools. * [Acton monorepo](https://github.com/ton-blockchain/acton) - source code for the [Acton toolchain](https://docs.ton.org/llms/contract-dev/acton/content.md). # Start here (https://docs.ton.org/llms/start-here/content.md) The documentation is organized by layers of detail, with lower-level details appearing later on the sidebar on the left. | | | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Onboarding | Overview of the basic tools to onboard in TON: from AI and wallets to explorers and analytics. | | Nodes | Guides for running TON infrastructure: nodes, validators, staking setups, and related tooling. | | Applications | Tools and guides for building user-facing dApps: SDKs, WalletKit, TON Connect, as well as guides on monitoring and handling blockchain transactions for business applications. | | APIs | Options for reading TON data and interacting with it from the off-chain world. | | Smart contracts | Working with the most popular standardized contracts and guides on developing new smart contracts. | | Tolk language | Reference documentation for the official TON smart contract language. | | TON Virtual Machine | Description of the low-level language that runs smart-contracts, and details of the runtime. | | Blockchain foundations | Comprehensive description of the blockchain. Includes web version of whitepapers. | | Legacy languages | Documentation for older TON languages kept for maintaining older contracts and understanding historical tooling. | | Contributing | Documentation on writing this documentation. | This is a condensed description of TON. The rest of the documentation may assume that all of this is already known to the reader. ## TON overview [#ton-overview] *TON* is a [blockchain](https://en.wikipedia.org/wiki/Blockchain). It provides a distributed platform for storing data and code, as well as running computations, all the ingredients to host applications. Roughly speaking, it works as if it were a single server executing all the code. The hosted applications are called *smart-contracts*. The platform runs on a set of servers, called [nodes](https://docs.ton.org/llms/nodes/overview/content.md). Most important type of nodes, *validators*, are owned by individuals or organizations with a [large stake in TON and great interest](https://docs.ton.org/llms/nodes/staking/overview/content.md) in keeping the platform safe, fair, and operational. Validators have to reach [consensus](https://en.wikipedia.org/wiki/Consensus_\(computer_science\)) on the state of the blockchain. Typically, the process takes below a second to reach [transaction finality](https://docs.ton.org/llms/applications/payments/overview/content.md), a time to mint a new block. ## Network communication [#network-communication] The nodes that run the blockchain interact via the [ADNL](https://docs.ton.org/llms/foundations/whitepapers/ton/content.md) protocol. User-facing applications usually use [servers](https://docs.ton.org/llms/api/overview/content.md) that proxy JSON HTTP requests into the ADNL network. The official version of such a proxy server is provided by the [liteserver](https://docs.ton.org/llms/nodes/overview/content.md) software. There are public instances of liteserver, so developers are not required to host one on their own servers. ## Gram and fees [#gram-and-fees] *Gram* (GRAM) is the TON's primary [cryptocurrency](https://en.wikipedia.org/wiki/Cryptocurrency). It is used to pay for the execution of smart contracts, the storage of their data, and network traffic. Such payments are called [fees](https://docs.ton.org/llms/foundations/fees/content.md). ## Mainnet and testnet [#mainnet-and-testnet] There are two instances of TON blockchain: mainnet and testnet. *Mainnet* is the "real" network. It's where actual payments in Gram are made. Applications use the mainnet by default. The other network is *testnet*, and it is used by TON developers to check that their applications work correctly before deploying them to mainnet. It uses "test coins" that barely have any value. Usually, when the TON blockchain gets an update, it is first deployed to testnet, and then to mainnet after a brief period of testing, so sometimes they may run different software. Also, their [configuration](https://docs.ton.org/llms/foundations/config/content.md), availability, and throughput might be different. ## Workchains and shards [#workchains-and-shards] A *workchain* is a TON blockchain with its own rules and account space. The *masterchain* holds global configuration and system smart contracts, while the *basechain* host most accounts and user space smart contracts and can be split into shardchains for scalability. In future there might be new workchains with there own set of rules and logic. Practical note: [addresses](https://docs.ton.org/llms/foundations/addresses/overview/content.md) include the workchain ID, and most apps use workchain 0 (basechain). Each network is split into [workchains](https://docs.ton.org/llms/foundations/shards/content.md) that can freely interact with each other, but their implementations may differ significantly. At the moment, there are two workchains: *basechain* (`workchain_id = 0`) for regular use, and a very similar *masterchain* (`workchain_id = -1`) for TON's [internal](https://docs.ton.org/llms/applications/payments/overview/content.md) [bookkeeping](https://docs.ton.org/llms/foundations/system/content.md). The masterchain follows mostly the same rules, except that using it is more expensive to limit the amount of traffic that interferes with TON's internals. To be freely scalable, each workchain is split into *shards*. The number of shards is [determined dynamically](https://docs.ton.org/llms/foundations/shards/content.md) based on the current network load. Internally, every shard is implemented as a separate blockchain. Except for increased latency, the effect on the user-facing code is minimal. ## Accounts [#accounts] It's easiest to visualize the blockchain as a set of [accounts](https://docs.ton.org/llms/foundations/addresses/overview/content.md). Each account has an address and a status. ### Account statuses [#account-statuses] Over its lifetime, an account changes its [status](https://docs.ton.org/llms/foundations/status/content.md) among four values: * `nonexist`: There wasn't a single operation with the account, or it was removed. It has neither a balance, nor code. * `uninit`: If some Gram is transferred to an account, it now exists, but there is still no smart contract code on it. It now has a balance. * `active`: After a deploy message (see below) with code and initial data is sent to an account, it becomes active and can process other messages. It now has a balance, code, and internal state. * `frozen`: If an account is overdue on its [storage fees](https://docs.ton.org/llms/foundations/fees/content.md), it will be frozen until the fees are paid. If the overdue amount reaches a maximum limit specified by the blockchain, the account goes completely bankrupt, is removed, and ceases to exist. ### Smart contracts [#smart-contracts] The *code* on an active account is a smart contract. The term *contract* is often used for an account that holds the code. Statuses overview ### Account addresses [#account-addresses] The [internal address](https://docs.ton.org/llms/foundations/addresses/overview/content.md) of an account is a pair of two numbers: its workchain ID and a 256-bit number. It may be displayed in the [raw format](https://docs.ton.org/llms/foundations/addresses/formats/content.md) (e.g., `0:4098805d2272a61b375350c6b2f5faaaf27c8267d8e7521ff2045104fdc7de76`), but is usually shown in a user-friendly format (e.g., `UQBKgXCNLPexWhs2L79kiARR1phGH1LwXxRbNsCFF9doczSI`). ## Messages [#messages] Addresses specify where [messages](https://docs.ton.org/llms/foundations/messages/overview/content.md) should be delivered. There are three types of messages: * [internal](https://docs.ton.org/llms/foundations/messages/internal/content.md) messages are sent between accounts; * [incoming external](https://docs.ton.org/llms/foundations/messages/external-in/content.md) messages are sent from code outside the blockchain to a contract; * [outgoing external](https://docs.ton.org/llms/foundations/messages/external-out/content.md) messages are broadcast to the external network; somewhat similar to adding them into the globally available list of all outgoing external messages that ever happened. Every internal message should have some Gram attached to it so that it can pay for the cost of handling it. External messages cannot have Gram attached to them because they come from or go to "outside" the blockchain, where Gram does not exist. Incoming external messages come from an external address, and outgoing external messages go to an external address. ## `StateInit` [#stateinit] The *state* of the account changes only when it handles messages. Messages also change the account's balance. An account is `active` when it has a state and a balance. A message might also be a [deploy message](https://docs.ton.org/llms/foundations/messages/deploy/content.md) if it has a `StateInit` structure attached with its initial code and data. When such a message is sent to a destination address [derived](https://docs.ton.org/llms/foundations/addresses/derive/content.md) from the `StateInit` hash, the code and data are stored in the account at that address, and the account becomes active. Both the code and data stored in the account may change in the future, but its address will remain the same as when it was originally deployed. ## Transactions [#transactions] Formally, a message is only an intent: it has a destination, possibly some Gram, and data. After the message is handled and all the necessary changes are applied to the blockchain, the message is packed, along with a description of those changes, into a single packet of data, called a [transaction](https://docs.ton.org/llms/foundations/messages/ordinary-tx/content.md). A transaction records the state changes on an account. [Some transactions](https://docs.ton.org/llms/foundations/messages/overview/content.md) might happen without any message. ## TON Virtual Machine [#ton-virtual-machine] Internal and incoming external messages execute the account's code. The code is interpreted by [TON Virtual Machine](https://docs.ton.org/llms/tvm/overview/content.md) (TVM). It is written in *bitcode*, a binary format specific to TVM. In the future, TVM might support multiple binary languages, *codepages*, but at the moment there is only codepage 0 (`CP0`). ### Phases [#phases] When execution [starts](https://docs.ton.org/llms/tvm/initialization/content.md), the message and current account state are provided to the code. By the end of execution, the account might change its state or code, or send internal or outgoing external messages. The execution follows a process whose steps are called [phases](https://docs.ton.org/llms/foundations/phases/content.md). [Fees](https://docs.ton.org/llms/foundations/fees/content.md) are deducted during this process. Fees might be deducted from the account's balance or from the Gram the message carries, depending on the [mode](https://docs.ton.org/llms/foundations/messages/modes/content.md) of the message, or by [explicit choice](https://docs.ton.org/llms/foundations/messages/external-in/content.md) made in the contract's code. ### Gas [#gas] Execution cost is first measured in *gas* units, then converted to Gram. This unit is separate so that if code execution becomes computationally cheaper (or more expensive), validators can vote to change the [price of gas](https://docs.ton.org/llms/foundations/config/content.md) in Gram. ### Exit codes [#exit-codes] If something goes wrong, a non-zero [exit code](https://docs.ton.org/llms/tvm/exit-codes/content.md) might be returned, no changes to state or code are saved, and no further messages are sent. If the message that resulted in a failed transaction is marked as *bounceable*, a [bounce message](https://docs.ton.org/llms/foundations/messages/internal/content.md) is sent back to the sender. Bounce messages are used to inform the sender that handling of their message failed. They can carry either truncated or full body of the original message. ## Traces [#traces] The most common reason a code is executed is when some account has received a message. Internal messages can only be sent by another contract executing some code, and that contract must have received a message from somewhere too. In the end, every message can be considered part of some *trace*: a tree of messages between accounts that starts with an incoming external message, continues with internal messages, and possibly ends with some outgoing external messages. ### Asynchronous execution [#asynchronous-execution] When some interaction with the blockchain involves multiple contracts, their code may not be executed in the same block. Contracts have to exchange messages with each other, and two such concurrent traces may interleave their messages. This fact is usually referred to as "*asynchronous* message handling." This feature of TON allows a limit to be placed on the maximum complexity of atomic computation and aids its scalability, but it is important to keep it in mind because it might create [race conditions](https://docs.ton.org/llms/contracts/techniques/security/content.md). ## Languages [#languages] Most development is done in [Tolk](https://docs.ton.org/llms/tolk/overview/content.md), a high-level programming language. Its compiler is included in the [Acton](https://docs.ton.org/llms/contract-dev/acton/content.md) development environment. Originally, [Fift](https://docs.ton.org/llms/languages/fift/overview/content.md), a Forth-like assembly language, and [FunC](https://docs.ton.org/llms/languages/func/overview/content.md), a C-like intermediate-level language, were the first languages for TON smart contract development. ## Get methods [#get-methods] If an external service needs to extract data from the blockchain, it can call a [get method](https://docs.ton.org/llms/tvm/get-method/content.md): an arbitrary function implemented in the code deployed to an account. Every call of a get method spawns a separate instance of TVM. Any changes to the blockchain made during the execution of a get method are not committed to the blockchain. Unlike in [other blockchains](https://docs.ton.org/llms/from-ethereum/content.md), get methods cannot be called by other contracts. It is intentional for several reasons: * by the time another contract receives the result of such a call, other messages may have been processed and may have changed the result; * get methods are executed completely separately, and changes from the blockchain are not guaranteed to be propagated to the server running the code of a get method. ## Wallets [#wallets] The main user of incoming external messages is a [wallet](https://docs.ton.org/llms/contracts/standard/wallets/how-it-works/content.md). A wallet is an account with a specific kind of smart contract deployed on it, which can handle incoming external messages, specifically *transfer* messages. A transfer message is a request to send an internal message to another account. Thus, a wallet transforms incoming external messages to internal messages. ### Wallet contract types [#wallet-contract-types] There are several [implementations](https://docs.ton.org/llms/contracts/standard/wallets/comparison/content.md) of wallets, with varying extra functionality and protection. [`V5R1`](https://docs.ton.org/llms/contracts/standard/wallets/v5/content.md) is the latest official general-purpose wallet. The text below describes only the functionality common to most wallets. ### How wallets work [#how-wallets-work] A transfer message consists of a destination address and, optionally, an internal message, both serialized and signed with a [private key](https://en.wikipedia.org/wiki/Public-key_cryptography). The wallet stores a public key and uses it to check that a transfer message was signed with the corresponding private key. If the check succeeds, it sends that internal message to the destination address. This ensures only the user (or a service) who knows the private key can use the wallet. Private and public keys are generated in a program or service outside the blockchain. Public key is used in a `StateInit` during the deploy, and determines the address of the wallet account. Keypair is usually derived from a set of 24 random words called a [mnemonic](https://docs.ton.org/llms/contracts/standard/wallets/mnemonics/content.md). Before the code of the wallet can be deployed on an account with an incoming external message, some other account has to transfer Gram to the wallet account. As external messages cannot have any Gram attached to them, if no funds are in the account when it handles an external message, it cannot pay for the message that deploys a wallet. The transfer of Gram to a wallet account usually comes from an exchange or another user. In testnet, there is [a bot](https://docs.ton.org/llms/onboarding/wallet-apps/get-coins/content.md) that sends test coins to an account for free. Usually, a transfer message is sent without an additional payload and only instructs the wallet to transfer some Gram to a destination address. This is the reason this type of smart contract is called a wallet. An internal message might be a request to some other contract or even a deploy message that deploys code on other accounts. In this way, a wallet acts as a proxy between a user (or an external service) and the rest of the blockchain. ### Wallet apps [#wallet-apps] End users usually use [wallet apps](https://docs.ton.org/llms/onboarding/wallet-apps/web/content.md) to create and use wallets. An exchange will usually create a wallet for a user as well. ## Standard contracts [#standard-contracts] The other [important types](https://docs.ton.org/llms/contracts/standard/tokens/overview/content.md) of contracts are * [Jetton](https://docs.ton.org/llms/contracts/standard/tokens/jettons/overview/content.md) tokens roughly correspond to coins and allow developers to mint their own currency; * [NFT](https://docs.ton.org/llms/contracts/standard/tokens/nft/overview/content.md) tokens are similar to tickets: unique items that can be sold; * [SBT](https://docs.ton.org/llms/contracts/standard/tokens/nft/sbt/content.md) tokens are like medals: unique items that can be given to someone but can never be sold or transferred. Many popular contract types have been standardized in [TON Enhancement Proposals](https://github.com/ton-blockchain/TEPs) (*TEP*), mostly describing expected contract interfaces with TL-B schemas. This allows tooling to be reused between similar contracts. For example, explorers detect TEP-standardized contracts and display their binary messages in a user-friendly format, and provide an interface to call their get methods. ## Explorers [#explorers] An [*explorer*](https://docs.ton.org/llms/onboarding/explorers/content.md) is a type of web app that displays information about the current state of accounts (including wallets, Jettons, and NFTs) and the history of transactions. Discover [popular TON explorers](https://duckduckgo.com/?q=ton+explorer). ## APIs and SDKs [#apis-and-sdks] To interact with wallets, Jettons, and other contracts, data has to be sent through an ADNL or HTTP API into the network. There are several ways to connect: * directly call the [API](https://docs.ton.org/llms/api/overview/content.md), or * use [an SDK](https://docs.ton.org/llms/applications/sdks/content.md) that simplifies working with an API by wrapping its methods in a more user-friendly interface; the most popular TypeScript SDK for this is [`@ton/ton`](https://github.com/ton-org/ton). ## TON Connect [#ton-connect] When an application has to use a wallet to prove the user's identity, it needs access to the wallet's private key. Giving arbitrary applications access to the private key is insecure, as they could perform arbitrary actions with the wallet. To address this, there is the [TON Connect](https://docs.ton.org/llms/applications/ton-connect/overview/content.md) set of SDKs that provide interfaces * for an application to perform an action through the wallet app; * for a wallet app to handle these requests. For example, Telegram apps use TON Connect to access a wallet that is integrated into Telegram. ## Data storage model [#data-storage-model] All data on TON is stored as trees of [cells](https://docs.ton.org/llms/foundations/serialization/cells/content.md): the state of contracts, their code, and messages. Each cell stores up to 1023 bits of data and can have up to 4 *refs* to other cells. Each cell has a hash computed from its bits and refs. Because the hash of a cell that directly or indirectly references itself would require knowing the same hash, creating cyclic data structures is impossible. Standard serialization of such a data structure into a single binary string is the [bag of cells](https://docs.ton.org/llms/foundations/serialization/boc/content.md) (*BoC*). When cells need to be stored in a file or sent over the network, they are commonly serialized into a BoC. Smart contract code is also compiled into BoC files. ### Binary representation [#binary-representation] To tell other developers how a certain type of data is stored in cells, a [TL-B](https://docs.ton.org/llms/foundations/tlb/overview/content.md) schema language is used. Its purpose is similar to that of [protocol buffers](https://en.wikipedia.org/wiki/Protocol_Buffers) or [binary templates](https://en.wikipedia.org/wiki/010_Editor#Binary_Templates), but it provides more features for structuring data at the bit level. [There are libraries](https://docs.ton.org/llms/applications/sdks/content.md) for assembling data structures out of cells. For TypeScript, the most popular one is [`@ton/core`](https://github.com/ton-org/ton-core). The TL-B schemas for binary representations of messages, transactions, initial contract state, and most other data structures used by the blockchain can be found in the [`block.tlb`](https://github.com/ton-blockchain/ton/blob/master/crypto/block/block.tlb) file in the [TON monorepo](https://github.com/ton-blockchain/ton). TypeScript functions for serializing and deserializing them are provided by the [`@ton/core`](https://github.com/ton-org/ton-core) and [`@ton/ton`](https://github.com/ton-org/ton) libraries. In general, a library that converts data structures between cells and the format native to a programming language, or allows calling contract methods as native functions of the language, is called a *wrapper* or *binding*. For example, functions that deserialize Jetton-related cell data into TypeScript objects can be found in the [`assets-sdk`](https://github.com/ton-community/assets-sdk/blob/5285cd75a97acbb15999e7dfb3b8e4ec9e98b4ed/src/jetton/types/JettonBurnMessage.ts) library. [Acton toolchain](https://docs.ton.org/llms/contract-dev/acton/content.md) can generate bindings from the Tolk contract's source code. The "rule of thumb" is that production-grade code should not include low-level manipulation of binary data, and should instead rely on a library with bindings. This reduces the chance of mistakes and ensures the code has more users. With widely reused code, there are more opportunities to detect mistakes, and they are more likely to be fixed quickly. ### Blockchain interaction [#blockchain-interaction] So, to interact with the blockchain, a couple of libraries are usually used: one that handles the connection to the blockchain and another that works with the specific type of data sent over that connection. Not all computation has to be done *on-chain*, i.e., executed inside TVM and paid for with Gram. Computing and storing data on the blockchain is significantly more expensive than doing so on a regular CPU. Instead, much of the work can be done in *off-chain* code, in a regular programming language, before or after sending a request to the blockchain. The recommended development practice is to write a TypeScript library that calls contracts implemented in Tolk. ## Next steps [#next-steps] * [Coming from Ethereum or similar synchronous blockchains?](https://docs.ton.org/llms/from-ethereum/content.md) — compare the differences in execution model and ecosystem. * [Want to host nodes or get involved in staking?](https://docs.ton.org/llms/nodes/overview/content.md) — pick the right TON node setup and understand the required operational work. * [Aiming to build a new dApp or integrate existing one with TON?](https://docs.ton.org/llms/applications/overview/content.md) — use the rich toolset of the TON application layer. * Aspire to write new or audit existing smart contracts? — set up the [toolchain and editor plugins](https://docs.ton.org/llms/contracts/overview/content.md), work with [standard contracts](https://docs.ton.org/llms/contracts/standard/overview/content.md), learn the [techniques](https://docs.ton.org/llms/contracts/overview/content.md) to write new contracts, master the [Tolk language](https://docs.ton.org/llms/tolk/overview/content.md) and the [TVM runtime](https://docs.ton.org/llms/tvm/overview/content.md). # How to adopt sub-second finality (https://docs.ton.org/llms/subsecond/content.md) The TON Core team has [released Catchain 2.0](https://t.me/toncore/104) on mainnet. This consensus upgrade enables sub-second block finality, reducing the block interval from about 2.5s to about 400ms. However, faster block production does not automatically reduce end-to-end latency for users. Projects must adapt their applications so transaction status updates and UI changes use the new timing guarantees. ## Current status [#current-status] Sub-second finality is live on TON mainnet. As of April 9th 2026, mainnet runs with a block interval of about 400 ms instead of \~2.5 s before the upgrade, producing roughly 6.25x more blocks per second. Target finalization lag is reduced from \~10 s to about 1 s. | Network | Block interval | Blocks per second | Finalization lag | | ---------------------------- | -------------- | ----------------- | ---------------- | | Mainnet | \~400ms | \~2.5 | \~1s | | Testnet | \~450ms | \~2.2 | \~1–2s | | Mainnet before Apr 9th, 2026 | \~2.5s | \~0.4 | \~10s | * Together with the consensus update, the [Streaming API v2](#ton-center-streaming-api-v2) delivers status updates with 30 to 100ms latency. * Testnet remains the primary environment for project testing. ## Example of sub-second user experience in action [#example-of-sub-second-user-experience-in-action]