🔨Dev tools updates

Recently new versions of blueprint, sandbox, test-utils, and create-ton have been released. The most important (and breaking) change is the fact that since blueprint v0.28.0 compilers (func-js, tolk, tact) have become peer dependencies. This means that you can pick and choose any compiler version that you need, as long as its API is compatible with what blueprint expects, but this also means that you need to have them listed in your package.json. If you're creating a new project using create-ton, it will add compiler dependencies automatically. If not and if you're upgrading blueprint in an old project, you will have to install compilers yourself, you can use the template's package.json for reference.

Changes to sandbox and test-utils include better support for extra currencies, which might be of use due to the recent developments in TON.

Telegram and TON Make it Exclusive!

All mini-app developers in Telegram will now exclusively use TON as their blockchain infrastructure. All mini-apps that do not currently use TON should migrate within the next 30 days. TON Connect - TON's Wallet authentication protocol in Telegram - will be the sole wallet connect protocol for every Telegram Mini App, excluding bridging scenarios.

Telegram and TON have updated their documentation, and TON Foundation is giving TG Ads grants to projects who will migrate within the next 30 days to help them get a good start in TON Ecosystem. Check out the grant program and developer guidelines here!

To learn more about this step forward head over to our latest blog article.  

🚀 Tact v1.5 Audited by Trail of Bits

The security audit for Tact v1.5 has been completed by Trail of Bits, a leading Web3 security firm.

✅ No high-severity vulnerabilities were found.

🔧 Some bugs and points of improvement were discovered and addressed in a new Tact v1.5.4 bugfix release.

Thanks to Trail of Bits for their thorough review!

The report can be accessed at the Trail of Bits GitHub repo: https://github.com/trailofbits/publications/blob/master/reviews/2025-01-ton-studio-tact-compiler-securityreview.pdf

⚡️ In the meantime we continue to improve Tact with new language features, gas optimizations (a lot of those lately!), and enhancements to the compiler’s reliability. This ensures a secure and efficient development experience on TON Blockchain.

👉 Upgrade to Tact 1.5.4, if not already: https://docs.tact-lang.org/book/compile/#upgrades

🍲 cooking with great care for performance and users
♨️ @tact_kitchen

TON Core: Report for December-January

48 updates, from small to huge. Moving along the roadmap: first part of the Accelerator, new tools for validators, TVM sidechains, new versions of TOLK and API, support for extra currencies and BTC Teleport, and other.

https://telegra.ph/TON-Core-Dec-Jan-2025-Updates-02-02

Tolk v0.8: preparation for structures

A new version of Tolk was released several days ago. We're starting a way to eventually implement structures with auto packing to/from cells. This will take several steps (each publicly released), it's the first one.

✅ Notable changes in Tolk v0.8:
1. Syntax tensorVar.0 and tupleVar.0, both for reading and writing
2. Allow cell, slice, etc. to be valid identifiers

PR on GitHub with detailed info.

Using syntax `tensorVar.{i}` and `tupleVar.{i}`, you can access tensors/tuples by indices without unpacking them.

It works for tensors:

var t = (5, someSlice, someBuilder);   // 3 stack slots
t.0                     // 5
t.0 = 10;               // t is now (10, ...)
t.0 += 1;               // t is now (11, ...)
increment(mutate t.0);  // t is now (12, ...)
t.0.increment();        // t is now (13, ...)

t.1         // slice
t.100500    // compilation error

It works for tuples (does asm INDEX/SETINDEX under the hood):

var t = [5, someSlice, someBuilder];   // 1 tuple on a stack with 3 items
t.0                     // "0 INDEX", reads 5
t.0 = 10;               // "0 SETINDEX", t is now [10, ...]
t.0 += 1;               // "0 INDEX" to read 10, "0 SETINDEX" to write 11
increment(mutate t.0);  // also, the same way
t.0.increment();        // also, the same way

t.1         // "1 INDEX", it's slice
t.100500    // compilation error

It works for nesting var.{i}.{j}. It works for nested tensors, nested tuples, tuples nested into tensors. It works for mutate. It works for globals.

Why is this essential?

In the future, we'll have structures, declared like this:

struct User {
    id: int;
    name: slice;
}

Structures will be stored like tensors on a stack:

var u: User = { id: 5, name: "" };
// u is actually 2 slots on a stack, the same as
var u: (int, slice) = (5, "");

fun getUser(): User { ... }
// on a stack, the same as
fun getUser(): (int, slice) { ... }

It means, that `obj.{field}` is exactly the same as `tensorVar.{i}`:

var u: User = ...;   // u: (int, slice) = ...
u.id;                // u.0
u.id = 10;           // u.0 = 10

Same goes for nested objects:

struct Storage {
    lastUpdated: int;
    owner: User;
}

s.lastUpdated        // s.0
s.owner.id           // s.1.0

So, implementing indexed access for tensors/tuples covering all scenarios is a direct step towards structures.

🚀 Bring TON to ElizaOS – Join the Bounty Program!

TON Blockchain is launching a bounty program to develop the TON Plugin within ElizaOS! This is your chance to contribute to a cutting-edge AI framework and integrate TON into autonomous AI agents.

$20,000 in prizes is up for grabs! Contribute by implementing key features and earn rewards for successfully merged pull requests.

💡 How to participate: take on one of the open issues:
👉 List of open TON Plugin bounties

⚡ Act fast! Don’t miss out on this opportunity to bring TON and AI together!

📝 TON devs — we need your feedback!

Building on TON? Tell us what works (and what doesn’t) in a quick survey on:

• Developing on TON, tooling, programming languages (FunC, Tact, Tolk), TMAs, guides

Fill it out, drop your wallet & claim an exclusive reputation SBT!

Make your voice count. 

Support for extra-currencies in local ton-http-api

In ton-http-api v2.0.53, which you can install by yourself on your server, support for extra-currencies and a number of other improvements have been made.

Recall that earlier support for extra-currencies was made in the public Toncenter V2 and Toncenter V3 APIs.

https://github.com/toncenter/ton-http-api/releases/tag/v2.0.53

Improved Metadata API

Last month we started providing metadata for Jettons and NFTs in the V3 API.

We are pleased to report a number of improvements:

— The metadata now enters the API in advance as soon as the token appears on the network. In the previous implementation, the metadata was indexed the first time the token was requested.

— Images and JSON are now proxied via toncenter.com. 3 image sizes are available, as well as original non-proxied urls for JSON and images. IPFS is supported.
Using a proxy increases security (you don't make requests to third-party hosting) and speed of downloading resources.

🎉 Tact v1.6.0 is released!

🏆 This is the biggest update of Tact since its creation, bigger than all previous milestones combined. There were so many improvements that we've even won over FunC in terms of gas usage on many standard contracts, such as Jettons.
🤔 Don't believe me?
🥳 Let's unpack Tact v1.6.0 together and see these improvements for ourselves!

We'll start with the number one achievement of this release:

⛽️ Gas optimization victory over FunC

Gas has long been a major pain point for Tact. Prior to v1.6.0, Tact's gas usage on many common contracts, such as Jettons, was far from ideal, requiring about 2.5 times gas of the FunC reference implementation.

But with Tact 1.6.0, those old gas-expensive days are long gone.

🤯 For example, a Tact rewrite of the reference FunC Jetton code consumes less gas for transfer, burn and discovery messages!
😎 So, expect to receive easy-to-use idiomatic Tact implementations of common contracts in the near future

Some of the things we did to achieve this:
▪️ Removed "system" cell — parent contract code is no longer stored in the system cell with all the child contract codes
▪️ Removed redundant address checks
▪️ Deprecated Deployable trait in favor of receive(){}
▪️ Introduced contract parameters as an alternative to init() function

And optimized compiler internals, many old and new functions in the stdlib:

🧰 Some of the standard library additions and changes

• Added specialized deploy and message functions for efficient on-chain deployments and non-deployment messages respectively
• Many math functions, such as divc, mulShiftRightCeil, and others
• More advanced functions, such as setGasLimit, setSeed, myCode, and others
• Handy throwIf and throwUnless functions, which deprecated their "native" prefixed counterparts
• Optimized emptyCell and emptySlice functions
• Int.toString function now consumes up to 64% less gas
• Int.toFloatString function now consumes up to 62% less gas

Added many functions for Cell, Slice and Builder types:
• Variable integer serialization types and the corresponding .load and .store functions of Slice and Builder types
• Functions Slice.hashData and String.hashData for efficient hashes of data only
• Functions for working with addresses: Slice.asAddress, Slice.asAddressUnsafe, contractHash, and a new BasechainAddress type its helper functions
• ...and more!

🧳 More auxiliary things

• Basic let-destructuring of structs and Messages
• Compile-time method ID expressions for getters and Message opcodes
• The codeOf expression to get the code of child contracts
• More map improvements and new methods, like replace and replaceGet
• New augmented assignment operators &&=, ||=, >>= and <<=
• Better error reporting for many cases
• Generation of constants in TypeScript wrappers
• The -w, --watch CLI flags for watching for changes and automatic recompilations
• CLI for the Tact's TVM disassembler — unboc
• Fixes of the compilation report
• Fixes of the compiler's third-party API
• Fixes of the internal infrastructure and code generation
• Lots of other miscellaneous bug fixes and smaller enhancements
• ...and documentation for all of that and beyond!

Besides, check out the updated Awesome Tact list and add your awesome projects, especially those using Tact in production!

⚠️ Breaking changes

There are only two, and they're both pretty minor:

• Tact 1.6.0 replaces Context.bounced field with Context.bounceable, which tells whether the received message can bounce back or not. Previously, the bounced was useless since any bounced messages would be handled in a separate bounced() receiver.

• The enabledMasterchain option was removed from tact.config.json. Going forward, support of masterchain addresses is always enabled in Tact contracts.

♥️ Special thanks goes to all the contributors and community members — without you there would be nothing. Let's keep building the future of smart contracts with ⚡️ Tact!
📜 See full release notes for Tact v1.6.0
📥 And upgrade Tact in your projects

🍲 we're beating the gas allegations with this one 🗣🗣🗣
♨️ @tact_kitchen

🎉 Tact v1.6.1 is released!

👀 "Long" time no see — many tools have been updated to support the latest Tact versions, and we've prepared some quality-of-life additions and minor fixes.

A big release cannot exist without a follow-up patch. This patch mainly focused on polishing things in the internal infrastructure, standard library, and public APIs.

🛠 Bug fixes

▪️ The multiple wildcard function parameters are now supported.

That is, the following works in v1.6.1:

trait WildThing {
    // Using wildcards for parameter names
    virtual fun assure(_: Int, _: Int): Bool {
        return true;
    }
}

contract YouMakeMyHeartSing with WildThing {
    // And then overriding them with concrete names
    override fun assure(a: Int, b: Int): Bool {
        return a + b == b + a;
    }
}

▪️ Made calls to the .toCell() function on struct as a contract field handled correctly.

struct MyStruct { x: Int; y: Int; z: Int }

contract MyContract(myField: MyStruct) {
    receive() {
        // This works fine now:
        self.reply(self.myField.toCell());
    }
}

🧰 Standard library additions and changes

• Added the StateInit.hasSameBasechainAddress() function, which is a gas-efficient way to check whether the given initial package corresponds to a specified address.

• Added the cashback() function to efficiently forward excess funds from an incoming message to the target address.

• All entities in Core libraries received documentation comments. Next time, we'll add missing doc comments for the standard libraries, i.e., everything imported using the import "@stdlib/..." syntax.

🧳 Some other changes:

• We've inlined the contract load functions, so the gas consumption of the benchmarked Jetton implementation in Tact is even smaller than that of its reference implementation in FunC.

• The TypeScript wrappers now produce bi-directional mappings of exit codes from their numbers to string descriptions and vice versa. Plus, the message opcodes are exported too.

• The .code infix is no longer added to the file names of the generated FunC, Fift, and disassembled Fift outputs. It was annoying to see it everywhere, so now it's only present on the compiled .boc files.

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

Besides, the tact.vim plugin for Vim 8+ and tact-sublime package for Sublime Text 3+ have been updated to support Tact v1.6.0 (and v1.6.1 too).

The Misti static analyzer has been updated to v0.7.0 and now supports Tact v1.6.0 and v1.6.1. See its full release notes.

Speaking of plugins and tools, we have another announcement to make — we're starting an alpha test of the tact-language-server: an official language server for Tact that can be used standalone or within a dedicated extension for VSCode and VSCode-based editors, such as VSCodium, Cursor, Windsurf, and others.

Join the alpha squad and gain early access to great tooling: tact-language-server. If things are good, please give it a star and write a positive review. If they're not — open an issue, and we'll take a look!

🍲 cue the Tact type beat (sped up)
♨️ @tact_kitchen from the @ton_studio

𒀟 Tolk v0.9: nullable types, null safefy, control flow, smart casts

Tolk v0.9 introduces nullable types: int?, cell?, and T?, bringing null safety to your code. The compiler prevents using nullable values without checks, but thanks to smart casts, this feels smooth and natural.

✅ Notable changes in Tolk v0.9:

1. Nullable types int?, cell?, etc.; null safety
2. Standard library updated to reflect nullability
3. Smart casts, like in TypeScript in Kotlin
4. Operator ! (non-null assertion)
5. Code after throw is treated unreachable
6. The never type

PR on GitHub with detailed info.

✔ Nullable types and null safety

In FunC, null was implicitly assignable to any primitive type — too permissive. A variable declared as int could still hold null at runtime, leading to TVM exceptions if used incorrectly.

Tolk now forces you to explicitly mark nullable values. This aligns with TypeScript T | null and Kotlin, preventing unintended null usage.

value = x > 0 ? 1 : null;  // int?

value + 5;               // error
s.storeInt(value);       // error

if (value != null) {
    value + 5;           // ok
    s.storeInt(value);   // ok
}

* any type can be nullable: cell?, [int, slice]?, (int, cell)?
* no more unexpected TVM exceptions due to null
* at runtime, int? and cell? occupy just one stack slot — zero overhead

✔ Smart casts (via control flow graph)

Once a nullable value is checked, the compiler automatically refines its type:

if (lastCell != null) {
    // here lastCell is `cell`, not `cell?`
}

or:

if (lastCell == null || prevCell == null) {
    return;
}
// both lastCell and prevCell are `cell`

or:

var x: int? = ...;
if (x == null) {
    x = random();
}
// here x is `int`

Smart casts ensure code is safe while remaining gas-efficient (compile-time only).

✔ Operator `!` (non-null assertion)

If you know a value can't be null, use the ! operator to bypass nullability checks:

// this key 100% exists, make it `cell`, not `cell?`
validators = getBlockchainConfigParam(16)!;

It's useful for low-level TVM functions (dicts, particularly), when you have guarantees outside the code. Use with care!

✔ The `never` type

Now, you can declare "always-throwing functions":

fun alwaysThrows(): never {
    throw 123;
}

fun f() {
    ...
    alwaysThrows();  // no return needed after this
}

never also occurs implicitly when a condition is impossible:

var v = 0;
// compiler warning: `int` can never be `null`
if (v == null) {
    // v is `never`
}

... this is just the beginning! Nullable tensors, tricky smart casts, and low-level null safety details — all explained in the PR.

🌳 Null safety is smooth, intuitive, and enforced at compile time — no runtime cost, no extra gas, just safer code.

Get high TONAPI limits in your dApps for free

You already know our @ton-api/client library — a client for building advanced TON dApps. Now, we're happy to announce a new feature that grants high TONAPI limits for free.

This upgrade enables cost-free TON API usage within dApps running in the Tonkeeper built-in browser (mobile) and standard browsers with the Tonkeeper extension installed.

To check if this feature is available, verify that the window.tonapi object exists in your browser.

How it works →

During the last year all dTON services were running on kubernetes cluster without HA build. Sometimes when we lost servers, we faced complex problems.

To improve the stability and availability of the service we developed high availability dTON cluster that will continue to work even if some of the servers are unavailable. Additionally, we've got setup complex monitoring and alerting system on services and data consistency.

Today we managed to switch all our services to HA cluster.

In our article we want to share our experience of HA cluster on top of bare-metal servers in three parts:

- dTON Kubernetes High Availability Transition
- dTON LiteServers High Availability Transition
- dTON GraphQL High Availability Transition

Second and third part will be posted exclusively on @dtontech with promo codes on dTON API usage.

https://blog.dton.io/dton-kubernetes-high-availability-transition-part-1/

🫧 Tolk v0.10: preparing for serialization — intN, bytesN, coins

This update lays the foundation of future auto-packing to/from cells by solving one critical question:
How should fields be serialized?

✅ Notable changes in Tolk v0.10:

1. Fixed-size integer types: int32, uint64, etc.
2. Type coins and function ton("0.05")
3. Types bytesN and bitsN (backed by slices at TVM)
4. Replace "..."c postfixes with stringCrc32("...") functions
5. Trailing comma support

PR on GitHub with detailed info.

❓ Fixed-size integers? In TVM? What?

Imagine Tolk already has structures, and we define an incoming message:

struct CounterIncrement {
    counter_id: int;
    inc_by: int;
}

A client sends this message following the TL/B schema:

counterIncrement 
    counter_id:int32 
    inc_by:int64
    = CounterIncrement;

But how do we tell the compiler that counter_id is int32 and inc_by is int64? This information is missing in the struct definition.

✖ Rejected approaches: why they fail

Several syntax ideas were considered:

// type casting?
counter_id: int as int32; 
inc_by: int as int64;

// inline annotations?
counter_id: int @int32;
inc_by: int @int64;

// annotations above fields?
@serialize(int32)
counter_id: int;
@serialize(int64)
inc_by: int;

Each of these quickly breaks down when handling more complex cases.

For example, how would we handle TL-B Maybe int32? Would we write:

// this?
inc_by: (int as int32)?;
// or this?
inc_by: int? as int32?;
// or this?
inc_by: Maybe<int> as Maybe<int32>;

And what about TL/B Both (Maybe int32) int64?

// this?
my_data: Both<Maybe<int as int32>, int as int64>;
// or this?
my_data: Both<Maybe<int>, int> as Both<Maybe<int32>, int64>;
// or how??

With every new case, the syntax becomes more complex, ambiguous, and error-prone.

✔ The solution: `int32` as a first-class type

struct CounterIncrement {
    counter_id: int32;
    inc_by: int64;
}

No annotations. No confusing as syntax. No ambiguity.

This scales perfectly:

struct MyMsg {
    inc_by: int32?;
    my_data: (int32?, int64);
}

These are distinct types. A variable can be int32 and similar:

var op: int32 = ...;
var query_id: uint64 = ...;

This makes serialization predictable, structured, and error-free.

✔ What about overflow?

A reasonable question: what happens if a value exceeds the limit?

var v: uint8 = 255;
v += 1;    // ???

Answer: no runtime overflow or clamping! It's just int at TVM.

* arithmetic works normally – v becomes 256
* no extra gas cost – no runtime bounds checks
* overflow will only happen at serialization

struct Resp {
    outValue: uint8;
}

resp.outValue = v;   // 256
resp.toCell();       // a runtime "overflow" error

✔ Why is this the best approach?

Think of smart contracts as a black box:
- inputs are encoded (int32, uint64, etc.)
- inside the contract, arithmetic uses full 257-bit precision
- outputs are serialized again — overflow happens only at this stage

This is similar to how mulDivFloor(x,y,z) uses 513-bit precision internally. Your contract keeps precision internally and only enforces constraints at the border with an outside world.

🌳 Tolk will follow a type-based philosophy

This post covered the foundation of automatic serialization. The right way is to have a rich type system. Having nested types, having generics, having aliases — will allow to describe every practical TL/B case, but at a language level.

In v0.10, we introduce intN (fixed integers), bytesN (definite slices), coins (variadic integers), and some more additions. Read the details in the PR.

How will Either L R and even more complex TL/B structures be expressed?
Stay tuned for the next update...

Build a Dashboard for DeDust
——————> Win up to $3000

Welcome to our first data contest where we reward for making TON data more transparent.

Build a Dune dashboard for DeDust and win:
🥇 1st place: $3000
🥈 2nd place: $2000
🥉 3rd place: $1000

📅 Deadline: Mar, 24

Read more:
👉 [ Rules & Guidelines ] 👈
(bonus task for onchain detectives inside)

Got questions? Ask in our chat: @tondatachat