🫧 Tolk v1.2: rich bounced messages, cheap deployment, and a breaking change that you'll love

Tolk v1.2 is here, aligned with TVM 12 — bringing new assembler instructions that make contracts cheaper and cleaner.

This update introduces one breaking change, several powerful new capabilities, and a few quality-of-life improvements across the compiler.

✅ Notable changes in Tolk v1.2:

1. Breaking change: address is now "internal only"
2. Rich bounces: not 256 bits, but the full body on bounce
3. Cheap builder-to-slice, StateInit, and address composition
4. Improved compilation errors
5. Anonymous functions (lambdas)
6. Borrow checker to catch undefined behavior

PR on GitHub with detailed info.

✔ `address` is now "internal only"

Before:
* address meant internal/external/none

Now:
* address — internal only
* address? (nullable) — internal/none, exactly like "maybe address" in @ton/core
* any_address — internal/external/none

In 99% of contracts only internal addresses are used. External ones are rare, and "none" can be expressed as nullable.

struct Storage {
    // internal, checked automatically
    owner: address
}

With new TVM 12 instructions, addresses are validated automatically during (de)serialization without extra gas — no more manual isInternal() checks.

So yes, it's technically a breaking change, but it removes a ton of noise.

A short migration guide, as well as technical details, available here.

✔ Rich bounced messages

Historically, a bounced message only returned the first 256 bits of the original body.

Now TVM 12 supports rich bounces — which lets you obtain the entire body instead.

createMessage({
    bounce: BounceMode.RichBounce,
    ...
})

In onBouncedMessage, you get access to the original body, exit code, gas used, and more.

Old true/false bounce flags still work for backward compatibility.

Rich bounces simplify complex message flows and inter-contract communication — one of the most painful aspects of TON until now.

✔ Cheap builder-to-slice and address composition

Previously, converting a builder to a slice (endCell + beginParse) consumed a lot of gas because cells are expensive. Now there's a new instruction — BTOS (builder-to-slice) — without intermediate cell creation.

- b.endCell().beginParse() is now cheap: auto-optimized to BTOS
- "builder-to-address" is the same BTOS; hacks around "return a builder with a valid address" can be removed
- cheaper StateInit hashing and address calculations

Just update to Tolk v1.2 + TVM 12, and you'll immediately save gas.

✔ Anonymous functions (lambdas)

Can be used in general-purpose frameworks, perfectly integrated with the type system:

fun customRead(reader: (slice) -> int) { ... }

customRead(fun(s) {
    return s.loadUint(32)
})

✔ Low-level compiler enhancements

Also included: better diagnostics with precise ranges, new peephole optimizations, tuple ↔ object conversions, and multiple small fixes. A lightweight borrow checker prevents undefined behavior on concurrent mutations.

As always, all additions are carefully described in a PR.

🌳 We've also started improving TVM itself — new assembler instructions are designed specifically to fit the Tolk type system and optimizer. I have always said: the language is just the beginning. Perfect developer experience requires improving every layer of TON's stack. The road may be sharp and curvy — but we're definitely heading in the right direction.

🫧 Tolk documentation — now complete and available for learning from scratch

From now on, Tolk has full, structured, from-scratch documentation — not just "Tolk vs FunC", but a complete language guide that lets developers approach Tolk directly, without any FunC background.

This is a major milestone. Tolk is the recommended language for TON, and now it finally has documentation that matches this role.

Read →

↓ What's inside

The documentation covers the entire language:

❶ Type system.
Every type on its own page: numbers, addresses, structures, generics, etc. — plus overall explanations for TVM layout and serialization.

❷ Syntax details.
Functions, conditions, loops, exceptions, and more — with minimal descriptions and clear examples.

❸ Language features.
Everything needed for smart-contract development: message sending, contract storage, automatic serialization, etc.

❹ Migration from FunC.
A complete guide for FunC builders — including the mindset shift Tolk encourages.

... And several articles for experienced divers. They reveal compiler internals and the language philosophy. My favourite — Stop thinking in TL-B.

㉈ Hundreds of examples

Every distinct aspect is covered with usage examples — properly highlighted in both light and dark mode.

No matter whether you are new to TON or have been here for years — you'll definitely find a few tricks you've never seen before.

∞ This documentation in numbers

All together, the new Tolk documentation contains:
• 46 pages
• 480 snippets
• 40000 words
• 280000 characters

I invested ~200 hours developing the text and picking every word.
I hope that, cumulatively, this documentation will save noticeably more time for all TON developers.

→ Start reading

https://docs.ton.org/languages/tolk

🌳 Thanks to everyone who reviewed the pull request and pointed out occasional mistakes or misprints. Just imagine the amount of content they had to deal with.

🫧 Tolk v1.3... not released yet: what's happening inside

I know it has been quiet.

The last public Tolk update was three months ago, so the question is fair:

❓ Where did I go, and why is there still no v1.3?

I did not disappear. I have been working on something much bigger than the next language release.

A huge part of my focus has shifted toward building a TON toolchain together with the team.

Not another small utility. Not another isolated CLI. A full development environment built as one coherent system — around Tolk.

⚙️ So what do I mean by a toolchain?

The core of TON development. A single tool that:

✔ Scaffolds real projects. Contracts, unit tests, integration tests, TypeScript wrappers, and ready-to-use templates.

✔ Runs tests. 50x faster than the current JS sandbox. And even more: tests are native, no Node.js required.

✔ Gives you a real debugger. Test failed with exit code 9? Stop exactly at the exception, inspect the call stack, local variables, lazy fields, and more. One thing I am especially proud of: there is no "compile without optimizations" mode. It works with fully-optimized production contracts.

✔ Visualizes transaction flows. Run a test and immediately see the full chain of generated transactions in a clean local UI.

✔ Covers the rest of the workflow too: code coverage and gas profiling; formatter and language server; verifier and ABI generation; all of it AI-friendly, with agent skills and MCP built-in.

✅ The goal is to reboot development on TON

When Tolk appeared, it made FunC feel like the old world. Tolk is not just "a bit better" — it feels like a different era.

Now we are doing the same for the entire on-chain development stack. Not just to improve existing tools a little — but the current approach will feel fundamentally outdated.

🌳 I originally planned to announce all of this at TON Gateway. But it was cancelled, so I am lifting the curtain a little earlier.

The timeline has not changed: early May.

And early May is very close.

🫧 Tolk v1.3: moving toward a general-purpose language

After the previous post, this release may feel less surprising — but still a bit unusual.

The reason is simple: Tolk is no longer evolving only as a contract language. It is becoming a foundation for the toolchain I described earlier.

This release focuses on features beyond contracts — introducing general-purpose capabilities needed for libraries and frameworks.

✅ Notable changes in Tolk v1.3:

1. Type array<T> — dynamically sized arrays backed by TVM tuples.
2. Type unknown — a TVM primitive with unknown contents.
3. Type lisp_list<T> — nested two-element tuples (FunC-style).
4. Type string — text chunks backed by snaked cells, with StringBuilder for concatenation.
5. Compile-time string methods: "str".crc32(), "str".sha256(), etc.
6. Null coalescing operator — ?? like in TypeScript.
7. Import path mappings — import "@third_party/utils".
8. Compile-time reflection via @stdlib/reflection.
9. Custom serializers now support structures and generics.
10. The compiler now reports multiple errors at once.
11. Focused on stability — fixed dozens of minor issues found by LLM fuzzing.
12. Extensive internal refactoring towards being stateless and multi-threaded.

PR on GitHub with detailed info.

✔ Arrays: redesigned tuples

Working with TVM tuples has been fully redesigned. There is now array<T> — a dynamically sized container:

// array<int>
var numbers = [1, 2, 3];

// array<Point?>
var optPoints = [
    Point { x: 10, y: 20 },
    Point { x: 30, y: 40 },
    null,
];

- methods push, get(idx), etc.
- any T, including sub-arrays like array<array<int>>
- automatically serialized into snake cells
- max size: 255 (TVM limitation)

✔ The `unknown` type

Raw TVM tuple exists, but it's no longer built-in. It's just an array... of something unknown:

type tuple = array<unknown>

The unknown gives access to the untyped TVM stack, fully integrated into the type system.

✔ The `string` type

TVM has no strings — only binary slices. Strings were always just a convention over binary data.

Now Tolk has strings built-in.

// string
val str = "hello";

- strings are cells (not slices)
- long strings are snake cells under the hood
- methods calculateLength, equalTo, etc.
- on-chain/off-chain encoding for jettons and NFTs to comply with TEPs

StringBuilder encapsulates cell manipulation:

StringBuilder.create()  
    .append(content.commonContent)  
    .append(individualNftContent)  
    .build()

By the way, compile-time functions now look cleaner: "str".crc32() and so on.

✔ Import path mappings

The import statement now accepts @aliases:

import "@common/jettons"
import "@third_party/math-lib"

This is similar to widely used path mappings in TypeScript.

✔ Compile-time reflection

Many additions in v1.3 make sense not for contracts, but for frameworks. For example, take a look at one of reflect features:

fun log(msg: string, loc: SourceLocation = reflect.sourceLocation()) {
     debug.print(loc.lineNo);
}

fun demo() {
     log("a");    // prints K — current line no
     log("b");    // prints K+1
}

Why is this useful? It allows errors to point to the original call site — for example, expect(...) in tests — by carrying source location at compile time.

⚙️ A huge portion of internal refactoring

A lot of work has been done inside the compiler core, peephole optimizations, and memory management.

Final result: tolk compiler is now thread-safe and re-invokable within a single process. It will be embedded into an external toolchain written in Rust, communicating via FFI.

... And more

Dozens of independent improvements. Combined, they cover the requirements not only for contracts, but for abstract libraries and the upcoming toolchain.

Feel free to check the description on GitHub.

🌳 And one more thing! Wallet-v5, compiled with Tolk v1.3, reduces gas usage by 30% compared to FunC. As of Tolk v1.0, the savings were "only" 20%. Take a look at new benchmarks.

🫧 TON enters a new era of smart-contract development

I promised this would happen in May.

Today we release:

• Tolk v1.4
• Acton — a unified toolchain for TON smart contracts

For more than half a year, we have been building this almost entirely in secret.

And honestly, this is the biggest release we have ever shipped at once.

⚙️ What is Acton?

Acton is an all-in-one CLI built around Tolk — a modern replacement for the fragmented tooling stack TON has today.

✓ Write tests directly in Tolk — including transaction flows and cross-contract interaction. 50x faster than current Sandbox + TypeScript approach.

✓ Automatic TypeScript wrappers. But not for tests! For end-to-end dApp/frontend integration.

✓ A native debugger. Step in, step over, step out, watch variables, and inspect the call stack. A smooth Web2-style developer experience — now inside a Web3 ecosystem.

✓ Entire contract lifecycle. Develop, deploy, verify, configure, and interact with contracts on-chain. Acton manages wallets and faucet top‑ups on testnet.

✓ Security built in. Coverage, fuzzing, mutation testing, gas profiling, and CI help catch regressions early.

🤖 Friendly for AI agents

One interesting thing we discovered while building Acton: good tooling for humans naturally becomes good tooling for AI.

We designed Acton for ourselves first. Every command, every flag, every workflow — polished to feel coherent and predictable.

And it turned out that agents thrive in exactly this kind of environment.

CLI-first by design, Acton becomes an agent's runtime — with structured commands, built-in skills and manuals.

🛠️ Tolk v1.4 as the foundation

None of this would be possible without the kernel behind it all: the compiler itself.

Tolk v1.4 allows external tools to finally understand the contract.

1. It emits ABI — describing how the contract is "seen" by the outside world. Explorers, frontend UI and TypeScript wrappers naturally build on top of ABI.
2. It emits source maps — allowing TVM execution to map back to Tolk source code, local variables, stack layout, and call frames.
3. It enables debugging WITHOUT bytecode modifications — for fully optimized production contracts.

This is an extremely non-trivial problem technically. But it works.

And here is the crazy part:

you can take a failed transaction from the real mainnet — and debug it step-by-step locally in your IDE.

As always — PR on GitHub with detailed info.
As always — very long and caring.

🪐 Where does it all lead?

We have prepared detailed documentation for dozens of Acton features — both for experts and newcomers.

But I am not inviting you to read it.

Instead, I am inviting you to the landing page.

Carefully designed. Written from scratch. A distilled form of the last 7 months of work.

It contains 7 videos.

Open it on desktop.
Turn on the sound.
Watch the videos.

Feel the technical depth hiding behind all this simplicity.

https://ton-blockchain.github.io/acton/

When you're ready —
Act on