Coming from Ethereum

Learn how to develop and build on TON coming from the Ethereum (EVM) ecosystem.

This guide only covers basic principles and tooling around them. If you want more practical example, check out Tokens on Ton.

Execution model

Asynchronous blockchain

One of the biggest stepping stones to learn TON development is asynchronous execution model. Messages sent by one contract take time to arrive to another, meaning that the resulting transaction, for incoming message processing, will happen after the current transaction terminates.

So compared to Ethereum, where you can have multiple processed messages and state changes on different contracts in the same atomic transaction, on TON transaction represents state change only for one account and single message processing. That means that a signed, included-in-block unit is called a “transaction” in both chains, however having the differences in execution models, it has different impact.

Here is a table for comparison:

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”

Let’s explore practical example, liquidity withdrawal on DEX.

On Ethereum it will look like this, single atomic transaction, with multiple contract calls inside it. You can see that this transaction has a single hash and included in one block:

The same operation on TON will be different, it will consist of more than 10 transactions, triggered by one another. Each arrow on this image represents a distinct finalized transaction, with its own hash, inclusion block and all the other properties:

If you want to execute a really big transaction on Ethereum (or any other EVM-based blockchain) you will have certain limitations: EVM call-depth of 1024 nested calls and block gas limit. With TON asynchronous execution model you can have trace (chain of transactions) of whatever length you want, as long as you have fees to continue it. For example, trace that resulted from this message consisted of more than 1.5+ million transactions, lasting more than 4000 blocks until its end!

On-chain get methods

Another radical difference between two chains is get methods, a way to retrieve some data from the contracts without paying any fees. In TON you can’t synchronously retrieve data from another contract - you can’t call get method from another contract during the transaction.

If you wonder how we can make any DeFi protocol or complicated on-chain system work with these limitation, read an article about on-chain Request-Response pattern.

Account model

There are two types of accounts in Ethereum: externally owned accounts (EOA in short) and contract accounts. EOA are human-controlled entities, represented each by private-public key pair. They are used to sign transaction and each have their own balance, they are commonly called “wallets” by community.

In TON, there is no such separation, every valid address represents on-chain account, each with its own state and balance, that could be changed through transactions (read more about accounts here). This means that “wallets” in TON are smart-contracts, that operate under the same rules as any other contract on the blockchain.

TON wallet smart-contract use familiar asymmetric cryptography to control message signing, meaning that user experience stay more or less the same. You can examine Wallet Standard implementation code and how it changed through ecosystem development.

Limited contract storage

In Ethereum, you can store as much data as you want in a single contract. Unbounded maps and arrays are considered a normal practice and you will probably see them in most of the contract examples. This is not the case with TON - every smart contract on TON blockchain has a storage size upper limit. That means that you can’t implement ERC20-like fungible tokens in the same way as in EVM chain, by using single map inside one contract.

The limit is 65536 unique cells per message or contract storage. Each cell is up to 1,023 bits, which sets a hard upper limit.

Every map that is expected to grow more than 1000 values is dangerous! Note that in TVM map key access asymptotic is logarithmic, meaning that it will continuously cost you more gas to find keys with map grow.

Instead, you should use sharding.

You can read more about TON architecture design choices that have lead to such differences here.

Ecosystem

Tooling

This section will mostly focus on Typescript tooling since historically this language is better adopted and well-established in TON.

Recommended programming language for smart contract development in TON is Tolk. However, there are other established languages in the ecosystem, you can read more about them here.

Here is ecosystem overview table.

Use case	Popular Ethereum tool	TON counterpart
Blockchain interaction	Ethers, Web3.js, Viem	@ton/ton, Asset-sdk
Wallet connection protocol	Walletconnect, Wagmi	TonConnect
Dev environment framework / scripting	Hardhat, Truffle	Blueprint
Simulation engine	Revm & Reth	Sandbox

Another important library to know about is @ton/core. This library handles low-level blockchain primitives (de-)serialization, you will probably need it together with any RPC-client or contract interaction library.

Services

Most of the web3 developers also have their favorite set of products and services that they use for easier on-chain development. This table showcases some of the use-cases that existing TON services can cover

Use case	Ethereum service	TON service
User-friendly explorer	Etherscan	Tonviewer, Tonscan
Open-source dev explorer	Blockscout	explorer.toncoin.org
Debugger	Remix Debugger	TxTracer
IDE	Remix IDE	Web IDE
Asm playground and compilation explorer	Evm.Codes	TxTracer

If you are looking for commercial RPC and node providers, check our Providers overview section.

Standards

This section showcases match between some of the Ethereum standards and proposals (ERC and EIP) and their counterpart or similar proposals in TON (TEP).

Because of major differences in execution models, most of the standards in TON are quite different in semantics and general approach compared to their Ethereum analogs.

Description	Ethereum standard	TON Standard (TEP)
Fungible token standard	ERC-20	Jettons (TEP-0074)
Non-fungible token standard	ERC-721	NFT standard (TEP-0062)
Token metadata	ERC-4955 (Not exactly, but close match)	Token Data Standard (TEP-0064)
NFT royalty standard	EIP-2981	NFT Royalty Standard (TEP-0066)
DNS-like registry	ENS (EIP-137)	DNS Standard (TEP-0081)
Soulbound / account-bound token concept	EIP-4973	SBT Standard (TEP-0085)
Wallet connection protocol	WalletConnect / EIP-1193	TonConnect (TEP-0115)