🫧 Tolk v0.11: type aliases, union types, and pattern matching

This update might confuse you at first. You may wonder: "Why do we need this? How will it be useful?". But in the end, you'll see how everything comes together bringing seamless and generalized message handling.

✅ Notable changes in Tolk v0.11:

1. Type aliases type NewName = <existing type>
2. Union types T1 | T2 | ...
3. Pattern matching for types
4. Operators is and !is
5. Pattern matching for expressions
6. Semicolon for the last statement in a block can be omitted

PR on GitHub with detailed info.

✔ Type aliases

Tolk now supports type aliases, similar to TypeScript and Rust.

type UserId = int32;
type MaybeOwnerHash = bytes32?;

An alias creates a new name for an existing type but remains interchangeable with it. No performance overhead — a compile-time feature.

✔ Union types `T1 | T2 | ...`

They now allow a variable to hold multiple possible types.

fun whatFor(a: bits8 | bits256): slice | UserId { ... }

var result = whatFor(...);  // slice | UserId

Nullable types T? are now formally T | null.

At the TVM level, union types work as tagged unions — similar to Rust enums but more flexible.

✔ Pattern matching

The only way to work with union types is matching them:

match (result) {
    slice  => { /* result is slice here  */ }
    UserId => { /* result is UserId here */ }
}

Matching is based on smart casts — inside each branch, the variable is automatically narrowed to the matched type.
 
It can also be used as an expression:

type Pair2 = (int, int);
type Pair3 = (int, int, int);

fun getLast(tensor: Pair2 | Pair3) {
    return match (tensor) {
        Pair2 => tensor.1,
        Pair3 => tensor.2,
    }
}

So, `match` + smart casts are our way for union types. You may notice that it's close to enums in Rust. But we don't have enum. Union types are more general and powerful.

✔ `match` for expressions

val nextValue = match (curValue) {
    1 => 0,
    0 => 1,
    else => -1
};

As you see, match also works for constant expressions, similar to switch in other languages.

✔ Union types and TL/B `Either`

T1 | T2 will be directly mapped to TL-B (Either T1 T2).
Look how clean this is: (Either SmallPayload LargePayload) becomes

struct StoragePart {
    data: SmallPayload | LargePayload;
    // (de)serialized as '0' + ... or '1' + ...
}

match (s.data) {
    SmallPayload => ...
    LargePayload => ...
}

No need to manually handle bits from the slice — it's naturally expressed in the type system!

✔ Union types and TL/B constructors

T1 | T2 | ... is a typed way to describe multiple constructors from TL/B. Generally, they can be used anywhere inside a storage or a message.

Moreover — handling incoming messages is beautifully expressed with union types.

✔ Union types and future structures

The ultimate goal? You'll describe each incoming message as a struct, create a union type for them, parse a slice, and just match over variants:

// don't mind about opcodes yet
struct CounterIncBy { byValue: int32 }
struct CounterReset {}
struct ... other messages

type IncomingMessage = CounterIncBy | CounterReset | ...;

// ... after parsing a message
match (msg) {
    CounterIncBy => {
        newCounter = curCounter + msg.byValue
    }
    CounterReset => {
        newCounter = 0
    }
    ...
}

🌳 So, union types (that perfectly work with tensors) will seamlessly work with structures. With union types, you will declare both Either and different kinds of messages. Combined with intN and other types, they will allow to express (almost) any practical TL/B construction. They are not limited to message routing — in other words, message routing does not differ from handling any field, any storage, or any cell in general.

📝 Sign Arbitrary Data with TON Connect

The latest update to our TON Connect implementation introduces a powerful new feature: the ability to sign arbitrary data — from plain text and binary blobs to BOC (cell) format.

This unlocks new use cases in the TON ecosystem: secure off-chain flows, verifiable signatures, and advanced on-chain logic — all through the familiar TON Connect interface.

Now supported in the latest versions of Tonkeeper on iOS and Android.

Explore the guide and start building →

🎉 Welcome Challenge: A Tact Developers Competition!

DivaTech is launching TON Contests — a platform for hosting competitions for TON smart contract developers.

To celebrate the launch, we’re kicking off our first contest — Welcome Challenge with a $1000 prize pool!

You’ll face 5 easy-to-medium-level tasks in Tact smart contract development, with 6 hours to solve them.

📅 When: April 13, 3:00 PM – 9:00 PM (GMT+3)
🌍 Where: Online at toncontests.com

🏆 Prizes:
🥇 Top 5: $100 each
🥈 Next10: $35 each
🥉 Next 15: $10 each

Registration for the Welcome Challenge is now open

🎉 Tact v1.6.6 is released!

The final patch release of this v1.6 series is upon us, and it brings a significant tooling improvement, amongst other things. Meet the official Tact formatter — a new tool that ensures consistent code style across your Tact projects. It ships with Tact v1.6.6, and you can run it in your projects via npx tact-fmt or by invoking a format command in your editor. You'd need to install the Tact's language server or the VSCode extension for that — see the tact-language-server repo for details.

The v1.6.* series of patches has been a journey of refinement and polish, setting the stage for what's coming next. As we close this chapter, we're already working hard on exciting new features for the future.

For now, let's explore the Tact v1.6.6 release:

🧰 Standard library additions and changes

• Added compute phase exit code constants reserved by the Tact compiler, such as TactExitCodeNullReferenceException (128) and many others.

• Added the SignedBundle struct and the corresponding verifySignature method.

• Added sendRawMessage and sendRawMessageReturnForwardFee functions as replacements for their deprecated counterparts.

• Optimized the sha256() function to about ~270 less gas used per call and added the keccak256() function that works with arbitrarily long slices.

🛠 Bug fixes

There were a lot of those. Remember that last time we started fuzzing the compiler with LLMs to root out bugs? Well, we found many bugs that way and fixed even more — many error messages got way more informative and useful. Some bug fixes allowed for seemingly unrelated UX improvements too.

One nice example of a second-order fix would be that the require() function now supports constants as its second parameter. You no longer need to provide identical string literals everywhere — define a string constant somewhere and reuse it!

See the full release notes for a long list of bugs squished and error messages improved.

✍️ Documentation updates

• Added a "Learn Tact in Y minutes" page, which gives a whirlwind code-first tour of the Tact language.

• Any AI vibe coders out there? The docs now generate llms.txt, llms-full.txt and llms-small.txt files for you to use with your AIs. The small version is particularly interesting as it fits in the 200k context.

• The "gas best practices" page got updated with new recommendations, such as specialized math functions or the BasechainAddress struct and related functions.

• Lots of examples fixed, with more fixes to arrive as we speak.

🧳 Formatter!

You can run it via npx tact-fmt in your projects — it supports checking the formatting via the --check flag, applying fixes via the --write flag, and can check both individual files and directories of files.

Furthermore, it also ships with our official language server and VSCode extensions. See the tact-language-server's README.md for installation details.

📜 See the full release notes for Tact v1.6.6
📥 And upgrade Tact in your projects

In about 4 days from now, on April 21 at 12:00 (UTC+3), the Tact Smart Battle will begin! It is the ultimate smart contract challenge powered by Tact and organized by TON Studio & Codeforces. The prize pool is $20,000 in Toncoin, and the top 128 participants will receive exclusive Soulbound Tokens (SBTs). Moreover, the best battlers will be invited for job interviews at TON Studio.

And all participants with valid solutions would also receive a Participant SBT.

👉 Register, if not already: Codeforces
• Here's the registration guide, just in case: Notion
• Hop in the community chat to ask questions, receive support and have fun learning and using Tact: @tact_smart_battle

🍲 flint and tact
♨️ @tact_kitchen from the @ton_studio

🫧 Tolk v0.12: structures, generics, and methods

Finally! Or maybe not yet?

This update brings Tolk one step closer to its final form by introducing:

✅ Notable changes in Tolk v0.12:

1. Structures
2. Generics
3. Methods
4. Stdlib with short naming
5. Fift output enhancements

PR on GitHub with detailed info.

✔ Structures

Looks like TypeScript — but works in TVM!

struct Point {
    x: int;
    y: int;
}

fun calcMaxCoord(p: Point) {
    return p.x > p.y ? p.x : p.y;
}

// declared like a JS object
var p: Point = { x: 10, y: 20 };

// called like a JS object
calcMaxCoord({ x: 10, y: 20 });

Point a just named tensor — identical to (int, int) at the TVM level.

Key features:
- Compiler guesses what you mean — automatically:

fun loadData(): StoredInfo {
    return {
        counterValue: ...,
        ownerAddress: ...,
    }
}

- Works with shorthand syntax { x, y }
- Default values for fields are supported
- Nested objects are supported
- No overhead for single-field structs over a plain value
- Nullability, smart casts, union types, all language features — everything works

✔ Generics

They exist only at the type level (no runtime cost):

struct Nullable<T> {
    item: T? = null;
}

The type system becomes powerful enough to express complex scenarios:

struct Ok<TResult> { result: TResult }
struct Err<TError> { err: TError }

type Response<R, E> = Ok<R> | Err<E>;

match (r) {
    Ok => { r.result }
    Err => { r.err }
}

✔ Methods — for any types

For structures:

fun Point.getX(self) {
    return self.x
}

fun Point.create(x: int, y: int): Point {
    return { x, y }
}

Or extend built-in types:

fun slice.load32(mutate self): int32 {
    return self.loadInt(32);
}

Or — tensors, unions, generics, even "any receiver". A method is just an extension function with predictable resolution rules.

✔ stdlib — with short methods naming

// before
someCell.cellHash();
someTuple.tupleSize();
someBuilder.getBuilderBitsCount();

// now
someCell.hash();
someTuple.size();
someBuilder.bitsCount();

Even more — some global functions are now static methods:

// before
getMyAddress();
setContractData(c);
getLogicalTime();

// now
contract.getAddress();
contract.setData(c);
blockchain.logicalTime();

It looks pretty, and since IDE suggest only available methods after dot, it's extremely useful. For a full list of renamings, consider documentation.

✔ A long-awaited bonus for Fift ninja

Look at the PR and enjoy how readable Fift assembler output is. Yes, it contains original .tolk lines as comments! And yes, it works perfectly.

🌳 You now see how Tolk's features are aligning together towards automatic serialization, fully described by the type system. Cell references, constructor prefixes, message sending, and other use cases will be expressed with the features above.

🫧 Tolk v0.13 (Release candidate): Auto-packing to/from cells

We've finally reached the point we've been working toward for the past six months: automatic (de)serialization of anything into cells. From simple structs to unions, generics, and even nested references — it just works.

The goal? To replace TL/B entirely with declarative, type-safe definitions. The compiler takes care of packing, loading, estimating, error handling, and more.

✅ Notable changes in Tolk v0.13:

1. Auto-packing to/from cells/slices/builders
2. Type address
3. Lateinit variables, default parameters, and other minor features

PR on GitHub with detailed info.

✔ Auto-serialization: short demo

struct Point {
    x: int8;
    y: int8;
}

var value: Point = { x: 10, y: 20 };

// makes a cell containing "0A14"
var c = value.toCell();   
// back to { x: 10, y: 20 }   
var p = Point.fromCell(c);

Key features:

* supports all types: unions, tensors, nullables, generics, atomics, ...
* allows to specify prefixes (particularly, opcodes)
* allows to manage cell references and when to load them
* lets you control error codes and other behavior
* unpacks data from a cell or a slice, mutate it or not
* packs data to a cell or a builder
* warns if data potentially exceeds 1023 bits
* more efficient than manual serialization
* will seamlessly integrate with message sending/receiving in Tolk v1.0

✔ Pack or unpack — anywhere

T.fromCell, T.fromSlice, slice.loadAny<T>, builder.storeAny<T>, and other methods give both high-level and low-level API.

// low-level is allowed:
beginCell()
  .storeUint(1, 32)    // mix manual
  .storeAny(myStruct)  // with auto

✔ Serialization prefixes and opcodes

struct (0x7362d09c) TransferNotification {
    queryId: uint64;
    ...
}

They are not limited to 32 bits — you can describe any TL/B constructors:

struct (0b001) AssetSimple { ... }
struct (0b100) AssetBooking { ... }
type Asset = AssetSimple | AssetBooking | ...;

✔ Typed cells

struct A {
    ref1: cell;          // untyped ref
    ref2: Cell<Inner>;   // typed ref
    ref3: Cell<int256>?; // maybe ref
}

Typed cells give you full control over when content is unpacked — nothing is loaded unless you call .load() manually:

a.ref2.field         // error
a.ref2.load().field  // ok

// Yes, point.toCell() really gives you Cell<Point>

✔ Granular options

Accurately adjust serialization behaviour (for example, error codes):

Point.fromSlice(s, {
    assertEndAfterReading: false
})

✔ Built-in type `address`

struct Wallet {
    owner: address;
}

* integrated with auto-serialization, while still a slice under the hood
* comparable: if (senderAddress == wallet.owner)
* introspectable: isInternal(), getWorkchain(), etc.

✔ Some other features

Described in detail in the full changelog and mirrored in the documentation.

🌳 We're just a couple of steps away from Tolk v1.0 — with message sending and handling, gas optimizations, and one secret feature. There is still a lot of work ahead, but today we're closer to the release than ever before.

🎉 Tact Language Server & VS Code Extension v0.8.0 are live!

Smarter code insight, TL-B support, fresh UI touches and a faster, quieter indexer — all wrapped into v0.8.0 release!

🚀 Headline features

Flexible toolchain picker – point the extension at any local Tact toolchain and switch them on the fly.
TL-B first-class citizen – syntax highlighting, completions, document symbols, go-to-references and inline highlighting inside Tact comments.
Next level navigation – search for functions by type, easily navigate with code lenses with go-to places where messages were sent and received
Fresh inspections – CanBeInline (with quickfix), DeprecatedSymbolUsage, MissedMembersInContract (with quickfix), NamingConvention, OptimalMathFunctions.

📜 And that's not all 😎, check out our changelog to find all the improvements and fixes in the new release!
Also check out X/Twitter thread with announcement.

📥 Upgrade now

Via VS Code marketplace
or Open VSX

Happy hacking! 🛠️✨

🍲 intelli-tact, you're next
♨️ @tact_kitchen from the @ton_studio

🫧 Tolk v0.99: universal message composition

This update introduces a high-level, type-safe way to compose and send messages to other contracts.

No more manual beginCell().storeUint(...).storeRef(...) boilerplate. Just describe the message in a literal, and let the compiler do the rest.

✅ Notable changes in Tolk v0.99:

1. Universal createMessage – control body, extra currency, stateInit, and more
2. Universal createExternalLogMessage — emit logs efficiently
3. Sharding — calculate addresses "close to another contract"

PR on GitHub with detailed info.

✔ createMessage: short demo

val reply = createMessage({
    bounce: false,
    value: ton("0.05"),
    dest: senderAddress,
    body: RequestedInfo { ... }
});
reply.send(SEND_MODE_REGULAR);

Key features:

1. Supports extra currencies
2. Supports stateInit with automatic address computation
3. Supports different workchains
4. Supports sharding (formerly splitDepth)
5. Integrated with auto-serialization of body
6. Automatically detects "body ref or not"

✔ Union types as the foundation

Almost every field is a union — flexible API while staying strictly typed:

// value: either tons, or tons + extra currencies
value: ton("1.5")
value: (ton("1.5"), extraDict)

// destination: various forms
dest: someAddress
dest: (workchain, hash)

✔ Body: inline or ref?

Don't think about refs — the compiler does:
- small structs are inlined
- large ones are wrapped in a ref
- detected at compile-time — no runtime checks

// any serializable struct — no toCell!
body: RequestedInfo { ... }

Don't need body? Just leave it out.

✔ Deployment: a variant of "destination"

dest: {
    workchain: BASECHAIN,
    stateInit: { code, data },
}

The beauty of TON is that it doesn't have a dedicated deployment mechanism. You just send a message to some void — and if this void doesn't exist, but you've attached a way to initialize it — it's initialized immediately, and accepts your message.

✔ Sharding!

Built-in features to calculate an address "in the shard of contract B."

dest: {
    ...
    toShard: {
        fixedPrefixLength: 8,
        closeTo: ownerAddress,
    }
}

Perfect for optimized sharded jettons. All the hashing, StateInit packing, and bit-level work is done automatically.

⚙️ What about gas costs?

Even with all this flexibility, createMessage is not bloated. The compiler unfolds all union branches and constant conditions at compile time, producing flat, minimal code — often more optimal than hand-crafted cell composition.

❓ v0.99? So, what's next?

Yes, it's the last version before the final release. Tolk now covers the entire initial roadmap and is ready for real-world use. On top of that, we'll add several compiler optimizations and rewrite standard contracts from FunC to Tolk — to demonstrate how exactly everything ties together.

📣 TON Developers — we need your feedback!

Help us shape the future of TON development. We’ve prepared a detailed survey to understand your experience with:
🧠 Smart contract languages (Tact, Func, Tolk)
📚 Documentation and education
🛠 SDKs, IDEs, and tools
🤖 Telegram Mini Apps
💬 Developer support and pain points

💎 As a thank you, we’ll issue an SBT (Soulbound Token) to your wallet as proof of contribution to the ecosystem.

👉 Take the survey here:
https://docs.google.com/forms/d/e/1FAIpQLSfDm85Z7YxDw96nMeV9T-b2kmd2qAe8xt0_iag8ZqrgqKuCRw/viewform

🕐 Takes 5 minutes. Every voice matters.
Let’s build a better TON together.

⚠️ If you are still using tonutils-go version below 1.13, you should update ASAP, because after mainnet update GetAccount method becomes incompatible due to changes in blockchain account schema, so your service may stop working.

This method is also used during wallet interraction and sending transactions.

https://github.com/gobicycle/bicycle/releases/tag/v0.10.1

Important update!
Changes will soon be applied to the Mainnet that will disrupt some services (including Bicycle). A new version v0.10.1 has been released to support these changes. To maintain the functionality of bicycle, it is recommended to update as soon as possible.

🫧 Tolk v1.0: lazy loading, partial updating, AST inlining — and extremely low gas fees

This is happening today.

I managed not only to finish up the compiler, but also to migrate standard contracts from FunC to Tolk.

I covered every contract with gas metrics to check whether it's more efficient than FunC or not. I didn't believe my eyes. I double-checked, triple-checked, but nothing changed. The results are correct. And now I am ready to present them to you.

🧪 Benchmarks!

Every contract has several metrics. For example, "basic jetton — mint".
FunC: 19278. Tolk: 11611.
Gas savings: -39.77%

|————————————————–-
| 01 — Jetton (mint, transfer, burn, discover)
| -39.77% | -30.32% | -33.66% | -26.75%
|————————————————–-
| 02 — NFT (deploy, transfer, onchain get)
| -43.79% | -37.47% | -44.28%
|————————————————–-
| 03 — Notcoin
| -35.72% | -27.98% | ...
|————————————————–-
| 04 — tgBTC
| -23.94% | -26.99% | ...
|————————————————–-
| 05 — Wallet v5
| -21.66% | -22.92% | ...
|————————————————–-
| 06 — Vesting
| -45.30% | -29.61% | ...
|————————————————–-
| 07 — Telegram gifts
| -54.81% | -39.39% | ...
|————————————————–-

I have migrated 7 contracts — preserving the original behavior and passing the same tests.

All benchmarks are open. No cheating. Just a smart compiler — and a language designed to be optimized.

— Even wallet?! But it's very low-level and tricky!

Even wallet. You just express your thoughts without any tricks — and it works automatically.

— But how? How is it possible to achieve such numbers?

Of course, I've put a lot of smartness into the compiler. A strong type system. Automatic inlining. Built-in serialization. The magic lazy keyword.

But first of all, Tolk is built for readability. These contracts aren't "just cleaner" than their FunC equivalents — they're elegant. No magic. No low-level intrigues. Just clean, consistent logic — whether it's a Jetton or a Wallet.

And gas savings? They are a consequence. I didn't micro-optimize. Each contract was rewritten in about a day — just focusing on clarity. The core principle is simple: once you make it elegant, it automatically becomes efficient.


✅ Notable changes in Tolk v1.0:

1. Lazy loading — only read what you actually use
2. AST-based inlining — zero-cost getters and methods
3. Peephole optimizations, TVM-11 — smaller code, lower gas

PR on GitHub with detailed info.

Just take a look:

val st = lazy Storage.load();
// the compiler skips everything and loads only what you access
return st.publicKey;

That's it. Lazy loading and partial updates (calculating immutable slices for writing) — one magic lazy keyword to rule them all.

⚙️ The Release. What's inside

- JetBrains IDE plugin — with completion, resolving, etc... ✓ done
- VS Code Extension — with suggestions, stdlib integration, etc... ✓ done
- Language server — for any LSP-compatible editor... ✓ done
- FunC-to-Tolk converter — migrate a project in 10 seconds... ✓ done
- Documentation — for smooth transition from FunC... ✓ done

And the TOLK language itself — exactly as I've visioned it... 7 months ago


📅 The essence of Numbers

At this moment, abstract yourself from the text. Take a look at the calendar.

Today is 07/07/25 (I mean 2+5, of course).

After the TON Gateway, throughout all November, I was laying out the roadmap towards Tolk v1.0. On December 1, I started working. It means, that the journey till now took exactly 7 months 7 days. If you scroll this channel to the top, you'll see an announcement... Of Tolk v0.7

🪐 What's next?

I could have written about my plans — for the language, TVM, ABI, TypeScript wrappers... but I won't.

Because today, instead of rushing into the future, maybe we can allow ourselves to look back.
To pause the endless race — just for a moment.
To notice how many beautiful coincidences pass us by — unnoticed in our constant hurry.

Just step outside.
Close your eyes.
Count to seven.
Feel it.

When you're ready —
Let's Tolk