Bitaigen Research In today’s rapidly evolving blockchain landscape, TON (The Open Network) is attracting an ever‑growing number of developers thanks to its efficiency and flexibility. The platform’s distinctive architecture offers a rich set of tools and possibilities for decentralized applications, but the accompanying contract‑security challenges cannot be ignored. This article discusses TON’s core characteristics, common security pitfalls, and practical optimisation recommendations, helping developers avoid risks when writing FunC contracts.
Our Bitaigen editorial team has carefully identified often‑overlooked security blind spots in TON contracts and compiled practical protection and optimisation strategies. By following these guidelines, developers can pre‑emptively mitigate risks during FunC programming, ensure stable project operation, quickly grasp key points, and improve development efficiency.
Frequently Overlooked Vulnerabilities in TON Smart Contracts
In previous security analyses we catalogued the typical vulnerability types found across the TON ecosystem (see the tables below). This article focuses on the subtle details that are easy to miss yet potentially harmful.
(1) Code Readability and Constant‑isation
Contracts often contain hard‑coded numbers—for example, `0x18` is used to denote NON_BOUNCEABLE. Such magic numbers make later maintenance difficult. It is recommended to abstract these critical values into named constants and replace naked error codes with a unified variable in error messages, thereby improving readability and maintainability.
(2) Use `end_parse()` to Ensure Complete Parsing
When a TON contract parses external data, it follows a fixed order, reading fields of specified types segment by segment. `end_parse()` checks whether the slice has been fully consumed; if any residue remains, it throws an exception. This guarantees that the data structure exactly matches expectations and prevents logic errors caused by incomplete parsing.
(3) Data‑Type Mismatch Errors
When storing integers, the type must remain consistent. For instance, after writing `-42` with `store_int()`, attempting to read it back using `load_uint()` will raise an exception. Always use the same signed or unsigned type for both storing and loading.
(4) Appropriate Use Cases for `inline` and `inline_ref`
- inline – The function body is directly inlined at each call site. Suitable for short, frequently invoked code but can cause code bloat.
- inline_ref – The function code resides in a separate cell and is invoked via `CALLREF`. Ideal for larger functions or those reused in many places, effectively reducing duplicated code.
Considering function size and call frequency, it is advisable to use `inline_ref` for complex or frequently reused functions and `inline` for lightweight utilities.
(5) Explicit Working‑Chain ID
TON can support up to 2³² working chains, each of which can be further subdivided into 2⁶⁰ shards. When generating a target address, a contract must specify the chain ID to avoid placing the address on the wrong working chain. Using `force_chain()` to force‑set the chain ID is a reliable approach.
(6) Uniqueness and Conflict Avoidance for Error Codes
Error codes should be unique within a contract to prevent ambiguity caused by duplicate definitions. Additionally, avoid colliding with platform‑defined standard error codes (e.g., `333` indicates a chain‑ID mismatch). It is recommended to allocate custom error codes in the 400 – 1000 range to reduce the likelihood of conflicts.
(7) Always Save and Return After Completing an Operation
When a contract processes different `op‑code`s that involve state changes, it must call `save_data()` to persist the modifications, followed by `return()` to signal normal termination. Omitting `return()` triggers a `throw(0xffff)` exception, causing the transaction to roll back.
---
TON Asynchronous Features and Account Mechanism Explained
Network Sharding and Asynchronous Communication
TON’s network is divided into a three‑layer chain hierarchy:
- Masterchain – Holds global metadata and consensus, recording the state of all working chains and shardchains to ensure overall security and consistency.
- Workingchains – Independent blockchains, limited to 2³² in number, each of which can be customised for specific business logic or contracts.
- Shardchains – Sub‑chains of a working chain, with a maximum of 2⁶⁰ shards, responsible for parallel transaction processing and thus boosting throughput.
In theory, each account can own an exclusive shardchain with its own COIN/TOKEN balances, allowing transactions between accounts to execute completely in parallel. The message‑propagation path between shards follows log₁₆(N) ‑ 1 (where N is the total number of shardchains), enabling efficient asynchronous communication.
*Image source: https://frontierlabzh.medium.com/ton-web3世界的weixin-e1d3ae3b3574*
Message Mechanism for Contract Interaction
In TON, contracts communicate via internal messages (contract‑to‑contract) or external messages (originating from an outside entity). The sender does not need to wait for an immediate response before proceeding with subsequent logic. This asynchronous model, compared with Ethereum’s synchronous calls, markedly improves flexibility and scalability, but also introduces challenges in handling concurrency and race conditions.
Message Format
A typical message includes the sender, receiver, transfer amount, and a payload. The payload can carry function calls, data transfers, or custom instructions. Its format is highly extensible, accommodating a wide variety of inter‑contract requirements.
Message Queue and State Handling
Each contract maintains an internal queue of pending messages, processing them sequentially. Because execution is asynchronous, a contract’s state is only updated after the corresponding message has been consumed. Developers must therefore design contracts with careful attention to state consistency.
Advantages of Asynchrony
- Efficient Sharding – The asynchronous mechanism aligns naturally with the sharding architecture; each shard processes its own messages without cross‑shard synchronization bottlenecks.
- Resource Utilisation – Computation does not need to be completed within a single block; execution can be spread across multiple blocks, reducing peak resource demand.
- Fault Tolerance – If a contract cannot respond promptly due to resource limits, the sender can continue executing other logic, preventing a single point of delay from stalling the entire system.
Design Challenges
- State Consistency – Asynchronous messages may arrive at varying times, making the order of state changes nondeterministic. Contracts should incorporate safeguards (e.g., versioning, checksums) to achieve eventual consistency.
- Race Conditions – Concurrent messages that modify the same state require locking mechanisms or transactional patterns to avoid conflicts.
- Security Risks – Cross‑contract communication can be vulnerable to man‑in‑the‑middle or replay attacks; incorporating timestamps, nonces, or multi‑signature verification is advisable.
---
Ledger Model and Account Abstraction
Account Abstraction
TON adopts a contract‑based account model. Each account is essentially a contract comprising three parts: Code, Data, and Message Handling. An address is derived from the code hash, the initial deployment data, and additional parameters; the same code can yield different addresses on different shards or chains. This design turns an account into more than a mere asset holder—it can encapsulate sophisticated business logic, cross‑account messaging, and condition‑triggered automation, offering greater extensibility than traditional account models.
Ledger Structure
Account state is organised and persisted via a Merkle tree, guaranteeing data integrity while enabling efficient verification. The primary state entries include:
- Main‑coin balance
- Other token balances
- Contract code (or its hash)
- Persistent data (or Merkle hash)
- Number of storage cells and raw byte statistics
- The master‑chain block number of the last payment
- Public key used for transfers (optional, defaults to `account_id`)
Not every field is required for every account; for example, a regular user account does not need to store contract code. When a working chain is created, a `sum‑product`‑type tag distinguishes different constructors, and the final state is stored as a collection of TVM‑persistent storage cells.
Message Processing
At the ledger layer, asynchronous message handling is built‑in. Each account can independently receive and process messages, with state updates occurring only after a message is consumed, thereby supporting high‑concurrency interactions without mutual blocking.
---
Characteristics of the Gas Model
TON’s gas‑fee model provides finer granularity in measuring and allocating resources. It independently accounts for computation, storage, and message transmission, preventing a single contract from monopolising compute power or storage space.
- Parallel Execution – Thanks to sharding, multiple contracts can run simultaneously on different shards. Gas costs are therefore distributed across many nodes, alleviating congestion on any single chain.
- Dynamic Adjustment – The system automatically adjusts gas prices based on real‑time network load; fees drop when the network is idle, encouraging transaction submission during low‑load periods and improving overall resource utilisation.
---
Consolidated Recommendations and Closing Remarks
TON’s innovative sharding, asynchronous messaging, and flexible account model provide a powerful foundation for decentralized applications. Nevertheless, contract security remains pivotal for the ecosystem’s healthy growth. When writing FunC contracts, developers should:
- Use named constants to improve readability;
- Invoke `end_parse()` after data parsing to verify that no slice remains;
- Keep storage and retrieval types consistent;
- Choose between `inline` and `inline_ref` based on function size and reuse frequency;
- Explicitly set the correct working‑chain ID;
- Manage unique, non‑conflicting error codes;
- After any state change, always call `save_data()` followed by `return()`.
Adhering to these best practices, combined with rigorous security audits, enables developers to fully leverage TON’s advantages, building secure and reliable decentralized applications that contribute to a robust ecosystem.
The TON ecosystem is expanding rapidly, attracting substantial capital and an active user base. At the same time, security concerns must not be overlooked. We hope the risk points and optimisation measures presented here offer valuable guidance during the contract design phase.
For deeper material on TON smart contracts, please follow other articles from Bitaigen (比特根).
---
Acquisition Note (Global Market Adaptation)
If you wish to acquire TON tokens, you can do so using USD via SEPA or SWIFT transfers on exchanges that support the network. Users residing in the United States should use Binance.US rather than the global Binance platform. Remember that cryptocurrency transactions may be subject to tax reporting obligations in your local jurisdiction.
Related Reading
- Understanding Ethereum Gas Fees: Costs, Validators, and Network Security
- What Is a Smart Contract? Definition, How It Works & Benefits
- Bitcoin Wallets Explained: Keys, Security & Address Generation
💡 Register on Binance with referral code B2345 for the maximum trading fee discount. See Binance complete guide.
