🫧 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