Reentrancy
A class of smart-contract vulnerability where an external call re-enters the original contract before its current execution completes, letting the attacker repeat a sensitive action. TON's architecture makes classic reentrancy impossible.
Aliases: re-entry attack, reentrancy bug
Reentrancy is the most infamous vulnerability in Ethereum’s history: the 2016 DAO exploit that triggered a network hard fork was a reentrancy bug. In the classical EVM model it works like this: contract A calls contract B (or transfers ETH); B uses the callback to re-enter A before A has finished its function; A executes the sensitive action again — for example, withdrawing the same balance twice.
Why it works in EVM
EVM contracts execute synchronously: calling another contract blocks the caller, and control returns only after the callee finishes. If the callee makes a re-entrant call, it lands in the caller’s state before the caller has finished updating its own data.
Why it cannot happen in TON
TON has a fundamentally different architecture — asynchronous messages between contracts:
- Contract A does not call contract B directly — it sends B a message.
- The message goes into a queue and is processed in a later transaction.
- A’s current transaction finishes. Its state updates atomically.
- Only afterwards does B process the message; if it wants to reply, it sends its own message into the queue.
“Re-enter A before its current call completes” is physically impossible — the current call has already finished before B even starts processing. This closes classic reentrancy at the execution-model level.
What can still go wrong
The asynchronous model introduces TON-specific bug classes:
- Race conditions between messages. A contract awaits a response from B; meanwhile a message from C arrives that mutates state. If the developer did not anticipate that ordering, it is a bug.
- Bounce messages. If a transaction executes but the recipient cannot accept it (out of gas, wrong opcode), the message “bounces” back. Handling bounces correctly is its own discipline.
- Out-of-order delivery. Messages between different shards can arrive in a different order than they were sent. Contract logic must tolerate that.
Implications for users
Anyone saying “TON has no reentrancy so its smart contracts are safe” is oversimplifying. Reentrancy is genuinely absent, but TON has its own equally serious bug classes. Contract audits remain mandatory; the checklist auditors run is just different.