Why TON is not EVM-compatible and what it means for users

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:

1. Millions of TPS — scalability significantly above Ethereum (then ~15 TPS).
2. Sharding by default — dynamic subdivision of the network into parallel shards.
3. 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.

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

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%.

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:

1. 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.
2. If you’re new to crypto — TON is an excellent entry point: cheaper and faster than Ethereum, and tied to Telegram.
3. 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.

Sources

• TON Whitepaper — Architecture overview
• TON documentation: TVM
• TVM vs EVM comparison, blog.ton.org
• Symbiosis — TON ↔ EVM bridge