Learn how to develop and build on TON coming from the Ethereum (EVM) ecosystem.
Execution model
Asynchronous blockchain
One of the biggest stepping stones to learn TON development is the asynchronous execution model. Messages sent by one contract take time to arrive at another, meaning that the resulting transactions for processing incoming messages will occur 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, a TON transaction represents a 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 a 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 a practical example, liquidity withdrawal on DEX.
On Ethereum, it will appear as a single atomic transaction with multiple contract calls inside it. You can see that this transaction has a single hash and is included in one block:
The same operation on TON will differ, consisting 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:
If you want to execute a huge 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’s asynchronous execution model, you can have a 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 the two chains is that TON has get methods, which allow data to be retrieved from the contracts without paying any fees. In TON, you can’t synchronously retrieve data from another contract - you can’t call a 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 limitations, read an article about the on-chain Request-Response pattern.
Account model
There are two types of accounts in Ethereum: externally owned accounts (EOA in short) and contract accounts. EOAs are human-controlled entities, each represented by a private-public key pair. They are used to sign transactions and each has its own balance; they are commonly called “wallets” by the community.
In TON, there is no such separation; every valid address represents an 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.
The TON wallet smart contract uses regular asymmetric cryptography to control message signing, ensuring that the user experience remains essentially unchanged. 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 standard 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 an EVM chain, by using a 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 the TVM map, key access is asymptotically logarithmic, meaning that it will continuously cost you more gas to find keys as the map grows.
Ecosystem
This section will primarily focus on Typescript tooling since historically this language has been better adopted and well-established in TON.
| 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 essential 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 web3 developers also have their favorite set of products and services for easier on-chain development. This table showcases some of the use cases that existing TON services can cover.
If you are looking for commercial RPC and node providers, check our Providers overview section.
Standards
This section showcases a match between some of the Ethereum standards and proposals (ERC and EIP) and their counterpart or similar proposals in TON (TEP).
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.
