Tact vs FunC vs Tolk: which language for TON contracts

By mid-2026, a TON developer faces a choice: which language to write a smart contract in? Not one, not two, but three actively used languages — FunC, Tact, Tolk. All three are supported, all three produce valid TVM bytecode, each has its own niche. This guide is a practical head-to-head: syntax, gas, ecosystem, a hello-world jetton in each, decision matrix at the end.

The real question is not “which language is best” but “which one suits your specific project”. There’s no universal answer. After this article you’ll be able to make a justified choice yourself.

TL;DR — quick comparison

• FunC — low-level functional language. Maximum gas control, minimal abstractions. High learning curve. ~70% of mainnet contracts.
• Tact — high-level Solidity-like language. Declarative receive blocks, traits, OOP. Low learning curve. ~20% of mainnet contracts.
• Tolk 1.4 — TON Foundation’s modern language (2024–2026). TypeScript-like syntax, ABI, TS wrappers, source maps, 30–50% gas savings vs FunC. ~10% of mainnet contracts but share growing fast.

When to pick what:

• Prototype, quick start, team with TypeScript background → Tact.
• High-volume DEX, oracle, protocol core with gas-critical paths → FunC.
• New project focused on modern DX and tooling → Tolk.

Context: why three languages at all

TON is a unique architecture. TVM (TON Virtual Machine) is a stack machine with its own type system (cells, slices, ints, builders). Solidity doesn’t port — the concept differs, EVM bytecode doesn’t run here. So languages were designed from scratch.

History:

• 2018–2021: FunC. Nikolai Durov writes the first language for TON. Functional, low-level — this was a deliberate choice to give developers full control.
• 2022–2023: Tact appears. The community asked for a high-level language. Tact arrives as a Solidity alternative.
• 2024–2025: TON Foundation launches Tolk. The goal — close the gap between “too low-level FunC” and “too abstract Tact”. Tolk gets pitched as “the new recommended language.”
• 2026, Tolk 1.4: declarative contract block, ABI export, TypeScript wrappers, source maps land. Tolk becomes production-ready.

This isn’t “evolution from bad to good” — it’s expanding the spectrum. Each language stays in its niche.

FunC — low-level, maximum control

FunC is a functional language with explicit work over the TVM stack. Visually it resembles a hybrid of C and Lisp. More code, fewer abstractions.

Syntax

A hello-world Counter contract in FunC:

#include "imports/stdlib.fc";

global int total;

() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) impure {
    if (in_msg_body.slice_empty?()) {
        return ();
    }
    int op = in_msg_body~load_uint(32);
    if (op == 1) {
        total = total + 1;
        return ();
    }
}

int get_total() method_id {
    return total;
}

What you can see:

• Explicit typing (int, cell, slice).
• Direct TVM instructions via slice operations (load_uint, slice_empty?).
• stdlib.fc import is mandatory — even base functions live there.
• Globals for state — you serialise/deserialise manually.
• impure marker for functions with side-effects.

Pros of FunC

• Maximum gas control. You write close to the bytecode, optimise by hand.
• Full TVM coverage. Any TVM feature is directly accessible.
• A huge body of examples. STON.fi, DeDust, jetton minter, NFT standard — all in FunC. You can copy patterns from proven code.
• Audit ecosystem. All TON audit firms have extensive FunC experience. It’s easier to find a competent audit for a FunC contract.

Cons of FunC

• High learning curve. You need to understand cells, slices, dictionaries, stack-machine concepts.
• Boilerplate. Serialisation, authorisation, op-code dispatch — all manual.
• Easy to make mistakes. Stack management, load/store order, wrong type in a dictionary — bugs that are hard to catch.
• No modern abstractions. Pattern matching, generics, type aliases — absent.

When to pick FunC

• A contract with a critical gas budget: DEX pool, oracle, lending vault.
• Maintenance of an existing FunC project.
• Implementing a low-level library called by other contracts.
• Audit is critical and you want maximum readability for auditors.

Tact — Solidity-like, friendly

Tact was conceived as “Solidity for TON”. High-level, declarative, with traits and contract syntax.

Syntax

Hello-world Counter in Tact:

contract Counter {
    total: Int as uint32 = 0;

    receive("increment") {
        self.total = self.total + 1;
    }

    receive("reset") {
        self.total = 0;
    }

    get fun total(): Int {
        return self.total;
    }
}

What you can see:

• Declarative contract block.
• Fields auto-serialise to storage.
• receive("increment") — a string-based message handler.
• Type aliases (Int as uint32) for serialisation control.
• get fun — get-methods as in Solidity.

Pros of Tact

• Low learning curve. If you know Solidity or TypeScript — you learn Tact in a day or two.
• Auto-serialisation. No manual pack/unpack for structs.
• Traits. Ready-made modules for jetton minter, NFT collection, ownable, jetton wallet — you plug them in like mixins.
• Good documentation at tact-lang.org.
• Production-tested. Many 2024–2025 projects use Tact (USDe-on-TON, several gaming projects).

Cons of Tact

• Less gas control. The compiler emits “safe” code, not always optimal.
• Some TVM features aren’t directly accessible. Complex optimisations require embedding FunC fragments.
• Smaller community than FunC. Fewer ready patterns, fewer audit firms specialising specifically in Tact.
• Not every auditor knows Tact deeply. This can be a problem when choosing an audit firm.

When to pick Tact

• Prototype, MVP, hackathon project.
• Team with Solidity or TypeScript experience but no TVM internals knowledge.
• Contract business logic is simple, gas budget not critical.
• You want ready-made traits (jetton, NFT, ownable) without rewriting from scratch.

Tolk — modern, recommended

Tolk is TON Foundation’s most recent language. By June 2026 we have version 1.4.1 (see release breakdown). Syntax closer to TypeScript and Rust, but the engine underneath is FunC-based.

Syntax

Hello-world Counter in Tolk 1.4:

contract Counter {
    storage: Storage
    incomingMessages: Increment | Reset
}

struct Storage {
    total: uint32
}

struct Increment(0x1)
struct Reset(0x2)

fun onInternalMessage(in: InMessage) {
    val storage = Storage.load();

    match (in.body) {
        Increment => {
            storage.total += 1;
        }
        Reset => {
            storage.total = 0;
        }
    }

    storage.save();
}

get fun total(): int {
    return Storage.load().total;
}

What you can see:

• Declarative contract block (new in 1.4).
• Typed structs.
• Pattern matching match on message type.
• Auto-serialisation of storage with explicit Storage.load() / .save().
• get fun for get-methods.
• Tag-based union types (Increment | Reset).

Pros of Tolk

• Modern syntax. If you know TypeScript or Rust — you’ll feel at home quickly.
• 30–50% gas savings vs FunC per official TON Foundation benchmarks. Achieved through auto-inlining of functions, intelligent stack management, dead-code elimination.
• ABI export. From 1.4 the compiler automatically generates a contract ABI (types, methods, events) — machine-readable.
• TypeScript wrappers. A Tolk build emits a TS module for the dApp with autocomplete and type checking.
• Source maps. You can debug TVM bytecode with attribution back to the Tolk source.
• Pattern matching, generics, null safety. Modern type-system features.
• TON Foundation backing. New examples and tutorials are shipping in Tolk.

Cons of Tolk

• Young. By June 2026 it’s just over a year in production. Fewer edge cases have hit mainnet.
• Audit firms are still building expertise. Not every auditor has deep Tolk knowledge.
• Documentation is still being written. Some advanced scenarios show gaps in docs.
• Fewer ready-made patterns. If you want a jetton minter in Tolk — you’ll write from scratch or adapt from FunC. Tact has a ready trait.

When to pick Tolk

• A new project with no FunC/Tact legacy.
• Team wants modern DX and tooling.
• Gas optimisation matters but isn’t so critical that you’d write hand-tuned FunC.
• You’ll ship a dApp and want auto TS wrappers for the frontend.
• You can tolerate that some docs are still in development and community support is smaller than for FunC.

Decision matrix — when to pick what

A summary table putting the criteria in one plane:

Scenario 1: a beginner learning TON

Start with Tact. Low barrier, fast feedback loop, you’ll have a working contract by the end of the evening. After Tact, once you understand the message model, cells, asynchrony — look at Tolk and FunC.

Alternative: jump straight to Tolk if you have TypeScript experience. Tolk is strongly typed, errors are visible at compile time, syntax is modern.

Don’t start with FunC — that’s like learning web development from assembly. It works, but not for the first experience.

Scenario 2: a team coming from Solidity

Tact. The declarative syntax is the closest to Solidity. Contract block, events, modifiers (via traits), get methods — all familiar.

After 1–2 months of production experience with Tact — look at Tolk. Many concepts transfer, and you get a modern type system on top.

Scenario 3: a new DEX protocol

FunC. Every gas unit matters — saving 5% gas on pool operations gives a noticeable advantage when competing with DeDust and STON.fi. Tolk is close, but audit firms are still ramping; for a major DEX, battle-tested FunC is the safer pick.

Alternative: Tolk for a new DEX if the team is willing to be an early adopter and has budget for extra audits.

Scenario 4: gaming project with millions of users

Tact or Tolk. Gaming logic isn’t usually gas-critical — many simple calls rather than heavy math. What matters is development speed and ease of updates.

Tact wins on ready traits (NFT, ownership), Tolk wins on modern DX.

Scenario 5: a jetton minter for a memecoin

Tact or copy a reference implementation in FunC. A standard jetton is a solved problem — no need to reinvent.

• Tact: there’s a Jetton trait — two hours of work and you have a working contract.
• FunC: copy a reference minter from TEP-74 examples — an hour of work, battle-tested code.

Tolk doesn’t yet have a canonical jetton template, you’d write from scratch.

Scenario 6: a new core DeFi protocol (lending, staking, RWA)

Tolk — the most forward-looking choice for a 2026–2027 launch. You get gas savings, ABI for integrations, TS wrappers for frontend, source maps for debugging. Audit firms are catching up; in six months to a year, their expertise will be deep.

Alternative: FunC if the team already has experience and strong audit relationships on FunC.

Tooling — everything runs through Blueprint

The good news: there’s a single framework — Blueprint from TON Foundation. It supports all three languages. Project creation:

npm create ton@latest my-contract
cd my-contract
npm install

Blueprint will ask:

• Which contract language (FunC / Tact / Tolk).
• The main contract name.
• Whether to include an example.

After that you get a ready structure:

my-contract/
  contracts/      # contract sources
  wrappers/       # TS wrappers for deployment
  scripts/        # deploy scripts
  tests/          # unit tests
  build/          # compiled .boc and ABI

Commands:

• npx blueprint build — compile.
• npx blueprint test — run sandbox tests.
• npx blueprint run --testnet — deploy to testnet.
• npx blueprint run --mainnet — deploy to mainnet.

Full workflow details — in the TON developer guide.

Can you mix languages in one project?

Yes, partially:

• Tact + FunC. Tact can embed FunC fragments to optimise gas-critical hot paths. Used regularly — main logic in Tact, hot path in FunC.
• Tolk + FunC. Tolk compiles through a FunC intermediate, and you can call FunC functions from Tolk. Less common.
• Tact + Tolk in one project. Can’t compile together, but the same repo can hold different contracts in different languages with a shared Blueprint setup.

The main rule: one contract — one language. Don’t try to rewrite half a contract in another language for optimisation purposes — that’s a path to bugs.

What’s important to grasp before choosing

A few final thoughts.

1. The language isn’t the hardest part. The TON model is harder: cells, asynchronous messages, bounce, storage fees. On any of the three languages you’ll hit these concepts. Tact and Tolk hide them but don’t eliminate them — bugs from misunderstanding asynchrony are possible in all three languages.
2. Audit decides. Regardless of language, a contract holding real money — must pass an audit. Audit budget runs from $5K (simple contract) to $50K+ (complex DeFi protocol). Plan for it.
3. Tolk will grow. By late 2026 to early 2027, Tolk’s mainnet share will rise from 10% to 25–30%. If you’re planning a multi-year TON developer career — bet on Tolk as primary, FunC as secondary.
4. Tact won’t die. Solidity-like syntax pulls developers from the EVM world. That’s a wide pipeline, and Tact will remain in demand within it.
5. FunC is the base. Even if you write only in Tact or Tolk, understanding FunC is useful — to read other contracts, review audit reports, optimise critical paths.

Where to go next

• If you want to start with Blueprint and your first contract — the TON developer guide.
• If Tolk and its newest features interest you specifically — Tolk 1.4 breakdown and Tolk introduction.
• If you’re going to build a jetton — TEP-74 jetton standard.
• If you want to understand what a jetton is in plain terms — the jetton guide.

Sources

• docs.ton.org/develop/smart-contracts — official documentation for all three languages.
• tact-lang.org — Tact’s dedicated documentation.
• docs.ton.org/develop/smart-contracts/tolk/overview — Tolk docs.
• GitHub TON-Foundation Blueprint — the framework.
• Tolk-bench gas comparisons — official gas-savings benchmarks.