The single most common question from someone meeting TON for the first time: “Why doesn’t Solidity work here?” Fair question — the Ethereum Virtual Machine has become the de-facto standard for most L1s and L2s, from Polygon to Arbitrum. TON went the other way and built its own virtual machine. Here’s why, and what it means in practice.
What EVM is and why everyone copies it
EVM (Ethereum Virtual Machine) is the instruction set (opcodes) and execution model for smart contracts originally designed for Ethereum. Since 2015 it has become the standard: Solidity compiles to EVM bytecode, and that bytecode runs on any EVM-compatible chain.
The advantages of EVM compatibility are obvious:
- Contracts port over. Uniswap, Aave, Curve — deployed on Polygon, BNB Chain, Arbitrum without rewrites.
- Toolchain reuse. Hardhat, Foundry, MetaMask, Etherscan — one stack for dozens of chains.
- Easy developer migration. A Solidity engineer from Ethereum starts shipping on Polygon within an hour.
- Liquidity moves. Through bridges or token duplicates.
That’s why most L1/L2 chains after Ethereum chose the EVM-compatible path — even when it isn’t the best engineering choice.
Why TON went a different way
When Nikolai Durov designed TON in 2017–2018, the goals were different:
- Millions of TPS — scalability significantly above Ethereum (then ~15 TPS).
- Sharding by default — dynamic subdivision of the network into parallel shards.
- Tied to Telegram — capable of supporting tens of millions of messenger users.
EVM doesn’t fit those goals well. Here’s why.
Synchronous vs asynchronous
EVM is a synchronous model: contract A calls contract B, waits for the result, and the value flows back into the original transaction. The transaction is atomic — either it all goes through, or all of it reverts.
TON is an asynchronous, message-based model: contract A sends a message to contract B without waiting for an answer. B will execute in the next block (or later, if it lives in another shard). There is no “return-value” atomicity.
iWhy asynchrony
Synchronous calls work poorly with sharding. If contract A in shard 1 wants to call contract B in shard 7, you need cross-shard synchronisation — expensive and slow. Asynchronous messages give sharding genuine parallelism.
Account model
EVM: one global state, all accounts live together, any contract can read any state during a transaction.
TON: each account is its own smart contract with its own storage, and you cannot “read another contract’s state” inside a transaction. If contract A needs data from contract B, A has to send a request message and wait for the reply.
That’s a fundamental design difference.
Gas model
In EVM the transaction initiator pays gas for the entire transaction, and atomicity means “all or nothing”. In TON each inter-contract message is a separate sub-transaction with its own gas, debited from whatever contract is currently executing.
TON has the concept of “the contract pays for its own work” — and that complicates the design versus EVM, where “the user pays gas for everything”.
What it means for the user
From the perspective of a regular user buying TON and sending it to a friend:
- Different address shape. EQ…/UQ… instead of 0x… You can’t copy addresses across networks.
- Different wallets. MetaMask doesn’t support TON. You need Tonkeeper, MyTonWallet or another TON wallet.
- Separate tokens. USDT on TON is a jetton, distinct from ERC-20 USDT on Ethereum. To move between them — bridge.
- Different DeFi. No Uniswap; STON.fi and DeDust instead. No Aave; EVAA instead. The contract curves are different, but the logic is similar.
It’s not scary, but it requires a separate orientation to the ecosystem. A user comfortable with MetaMask + Uniswap can’t do “the exact same thing” on TON one-to-one — a new toolkit is required.
What it means for the developer
For a developer used to Solidity:
- Solidity does not work. Contracts are written in FunC (low-level), Tact (high-level) or Tolk (newest, recommended in 2026). Details — in the developers’ guide.
- Different toolchain. Hardhat does not work. Blueprint from TON Foundation is the standard framework for development, testing and deployment.
- Contract storage. In EVM you use storage slots; in TON — a special structure with explicit serialisation into Cells.
- Think asynchronously. Any inter-contract call is a message. Every “call Pool.swap() and check the return” pattern has to be rewritten with different logic.
Migration time for an experienced developer is a few weeks. Not “an hour to learn Polygon”, but not “learn from scratch” either.
What TON gained and lost
| Parameter | TON (TVM) | Ethereum (EVM) |
|---|---|---|
| Throughput | ~1k–3k TPS basechain, theoretically more | ~15 TPS L1, ~1k–3k via L2 |
| Fee | ~$0.005 | $0.16–0.50 (mainnet, 2026) |
| Ecosystem (projects) | Dozens in the ecosystem | Thousands (across the EVM family) |
| Language standard | FunC/Tact/Tolk | Solidity (Vyper marginal) |
| Contract portability | Impossible from EVM | Trivial between EVM-compatible |
| Audit firms | A handful (Certik, Trail of Bits) | Hundreds |
| Telegram tie-in | Native | None |
Gains: speed, cost, scalability, exclusive access to the Telegram audience. Losses: isolation from the EVM ecosystem, harder developer entry, fewer ready-made building blocks.
Bridges: how tokens move between TON and EVM
Since there’s no native compatibility, the ecosystem developed cross-chain bridges. The principle is the same: lock the token on the source network and mint a wrapped version on the destination.
The main bridges in 2026:
- Symbiosis — multi-chain bridge supporting TON ↔ Ethereum, BNB Chain, Polygon, Arbitrum.
- Orbit Bridge — TON ↔ Ethereum, Klaytn, Polygon.
- TON Bridge (official) — for USDT and a few other key tokens, supported by TON Foundation.
- LayerZero integrations — through wrapped tokens.
Crossing time is usually 5–15 minutes plus block times. Fees depend on the bridge and amount, typically 0.1–0.5%.
!Wrapped tokens are IOUs
When you move USDT from Ethereum to TON you receive wrapped USDT on TON — a jetton issued by the bridge. If the bridge breaks or is exploited, the wrapped token can lose its peg to the original. That’s a real risk of any bridge, not just TON’s.
Could EVM compatibility happen later
Technically — yes, through EVM translators or sidechains. The idea of “EVM as an L2 on top of TON” is discussed in the community, but as of 2026 there are no real production projects.
The alternative — universal standards: tokens via the jetton standard (the ERC-20 analogue), NFTs via TON NFT (the ERC-721 analogue). Not EVM-compatible, but the ideas transfer.
What to do as a user
The practical answer:
- If you’re in the EVM family and don’t want to learn anything new — use bridges, USDT transfers take 10 minutes. Inside TON you’ll still need a TON wallet.
- If you’re new to crypto — TON is an excellent entry point: cheaper and faster than Ethereum, and tied to Telegram.
- If you’re a developer — invest a couple of weeks learning TON. The Telegram audience is worth it, especially for consumer products.
Ecosystem context — in the TON full guide. Practical migration from Ethereum to TON — in a separate piece.
Top comments (0)