Intellij TON v3.0.0 is the biggest update of the plugin ever.

We have improved every part of the plugin, every supported language.
The list of supported languages has expanded, and now the plugin also supports TASM, the future assembler standard in
the Tolk language, and Fift assembly has received its improved support as part of Fift support.
BoC files are no longer just opaque binary files, you can open them and see the disassembled code!
In this version, we also supported the latest release of Tolk 1.1.

Available on JetBrains Marketplace

Read full change-log:
https://github.com/ton-blockchain/intellij-ton/releases/tag/v3.0.0

🫧 Tolk v1.1: built-in map<K,V>, enums, private and readonly fields, method overloads

Two months have passed — maybe you even started to worry about the silence. The reason is simple: I worked on features that are "nice to have" but complex and time-consuming to implement — and they've only just been finished.

✅ Notable changes in Tolk v1.1:

1. map<K, V> — a convenient zero-overhead wrapper over TVM dictionaries
2. enum — group numeric constants into a distinct type
3. private and readonly fields in structures
4. Overload resolution and partial specialization

PR on GitHub with detailed info.

✔ Built-in maps

Forget about uDictSetBuilder, sDictGetFirstAsRef, and the endless boilerplate of low-level dict helpers. A universal map<K, V> now fully replaces them.

var m: map<int8, int32> = createEmptyMap();
m.set(1, 10);
m.addIfNotExists(9, -90);
m.delete(9);   // now: [ 1 => 10 ]
m.exists(1);   // true
m.isEmpty();   // false

Just m.get() — no need to care about cells and slices under the hood:

val r = m.get(1);
if (r.isFound) {   // true
    val v = r.loadValue();  // 10
}

// or if the key 100% exists
val v = m.mustGet(1);  // 10

Easily iterate forward and backward:

var r = m.findFirst();
while (r.isFound) {
    // use r.getKey() and r.loadValue()
    r = m.iterateNext(r);
}

Any serializable keys and values — it just works:

map<address, Point>
map<Point, Cell<Extra>>
map<int32, map<int64, bool>>
...

All in all:
- self-explanatory methods, nicely suggested by IDEs
- DICTISETREF, DICTREPLACE, DICTUREPLACEGET, ... — 100+ asm instructions covered by the type system
- all deserialization to/from cells perfectly hidden by high-level API
- absolutely zero overhead compared to low-level TVM dictionaries

✔ Enums

A long-awaited syntax feature for grouping constants.

// will be 0 1 2
enum Color {
    Red
    Green
    Blue
}

Being integers at runtime, enums have their own place in the type system. They resemble TypeScript/C++ enums. (Unlike Rust, where each variant may have its own shape. In Tolk we have union types — a more powerful solution)

struct Gradient {
    from: Color
    to: Color? = null
}

var g: Gradient = { from: Color.Blue };
g.from == Color.Red;    // false

Compatible with all language features: auto-serialization, exhaustive pattern matching, generics, etc.

✔ Private and readonly fields

Fields can now have modifiers:
* private — accessible only within methods
* readonly — immutable after object creation

struct PosInTuple {
    private readonly t: tuple
    curIndex: int
}

fun PosInTuple.last(mutate self) {
    // `t` is visible only in methods
    // and cannot be modified
    self.curIndex = self.t.size() - 1;
}

✔ Partial specialization

Now it's possible to overload methods for "more specific" implementations:

// general implementation
fun Iterator<T>.next(self) { ... }

// a more specific one
fun Iterator<Cell<T>>.next(self) { ... }

In complex scenarios, this feature lets you adjust the behavior of specific types while keeping a common interface. It "just works", but internally the compiler was enhanced with shape of types, structural depth, type dominators, and several heuristics.

🌳 After Tolk v1.0 release, many people and companies started migrating from FunC to Tolk. I have received a lot of feedback and requests (and almost zero bug reports, huh). Meanwhile, a bigger roadmap is already in motion. In the near future I'll also try to close long-standing questions around TypeScript wrappers, and deliver proper from-scratch documentation.

TON x Ignyte Hackathon: Building the Web3 SuperApp Economy

TON Foundation and Ignyte invite innovators worldwide to create Web3 payment, gig economy, and creator tools on Telegram, making digital payments faster and more useful for everyday life.

🗓 Key Dates

▪️Launch: Oct 8, 2025
▪️Deadline: Nov 17, 2025
▪️Finalists: Nov 21, 2025
▪️Pitch & Awards: Nov 29, 2025

Who Can Apply?

Students, early-stage startups, and scale-ups (Seed to Pre-Series A)

💰 Prizes (30,000 USD Total)
🥇 15,000 | 🥈 10,000 | 🥉 5,000

The Challenge

Build solutions that bring Web3 payments and experiences to Telegram, from instant pay for gig workers to token-gated creator tools.

Winners gain mentorship, access to TON’s Ecosystem, and a chance to pilot their projects globally.

Apply here

🚀 First beta release of the new TON documentation is now live!
🗺 Jump ahead to beta-docs.ton.org or stay here to learn about the project's backstory, current achievements, and future plans.

For quite some time, developers shared the same feedback: TON documentation is too scattered, difficult to navigate, and has obvious gaps and inconsistencies.

We at TON Studio took that seriously and initiated the TON Docs Revamp project in late July. It is focused on the following four goals:

• To introduce a streamlined, discoverable structure that would be easy to navigate and search
• To make documentation welcoming to all developers, from newcomers to seasoned professionals
• To introduce and maintain stricter quality checks from humans and AIs to ensure proof-read, up-to-date, consistent, and clear content
• And, finally, to set up documentation release pipelines for major TON builders, while making community contributions straightforward and approachable

🏆 Today, with the help and suggestions from various developer teams, including Zengo, RSquad, TonTech, TON API team, and TON Core, the TON Studio is proud to present the first public version of this documentation. It already fulfills the first goal of comprehensive structure and rapidly moves towards achieving the third goal of content.

🦄 That said, this is a beta release: many pages await their contents, some pages require secondary reviews, while infrastructure, pipelines, and processes are only nourishing, not mature yet. All constructive feedback is appreciated.

So, what's in store already? We've got:

• Flat, easy-to-navigate structure
• Hands-on articles with real examples whenever we can provide them
• Visuals and diagrams, including various Mermaid diagrams
• Smart AI search and summaries
• Automatic CI spell checks and AI reviews based on the growing style guide
• ...and much, much more!

🏠 TON Docs Revamp features an engaging landing page that guides users through their TON journey, whether they're first exploring TON, building smart contracts, integrating wallets, or just want to access and navigate the documentation quickly.

📝 Re-written or brand new content includes pages for: mytonctrl, mylocalton, development setups with Sandbox and Blueprint (with major help from TonTech), IDEs and SDKs, gas estimation, analytics, oracles, bridges, TMAs, TON Connect, standard wallet contracts, Jettons, NFTs, TVM instructions (with proper search and discovery), TL-B, FunC and other TON-specific programming languages, web versions of whitepapers (with cross-links and solid AI summaries), and even a "Coming from Ethereum" guide!

📈 And this is just the beginning. Plans ahead and for the next month include:

- Release pipelines and assignments of relevant technical owners
- Docs, infrastructure, and processes for approachable community contributions
- More playgrounds, interactive components, and interactivity
- Much more content
- Stronger AI-based assistance as documentation grows

🎯 The main goals of this beta release are to show preliminary progress, willingness to make things right, and to collect feedback from the developer community before the full release, which is tentatively scheduled for November 17th.

We are nothing without the feedback from the community. If something is missing or confusing, let us know by filing a GitHub issue. Furthermore, help review new content whenever you or someone you know is deeply familiar with the topic. TON is vast, and there is always something to know or be aware of.

Prominent ecosystem projects are invited to host, co-own, and maintain their documentation with us. Keeping things in one place will enrich the user experience and AI responses.

💪 Let's make the best documentation for TON. Together.

→ Beta release URL: beta-docs.ton.org
→ GitHub repository: github.com/ton-org/docs
→ Future milestones: github.com/ton-org/docs/milestone/3

@ton/ton library v16.0.0 major release

🚨 This is a breaking change to fix a bug in the storeOutListExtendedV5R1 method for Wallet V5.

It used to incorrectly reverse the message order, but in v16.0.0 this behavior has been changed to NOT do the reversal anymore.
Now the load and store operations are mutually inverse.

This major release does not add any new functionality.

Important: If you do not use Wallet V5, you don’t have to change anything in your code, otherwise, please test your apps before upgrading to the new version.

Many thanks to the Ston.fi team for uncovering the issue.

🦀 ton-rs — Idiomatic Rust toolkit for TON builders

Write TON dApps the Rust way with a modern crate family: ton_core, ton, and ton_macros.

✨ Why devs will love it
• Type-safe TON primitives: Cells/BOCs, addresses, TL-B parsing/serialization
• Zero-boilerplate TL-B: derive layouts with #[derive(TLB)] from ton_macros
• Two network clients:
– TLClient (behind the tonlibjson feature) using TON’s TonLib API
– Built-in lite client (always available) using ADNL + Lite API
• Block.TLB coverage: a large set of predefined block.tlb types in ton/src/block_tlb/
– tx.rs (transactions), msg.rs (messages), tvm_stack.rs (TVM stack) — parse raw chain data & traces out of the box
• Practical examples to get you shipping fast

Repo:
https://github.com/ston-fi/ton-rs

#TON #Rust #TONBlockchain #OpenSource

🫧 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.

📚 New TON Documentation is Live

We rebuilt the entire documentation from scratch based on community feedback.

What's new:

▪️ AI Assistant - Ask questions in plain language and get instant answers from the entire documentation

▪️ Easier Navigation - Flat structure rewritten by blockchain engineers

▪️ Comprehensive Guides - New content for blockchain foundations, TON Connect, mytonctrl, Sandbox, Blueprint, smart contracts, and more

▪️ Dr. Durov's Whitepapers - Now in web format with AI summaries and cross-links

Built with feedback from Zengo, RSquad, TonTech, TON API team, TON Core, and shaped and delivered by TON Studio.

Try it: docs.ton.org 

👉 Read more

🫧 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.

TON Vanity

Meet the new blazingly fast vanity address generator for TON smart contracts!

The previous state-of-the-art solution was released 3 years ago and hasn't improved much since. We at TON Studio decided to develop a completely new solution from scratch, following the usage patterns the previous solution introduced.

Optimizations in both the smart contract and the kernel lead to extreme generation speedups. In realistic usage scenarios on an RTX 4090, the generator finds suffix patterns up to 5,100x faster, and prefix patterns up to 3,600x faster. In practice, this allows finding about 2 more letters than before in appropriate time.

Apart from the crazy speedups, there's a simple interface for TypeScript usage, like in smart contract tests and deployment scripts. Applying the generated vanity address requires writing just a few extra lines of code. The generator's output was improved too, storing all results in a structured JSON format with all useful metadata. Quality-of-life improvements include a polished CLI experience, comprehensive test coverage, and a benchmark script for comparing future optimizations.

The tool will be maintained and improved over time. The entire development process is open on GitHub, and contributions and feedback are welcome. A detailed write-up covering all optimizations and the development process will be published soon, for those who are interested.

Check it out: https://github.com/ton-org/vanity

Hello everyone,

The Pyth oracle contract addresses have now been updated in the TON docs.

The new contract brings several performance improvements, including significantly reduced on-chain price verification costs (10-20x cheaper).


https://docs.ton.org/ecosystem/oracles/pyth