+ + + +

TON Has Had Four Smart Contract Languages in Five Years

DEV

I was working on a TON project late last year, and the first thing I had to figure out was which language to actually write contracts in. TON had four options: Fift (a stack-based Forth-like language), FunC (the “main” language with C-like syntax and some unusual quirks), Tact (a higher-level TypeScript-like language that transpiled to FunC), and technically you could write raw TVM assembly too. For someone showing up to build something, it was a confusing spread. Tact seemed like the obvious pick: modern syntax, growing tooling, about a third of all mainnet contracts written in it. TON’s own blog was running pieces titled “Why Tact is TON’s Next Big Breakthrough.” It felt like the right bet.

Then TON declared Tolk the “official language” and labeled everything else, Tact included, as “legacy.”

What happened

The short version: in July 2025, the TON Foundation shipped Tolk v1.0 and positioned it as the one language developers should use going forward. Tolk was created by Aleksandr Kirsanov, who’d previously maintained KPHP under Nikolay Durov at VK. It started as a proposed FunC v0.5 update in mid-2024, but instead of merging it, the team decided to fork FunC entirely and build something new under a new name.

The design goal was “FunC under the hood, TypeScript on the outside.” And honestly, looking at the before/after, you can see why they did it. FunC had some truly unusual conventions. Tildes for mutating method calls. -1 for boolean true. An impure keyword that, if you forgot it, would let the compiler silently drop your function calls. The stdlib used names like cur_lt() and raw_reserve() where Tolk uses blockchain.logicalTime() and reserveToncoinsOnBalance().

Tolk also compiles directly to Fift assembler then to TVM bytecode, cutting out one step, and achieves 30-50% gas savings over FunC through compiler optimizations like constant folding and auto-inlining. By December 2025, v1.2 had shipped with a borrow checker, anonymous functions, and maps. That’s a fast development pace.

So Tolk is genuinely better than FunC by pretty much every measure. The problem isn’t Tolk. The problem is what it means for Tact.

The Tact situation

Here’s the timeline that bothers me:

  • Late 2022: Steve Korshakov rewrites Tact nearly from scratch
  • 2023: TON blog actively promotes Tact, publishes “The Story of Tact Language”
  • 2024: TON Foundation hires Anton Trunov specifically to lead Tact development
  • January 2025: Trail of Bits completes a security audit of the Tact compiler
  • July 2025: TON Foundation labels Tact “legacy” in favor of Tolk

That’s a lot of institutional investment into a language they’d sideline less than a year later.

And there’s a deeper technical issue. Tact’s compilation chain goes Tact -> FunC -> Fift -> TVM bytecode. It transpiles to FunC as an intermediate step. FunC is being phased out. Tact’s own CONTRIBUTING.md acknowledges this with a note that “this implementation strategy is likely to change.” They know the middle of their pipeline is dying.

Meanwhile, Tolk now covers most of Tact’s selling points: modern syntax, strong types, named structs, pattern matching. Both were trying to be “the friendlier way to write TON contracts.” The difference is Tolk has a direct compilation path and official backing.

This isn’t a situation where two tools coexist because they serve different needs. FunC, Tact, and Tolk all do the same thing: write smart contracts for TVM. The differentiation was almost entirely syntactic. Tact was “FunC but easier,” and now Tolk is also “FunC but easier” with better performance and no middleman in the compilation chain.

Compare this to Solana

Solana’s framework ecosystem is an interesting counterexample because it has diversity that actually makes sense.

The base language is Rust. That’s not changing. What varies is the framework layer, and each option occupies a distinct point on the performance-to-developer-experience spectrum:

Anchor is the high-level framework. Macros, IDL generation, automatic account validation. It’s what most projects use and what most tutorials teach. You trade some compute units for a much faster development cycle.

Pinocchio sits at the opposite end. It’s a zero-dependency, no_std library from Anza (the team behind the Agave validator) that replaces the solana-program crate entirely. It uses zero-copy deserialization, reading account data directly from the SVM’s byte array without copying it to separate memory. The benchmarks are striking: 108 compute units for a hello world vs Anchor’s 649. That’s an 84% reduction, and it lands within 4 CU of hand-written assembly. The P-Token project (a Pinocchio reimplementation of SPL Token) achieved 88-95% CU savings over the standard implementation.

Steel falls in between: less opinionated than Anchor, more structured than going fully native.

The point is that each of these tools exists for a reason. Anchor for rapid development. Pinocchio for squeezing every compute unit out of high-traffic programs. Steel for teams that want a middle ground. They’re all Rust, they compose vertically, and you pick one based on your actual constraints.

TON’s language situation was never like this. There was no meaningful performance gradient between FunC and Tact. No reason you’d choose one over the other based on your program’s requirements rather than your syntax preferences. They were competing to be the same thing.

What this means if you’re picking ecosystems

Language stability is one of those things that doesn’t make anyone’s feature comparison chart but matters a lot in practice. If you’re building a product on a blockchain, you’re committing to that chain’s tooling for years. You’re training a team, building CI pipelines, writing documentation, accumulating institutional knowledge.

TON went through Fift, FunC, Tact, and now Tolk in roughly five years. Each transition means rewriting contracts or at minimum retraining developers. The ~33% of mainnet contracts written in Tact represent teams that are now building on something the foundation considers “legacy.”

Compare that to other ecosystems. EVM has had Solidity as the dominant language for years. Vyper exists as an alternative, but Solidity’s position is not in question. Solana has Rust. Move chains have Move. These aren’t perfect, but they’re stable foundations you can plan around.

I’m not saying TON made the wrong call with Tolk. Looking at FunC’s quirks and Tolk’s improvements, it’s a better language. The 30-50% gas savings alone would justify a migration. But the pattern of investing heavily in a language (blog posts, dedicated team lead, professional security audit) and then pivoting away from it within months is the kind of thing that makes developers cautious about committing to an ecosystem.

Where I’m landing

If you’re starting a new TON project today, Tolk is obviously the right choice. It’s better than FunC, it has a cleaner compilation path than Tact, and it’s where the foundation’s support is going.

If you have existing Tact contracts, you’re probably fine for now. The language still works, and there’s a community maintaining it. But I’d keep an eye on that FunC dependency in the compilation chain.

The broader takeaway for me is that language churn is a real cost when evaluating blockchain ecosystems, and it’s one that’s easy to overlook when you’re comparing TPS numbers and gas fees. A chain that’s still figuring out its developer tooling is a chain that might ask you to rewrite your contracts in two years.

That’s not a dealbreaker. But it should be on the spreadsheet.