TON Scanner Skill

Purpose

Analyze TON (The Open Network) smart contracts written in FunC or Tact for security vulnerabilities. TON's actor-model architecture, asynchronous message passing, and TVM (TON Virtual Machine) create a fundamentally different security model from EVM-based chains.

TON Architecture Overview

┌─────────────────────────────────────────────────────────────────┐
│                         TON Network                             │
│                                                                 │
│  ┌──────────────┐    async messages     ┌──────────────┐        │
│  │  Contract A   │ ──────────────────► │  Contract B   │        │
│  │  (Shard 1)    │ ◄────────────────── │  (Shard 2)    │        │
│  │               │    bounce/reply      │               │        │
│  │  FunC / Tact  │                      │  FunC / Tact  │        │
│  └──────┬───────┘                      └──────┬───────┘        │
│         │                                      │                │
│         ▼                                      ▼                │
│  ┌──────────────┐                      ┌──────────────┐        │
│  │    Storage    │                      │    Storage    │        │
│  │  (Cells/BoC)  │                      │  (Cells/BoC)  │        │
│  │  pays rent    │                      │  pays rent    │        │
│  └──────────────┘                      └──────────────┘        │
└─────────────────────────────────────────────────────────────────┘

Key Differences from EVM

Aspect	EVM (Solidity)	TON (FunC/Tact)
Execution Model	Synchronous, atomic	Asynchronous, actor-based messages
Cross-Contract Calls	Atomic within transaction	Non-atomic, separate transactions
Storage Cost	One-time gas	Ongoing rent (storage fees)
Data Structure	Key-value mapping	Cell trees (max 1023 bits, 4 refs)
Reentrancy	Within same transaction	Not possible (async messages)
Failure Handling	Revert entire tx	Bounce messages, partial failure
Languages	Solidity, Vyper	FunC (low-level), Tact (high-level)
Address Format	20-byte, single chain	Workchain ID + 256-bit hash

Languages

Language	Level	Usage	Security Characteristics
FunC	Low-level	Core contracts, jettons, NFTs	Direct TVM access, manual cell serialization, easy to misuse
Tact	High-level	Modern contracts	Type-safe, auto-serialization, safer defaults but newer
Fift	Assembly-level	Deployment scripts	Direct TVM opcodes, used for contract deployment

Detection Capabilities

Critical Vulnerabilities

• Message chain gas exhaustion: Multi-hop messages run out of gas before completing all operations
• Missing bounce handling: Bounced messages not processed → permanent fund loss
• Unbounded storage growth: Attacker-controlled data storage drains contract balance via rent
• Missing replay protection: Same message processed multiple times

High Vulnerabilities

• Carry-value attacks: Incoming message value used to fund outgoing messages without accounting
• Cell overflow/underflow: Exceeding 1023-bit or 4-reference cell limits during serialization
• Workchain ID confusion: Not validating workchain in address leads to cross-chain issues
• Incorrect message mode flags: Wrong send mode causes unintended gas forwarding or balance drain

Medium Vulnerabilities

• Storage fee drain: Contract balance slowly depleted by rent payments on stored data
• Sharded message ordering: Assuming message order across shards causes race conditions
• Tick-tock contract abuse: Automatic execution contracts with expensive operations
• Missing accept_message() in external handlers: External messages silently dropped without gas acceptance

Real-World TON Incidents

Incident	Vulnerability	Impact
Early Jetton implementations	Missing bounce handling	Token loss on failed transfers
DNS auction contracts	Gas exhaustion in multi-message chains	Auctions stuck irrecoverably
Various NFT marketplaces	Replay attacks (no seqno)	Duplicate sales/purchases
Storage-based attacks	Unbounded storage growth	Contract balance drained by rent

Resources

• TON Patterns — Full vulnerability patterns with FunC/Tact code
• TON Audit Workflow — Step-by-step audit methodology

Related Scanners

• Solidity Scanner — EVM comparison for cross-chain auditors
• Solana Scanner — Another non-EVM async model for comparison

Error Code Reference

Common TON/FunC error codes encountered during audits. TON uses numeric exit codes in throw() / throw_if() / throw_unless() statements.

Standard TVM Exit Codes

Exit Code	Name	Meaning
0	Success	Normal successful execution
2	Stack underflow	Too few arguments on the stack — FunC function signature mismatch
3	Stack overflow	Stack exceeded limits
4	Integer overflow	Integer does not fit into 257-bit signed range
5	Integer out of range	Value outside expected range for operation
6	Invalid opcode	Unknown TVM instruction — possible code corruption
7	Type check error	Wrong type on stack — e.g., expected cell, got integer
8	Cell overflow	Cell data exceeds 1023 bits or 4 references
9	Cell underflow	Attempted to read more data than cell contains
10	Dictionary error	Invalid dictionary (hashmap) operation
11	Unknown error	General "most common" error
13	Out of gas	Computation exceeded gas limit
-14	Out of gas (credit)	Gas credit depleted before accept_message()

Common Application Exit Codes (Convention)

Exit Code Range	Convention	Meaning
30-39	Auth errors	Unauthorized sender (throw_unless(33, ...))
40-49	State errors	Invalid contract state for operation
50-59	Balance errors	Insufficient balance for operation
60-69	Validation errors	Invalid input parameters
100-199	Jetton Standard	Jetton (token) specific errors
200-299	NFT Standard	NFT specific errors
300-399	DEX errors	Liquidity pool / AMM errors
400+	Application-specific	Custom application logic errors

Jetton Standard Error Codes

Exit Code	Meaning
73	Insufficient jetton balance for transfer
74	Not enough TON for gas fees attached to transfer
75	Invalid sender — not the jetton wallet owner
76	Discovery: unknown jetton wallet

Troubleshooting

Issue	Likely Cause	Solution
Bounce handler vulnerabilities missed	Scanner doesn't analyze bounced<> message handlers	Audit all recv_internal branches that handle bounced messages — check for state rollback correctness
Message chain replay not detected	Scanner analyzes single messages, not chains	Trace full message chains: initial message → internal messages → bounces; check seqno/query_id uniqueness
Gas estimation issues not flagged	Scanner doesn't model TON gas economics	Flag messages without accept_message() or with insufficient gas forwarding via msg_value
Actor model concurrency bugs missed	Scanner uses synchronous mental model	Map all async message flows; check for time-of-check/time-of-use between separate messages
FunC vs Tact pattern mismatch	Scanner patterns written for FunC, code is in Tact	Verify Tact's auto-generated FunC output; Tact handles some safety checks automatically
Storage fee drain not caught	Scanner doesn't model TON storage costs	Check that contracts handle storage_fee deductions; verify minimum balance maintenance