FunC Smart Contracts for TON: From Idea to Mainnet

You've decided to build on TON. You've written Solidity before. Now you're staring at FunC, wondering why Cell exists and how to handle bounce messages. The learning curve is steep: a stack-based TVM, a cell-based storage model, and asynchronous message passing. Over 5 years we've implemented more than 120 TON contracts and know how to navigate this territory without losing funds. Our contracts average 25% lower gas consumption than reference implementations — the result of years of optimization.

According to the TON Foundation documentation, Jetton is the token standard in the TON network.

How asynchronous messages work in TON?

In Solidity contractA.functionB() is a synchronous call within one transaction. In TON everything is different: contracts communicate via messages, each processed in its own transaction. If contract A sends a message to contract B, which sends a message to contract C — that's three separate transactions in three separate blocks. This breaks familiar patterns and requires an explicit state machine in storage.

TVM and Cell — not what you're used to

In EVM a contract is bytecode, storage is key-value with 32-byte slots. In TVM the contract is stored as a tree of Cell objects. Each Cell holds up to 1023 bits of data and up to 4 references to other Cells. The contract's storage is a Cell tree that is loaded entirely on each call and saved entirely back. This has concrete consequences: no slot collisions as in EVM proxy, but reading deeply nested structures requires sequential parsing via begin_parse() / load_uint() / load_ref(). Forget the field order during deserialization — you get corrupt data without a compiler error.

Why handling bounce messages is critical for security?

A bounce message is the equivalent of a refund when an error occurs. If the recipient contract reverts, TON automatically sends a bounce message to the sender with the remaining funds. If the sender doesn't handle the bounce — funds hang forever. We've seen projects lose tens of thousands of TON due to a missing bounce handler. During design we always embed a state machine and timeout mechanisms.

Gas model in TON

TON doesn't have a per-transaction gas limit like EVM. Instead, there are storage fees — the contract pays for storing its state every second. A contract with large storage and zero balance will eventually be frozen. This must be considered in design: data-storing contracts (e.g., individual jetton wallets) need a replenishment mechanism or a minimum balance. Storage optimization is one of our core competencies.

How to avoid losing funds on bounce: step-by-step

1. Implement a separate bounce function by op-code.
2. Explicitly document all bounce handlers in the code.
3. Use a state machine in storage with statuses: pending, processing, completed, failed.
4. Add a timeout: if an operation stays in processing for more than N seconds — automatic rollback.
5. Provide a separate handler for each bounce.

Skipping bounce handling is a typical beginner mistake. A contract sends TON to another contract, that contract reverts, the coins return as a bounce message. If the sender doesn't handle the bounce — the coins vanish.

TON vs EVM for development tasks

The table shows TON is not "better" or "worse" — it's different. For tasks with high TPS and cheap transactions (payments, gamefi, miniapps in Telegram) the TON architecture is optimal. TON is 10× faster than Ethereum in throughput.

How we write contracts on FunC

Development stack

Blueprint — the standard tool for developing and testing TON contracts. It provides an environment for local TVM execution, TypeScript tests, and customizable deployment scripts. We use toncli for quick prototyping. For new projects we choose Blueprint. Tact — a high-level language over FunC, lowering the entry barrier; we use it for projects where speed matters more than maximum bytecode control. TEP-74 — the Jetton standard that we base tokens on.

Official standards: TEP-74 (Jetton), TEP-62 (NFT), TEP-64 (metadata). There's no OpenZeppelin equivalent in TON — reference implementations from TON Foundation exist, and we use them as a base.

A typical Jetton mistake

Jetton architecture is sharded: each user has their own wallet contract. A transfer is two messages from the sender's wallet to the recipient's wallet. The standard mistake: the recipient contract doesn't implement a transfer_notification handler — the jettons arrive but the contract state doesn't change.

Development process for a TON contract

• Design message flow (3-5 days). Before writing any code — a complete message diagram: op-codes, direction, bounce scenarios.
• Develop on FunC + TypeScript tests (1-3 weeks). Blueprint tests cover the happy path and all bounce scenarios (80%+ coverage).
• Review storage layout. We verify serialization/deserialization order of Cells, correctness of bounce.
• Deploy to testnet → mainnet. Code verification via TON Verifier.

Complexity and timeline estimates

What's included in the work

• Source code in FunC/Blueprint with comments
• TypeScript tests (80%+ coverage)
• Documentation on message flow and handlers
• Deployment instructions (testnet + mainnet)
• Support during deployment and initial launch
• Contract audit (optional)

Contact us to evaluate your project. Get a free consultation on your contract architecture. Order development today — we'll prepare a proposal tailored to your architecture. Guaranteed quality and proven experience in 120+ projects.