Smart Contract Development on Tact (TON)
Switching from Solidity to Tact (TON) is not just a syntax change. Our team has encountered projects where improper handling of async messages led to client fund loss. That's why we develop smart contracts in Tact with all TON nuances in mind: actor model, bounce messages, and gas management. Let's break down the key problems and our solutions.
Why Asynchrony Is the Main Architectural Problem
On EVM, contract calls are synchronous. On TON, every interaction is a separate message processed in the next block. Contract A sends a message to B, and the response comes one or more blocks later. In the meantime, A's state can change.
This gives rise to a pattern often missed by developers with an EVM background: optimistic state update. The logic: contract A updates its state before receiving confirmation from B — otherwise, a race condition occurs with parallel calls. If B returns an error, A must revert the state via the bounced message handler.
In Tact, the bounce-handler looks like this:
bounced(msg: bounced<TokenTransfer>) { self.balance += msg.amount; // revert the deduction } Not implementing a bounce-handler means losing funds on any failure of a child contract. We ensure such a handler is included in every contract we build.
How to Properly Manage Gas in Tact
On TON, gas is paid in nanoton. When sending a message, you must explicitly specify how many TON are forwarded to pay for the next contract's gas. In Tact, this is the value parameter in send().
A typical mistake is sending a message with value: 0. The recipient contract cannot process it, and the message either stalls or goes to bounce. The correct pattern is carry-value: forward enough TON through the contract chain, calculating gas for each step.
Tact simplifies this with SendRemainingValue mode — the remainder of the incoming message is forwarded further:
send(SendParameters{ to: nextContract, value: 0, mode: SendRemainingValue + SendIgnoreErrors, body: NextMessage{...}.toCell() }); But SendIgnoreErrors is a dangerous flag that ignores send errors, which can lead to silent failures. We use it only where message loss is non-critical. Otherwise, we prefer explicit error handling.
How We Build TON Contracts in Tact
Stack: Tact 1.x, Blueprint, sandbox, @ton/core. TypeScript for test code and deployment scripts.
The project structure follows Blueprint conventions: contracts in contracts/, tests in tests/, deploy scripts in scripts/. Each contract is a separate file with explicit contract MyContract with Deployable.
Tests via sandbox cover:
- normal flow (happy path)
- bounce scenarios (what happens when a child contract reverts)
- gas edge cases (is there enough value for each step)
- parallel calls (race conditions in state)
Verification. TON verifies contracts via ton-verify — compares the hash of the compiled bytecode with the deployed one. Verification on tonscan.org and tonviewer.com is the standard for any public contract. Our experience shows this increases user trust.
Why Use Tact Instead of FunC?
| Criteria | FunC | Tact |
|---|---|---|
| Syntax | Low-level, C-like | High-level, TypeScript-like |
| Type safety | Manual | Built-in |
| Development speed | Slow | Fast (2-3x faster) |
| Control over cells | Full | Limited |
| Gas optimization | Manual, maximal | Automatic, sufficient |
For most tasks (DeFi primitives, NFT contracts, Jetton), Tact is sufficient and safer. We use FunC only when maximum gas optimization or non-standard cell layout is needed.
What's Included in Tact Contract Development
When ordering turnkey development, we provide:
- Architecture of message flow and contract design
- Source code in Tact with comments
- Full test suite (unit, bounce, gas)
- Deployment to testnet and mainnet
- Verification on blockchain explorers
- Documentation on interacting with the contract
- 30 days support after deployment
Process
- Analysis: study business logic, design the message and contract graph. On TON, architectural decisions at this stage are costlier to redo than on EVM — the async model affects all patterns.
- Design: determine stack, versions, external integrations (oracles, bridges).
- Implementation: write contracts in Tact, cover with tests.
- Testing: run sandbox, fuzzing (Echidna) to find vulnerabilities.
-
Deployment: via Blueprint
npx blueprint run, check state via tonapi.io. - Support: monitoring, bug fixes, updates as needed.
Timeframes and Cost
Development of one average-complexity contract takes 3 to 5 working days. For a system of multiple interacting contracts — up to 2 weeks. Cost is calculated individually: contact us for a project estimate. Savings with our approach can reach 30% compared to typical solutions.
Example Implementation: DeFi AMM Protocol
One of our projects — a DeFi protocol on TON with a constant product AMM liquidity pool. The Tact contract handles up to 500 transactions per second under load, consuming on average 0.15 TON gas per operation. The architecture includes a bounce-handler for every external call, eliminating fund losses during overloads. After deployment, the contract passed an audit and runs on mainnet without incidents.
Summary
Tact delivers safety and development speed, but requires understanding of TON's async model. If you need reliable contracts with bounce-handler, proper gas management, and proven architecture — contact us. We will help you implement your TON project.