Smart Contract Development in Tact (TON)

Smart Contract Development on Tact (TON)

TON is not yet another EVM clone. An asynchronous message model, actor model, infinite sharding — all of this makes contract development fundamentally different compared to Solidity. Tact emerged as an attempt to make this development more accessible: strict typing, familiar syntax, built-in safety primitives. But behind the convenience lie specific patterns, ignorance of which leads to loss of funds or non-working logic.

Asynchronicity as Main Architectural Challenge

In EVM, a contract call is a synchronous operation. In TON, every interaction between contracts is a separate message processed in the next block. Contract A sends message to contract B, receives response through one or more blocks. In the meantime, A's state can change.

This creates a pattern that EVM developers miss: optimistic state update. Logic: contract A updates its state before receiving confirmation from B — otherwise parallel calls create race condition. If B returns error, A must rollback state via bounced message handler.

In Tact, bounce-handler looks like:

bounced(msg: bounced<TokenTransfer>) {
    self.balance += msg.amount; // rollback deduction
}

Failing to implement bounce-handler means losing funds on any downstream contract failure.

Gas Management: forward_ton and carry-value Pattern

In TON, gas is paid in TON (nanoton). When sending message between contracts, you must explicitly specify how much TON to forward with message to cover gas of the receiving contract. In Tact this is value parameter in send().

Typical mistake: send message with value: 0 — receiving contract can't process it due to insufficient gas. Message hangs or bounces. Correct pattern — carry-value: forward sufficient TON through contract chain, calculating gas at each step.

Tact simplifies this via SendRemainingValue mode — remaining balance from incoming message is forwarded further:

send(SendParameters{
    to: nextContract,
    value: 0,
    mode: SendRemainingValue + SendIgnoreErrors,
    body: NextMessage{...}.toCell()
});

But SendIgnoreErrors is dangerous flag. It ignores send errors, which can lead to silent failure. Use it only where losing message is non-critical.

How We Build TON Contracts with Tact

Stack: Tact 1.x, Blueprint (testing framework from TON Foundation), sandbox for local execution, @ton/core for working with cells/slices in tests. TypeScript for test code and deploy scripts.

Project structure follows Blueprint conventions: contracts in contracts/, tests in tests/, deploy scripts in scripts/. Each contract — separate file with explicit contract MyContract with Deployable.

Tests via sandbox cover:

• normal flow (happy path)
• bounce scenarios (what happens on downstream contract revert)
• boundary gas values (enough value on each step)
• parallel calls (no race condition in state)

Verification. TON verifies contracts via ton-verify — compares hash of compiled bytecode with what's deployed. Verification on tonscan.org and tonviewer.com — standard for any public contract.

Comparison of FunC and Tact

For most tasks — DeFi primitives, NFT contracts, jetton standard — Tact is sufficient and safer. FunC we use when maximum gas optimization or non-standard cell layout is needed.

Process

Start with message flow design: draw graph of contracts and messages between them. On TON, architectural decisions at this stage are more expensive to redo than on EVM — because async model affects all patterns.

Development takes 3-5 days for one medium complexity contract, up to 2 weeks for system of multiple interacting contracts. Mainnet deployment — via Blueprint npx blueprint run, with status checking via tonapi.io.