TON is a layer 1 blockchain where each smart contract is an independent actor that communicates with others only through asynchronous messages. This model scales well but makes the flow of a single operation span several transactions. For a project, building on TON means designing and reviewing message chains rather than single function calls.
Building on TON
A user action typically triggers a sequence of messages across several contracts, each processed in its own transaction, so an operation can partly succeed and partly fail. Messages carry value, and a failed message can be returned to its sender as a bounce. Contracts pay for their own storage and computation. Fungible tokens (Jettons) use one wallet contract per holder, rather than a single balance table.
- Languages: FunC, Tact and Tolk, compiled for the TON Virtual Machine
- Tooling: the Blueprint framework and its sandbox for testing
- Not EVM-compatible
What auditors look at
- Asynchronous flows: intermediate states between messages, race conditions and actions that cannot be rolled back
- Bounce handling: whether a failed message restores balances and state correctly
- Sender authentication: verifying that an incoming message comes from the expected contract, for example a legitimate Jetton wallet
- Gas and value management: enough value forwarded for the whole chain of messages, and storage fees that could freeze a contract
- Replay protection on external messages and the correct parsing of message data
Before requesting quotes
- Draw the message flow of each user operation, including failure and bounce paths
- Specify the language used for each contract and its compiler version
- Provide sandbox tests covering partial failures, not only successful chains
- Describe token contracts precisely if you implement Jettons or NFTs