What Is the TON Virtual Machine (TVM)? Guide (2026)
— By Tony Rabbit in Tutorials
What is the TON Virtual Machine (TVM)? Learn the stack model, async message passing, cell-based data layout, gas metering and how it compares to the EVM.
The TVM (TON Virtual Machine) is the execution engine that runs every smart contract on The Open Network. It is genuinely different from the EVM, the SVM, and other major virtual machines, mostly because TON's design philosophy is asynchronous: contracts pass messages instead of making synchronous function calls. Understanding the TVM is the difference between treating TON development as a black box and writing contracts that play well with the network's parallelism.
Quick answer: The TVM is a stack-based virtual machine that executes TON smart contracts. It uses a cell-based data layout where everything is stored as small chunks (up to 1023 bits) with up to four references to other cells. Execution is asynchronous: a contract receives a message, runs to completion, and may emit new messages. There are no synchronous calls between contracts. Gas metering is per-contract per-message, and unused gas is refunded.
- Stack-based. Operations push and pop values from a stack rather than addressing registers.
- Cell-based data. Storage uses small chunks called cells with up to four references each.
- Asynchronous execution. Contracts communicate through messages, not synchronous calls.
- Gas metering per message. Each message carries its own gas budget.
- Languages compile to TVM bytecode. FunC, Tact, and others all target the same execution layer.
What the TVM is and why it exists
The TVM is the runtime that turns smart contract code into actual on-chain operations. Every node on the network agrees on the TVM specification, so a contract that runs in one node runs identically everywhere. This determinism is what lets the network reach consensus on contract outcomes.
Trade TON with Not.Trade, the fastest terminal on TON
Not.Trade is purpose built for TON traders: real-time on-chain charts for every jetton, insider safety scoring (Top 10 wallets, snipers, dev movement, bundlers, LP lock), MCAP-trigger limit orders, multi-wallet sniping, MEV protection and one-click swaps routed across STON.fi and DeDust. It runs natively inside Telegram and as a fast web terminal, with TON Connect non-custodial wallet support.
Read the full Not.Trade guide →Why a custom VM
TON's designers built a custom VM to fit the network's sharded, asynchronous architecture. Borrowing the EVM would have meant accepting EVM's synchronous calling model, which fights TON's parallel-shard execution. The TVM gives TON a model where each message is a unit of work that can run in any shard at any time without coordinating with other shards.
Where it sits in the stack
Below the TVM are the network's accounts, storage, and consensus. Above the TVM are the smart contract languages (FunC, Tact). The TVM is the universal interface: every language compiles down to TVM bytecode, and every node executes that bytecode.
Cells and the data layout
One of the TVM's signature design choices is the cell. Everything stored on TON, from contract state to message bodies to NFT metadata, is laid out as a tree of cells.
What a cell is
A cell holds up to 1023 bits of raw data and up to four references to other cells. Larger objects (a long string, a big array, a complex contract state) are represented as trees of cells. The structure is similar in spirit to a Merkle tree.
Why cells matter
The cell layout supports content-addressing (each cell has a hash), efficient diffing (changes only modify affected cells), and storage rent calculation (cell count and time both matter). Long-lived contracts pay a small rent based on the number of cells they keep alive.
Storage rent
Unlike Ethereum's permanent storage, TON charges a tiny ongoing fee for keeping cells alive. The intent is to discourage indefinite bloating. Active contracts pay almost nothing; abandoned contracts that hold large state pay more, eventually getting frozen if their balance hits zero.
Asynchronous execution
The TVM does not let contract A call contract B synchronously. Instead, contract A sends a message to contract B, which is processed in a later step.
One message, one execution
Each on-chain interaction is triggered by a message. The recipient contract reads the message, updates its state, and may emit new messages as a side effect. Those new messages will be processed in subsequent network rounds.
Implications for developers
Developers used to synchronous EVM-style calls have to think differently on TON. A "transaction" on TON is often a chain of messages. Failure handling is also different: a message that bounces back returns funds to the sender, but only if the sender configured the message as bounceable.
Implications for parallelism
The async model is what allows TON to run shardchains in parallel. Two shards can process unrelated messages without coordinating, and even messages between shards are queued and resolved in later rounds.
Gas metering on TON
Every TVM operation has a gas cost. The cost system is similar in spirit to Ethereum's gas, with a few important differences.
Per-message gas
Each incoming message carries its own gas allowance. When the message is processed, gas is consumed by the operations executed. Unused gas is refunded to the sender along with any unused TON balance.
Storage rent vs computation gas
TON charges separately for storage rent (long-term cell storage) and computation gas (work done by the TVM). Both are paid in TON. For most user-facing contracts, computation gas is the bigger cost.
Why fees stay low
Fees stay low because the network can scale through sharding when demand spikes. Most contract executions are cheap, predictable, and refundable when overestimated.
TVM vs EVM
The two engines solve the same problem with different mechanics.
| Property | TVM | EVM |
|---|---|---|
| Architecture | Stack-based | Stack-based |
| Data layout | Cells (1023 bits + 4 refs) | Word-addressed storage |
| Execution model | Asynchronous messages | Synchronous calls |
| Gas refund | Yes, unused refunded | Yes, partial refund |
| Storage cost | Storage rent | Permanent storage cost upfront |
| Languages | FunC, Tact | Solidity, Vyper, Yul |
What this means for developers
Building on TON requires a different mental model than building on Ethereum or Solana.
Think in messages, not function calls
If you find yourself wanting "the result of contract B" inside contract A, you are usually fighting the model. Restructure the flow so contract A sends a message to B and either expects a callback or completes its own state change without waiting.
Think in cells when storing state
Large flat arrays are unfriendly on TON. Tree-shaped data structures play better with the cell layout. State that grows unboundedly should be partitioned across multiple cells or sub-contracts.
Use Tact for friendlier syntax
FunC is closer to assembly. Tact provides higher-level syntax that compiles down to TVM bytecode and is easier to read. Most new TON projects use Tact unless they need fine-grained control.
A practical learning path
- Start with Tact tutorials. Higher-level syntax helps you grasp the message model first.
- Read a Jetton implementation. Master and wallet contracts illustrate the async model clearly.
- Build a tiny contract on testnet. Send messages, observe how they propagate.
- Drop down to FunC when you need to optimize gas or fine-tune cell layout.
- Use a TVM execution trace tool to inspect the stack and messages during development.
Frequently asked questions
Is the TVM compatible with the EVM?
No. The execution models, data layouts, and gas systems are different. Some experimental EVM compatibility layers exist but are not the default development path.
Can I write TON contracts in Solidity?
Native TON development uses FunC or Tact. Some adapters allow Solidity-like syntax, but most production code uses TON's native languages.
Why is the TVM stack-based?
Stack-based VMs are simpler to specify and verify than register-based VMs, and they make it easier to design deterministic gas models. The EVM is also stack-based for the same reasons.
What is a cell on TON?
The basic unit of data on TON. A cell holds up to 1023 bits and up to four references to other cells. Everything stored on TON is laid out as a tree of cells.
Do I pay rent for storing data on TON?
Yes. Storage rent is a small ongoing fee proportional to cell count and time. Active contracts barely notice it; abandoned contracts can drain to zero and freeze.
Final takeaway: The TVM is the most distinctive piece of TON's design. Once you understand the cell layout, the asynchronous message model, and the per-message gas system, the rest of the network's quirks (sharding, low fees, fast finality) make sense as natural consequences. Build with the model, not against it.
Disclaimer: This guide is for educational purposes only and does not constitute investment, financial, legal, or trading advice.
Related Guides
- What Is Toncoin (TON)? Beginner Guide Explained 2026
- Toncoin in 2026: Telegram Economy, Catchain 2.0 and USDT on TON
- What Is a TON Memo Tag and When Do You Need One? Guide (2026)
- What Is TON DNS and How Do .ton Domains Work? Guide (2026)
- What Is TON Connect and How Do You Use It Safely? Guide (2026)
Frequently Asked Questions
What is the TON Virtual Machine (TVM)?
The TVM is the runtime environment that executes smart contracts on the TON blockchain. It defines how contract code runs, how data is stored, and how transactions are processed on the network.
How does the TVM differ from the EVM?
The TVM uses a stack based model with a cell based data layout and asynchronous message passing between contracts, which differs from Ethereum's EVM design. These differences affect how developers structure contracts and how contracts communicate.
What is asynchronous message passing in TON?
On TON, contracts often interact by sending messages that are processed in separate steps rather than completing everything in one synchronous call. This model supports the network's scalability but changes how developers design contract logic.
What is gas in the TVM?
Gas is the unit that measures the computational work a transaction requires, and you pay for it to run contract code. Understanding gas metering helps developers and users estimate the cost of operations.