🫧 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

💎 AppKit — Early Access Now Open

A new way to build TON apps.
Blockchain complexity fades into the background. You focus on product.

🔗 Apply for the Early Adopter List.
*Selected developers will have access to Beta version.

Gateway Tickets | Hotel Booking | TON Community | TON Builders | TON Hubs | X | YouTube | Website | Blog | LinkedIn

💎 AppKit | Alpha Announcement

TON is the blockchain built into Telegram. Apps built on TON can reach Telegram's billion+ users directly.

Until now, every team had to build wallet connections, transaction handling, and DeFi integrations from scratch. Weeks of work before a single line of product code.

Today we're announcing AppKit alpha to change that.

What's live now:
▪️ Wallet management and transaction sending
▪️ DeFi integration (swaps, staking)
▪️ TON Connect support
▪️ TypeScript and React support
▪️ LLM-friendly (describe an app, build a prototype in minutes)

WalletKit is also production-ready for wallet developers on iOS, Android, React Native, and Web.
More features coming at Gateway (May 1-2).

👉Read more

Tribute Tickets | Gateway | TON Community | TON Builders | TON Hubs |X | YouTube | LinkedIn |TON.org

TON Tech: what we’ve built and what’s available now

Over the past months, we’ve been expanding TON developer stack. This is a quick overview of what’s available today

TON Connect
The protocol to connect apps and wallets on TON. Over the past months, we’ve improved its stability, speed, security and compatibility with the rest of the stack — so the rest of the developer stack can build on top of it

AppKit
SDK for building TON apps using familiar patterns. Provides ready-to-use primitives for balances, transactions, swaps and NFTs, with built-in integrations so these features work out of the box

WalletKit
SDK for building wallets across web, iOS, Android and React Native. Handles TON Connect, signing, asset management and transaction flow

AgentKit
Tools for building AI agents that can interact with TON via MCP. Balances, transactions, swaps and assets are accessible through natural language

Network progress

Sub-second finality has been rolled out. TON Core upgraded the blockchain and API, and we’ve worked with ecosystem projects to roll out the update. What this means

• <1 sec transaction confirmation
• faster block production
• improved real-time UX

If you’re building, this channel will save you time

We’ve just launched a Russian-language TON Tech channel
Follow for updates in Russian @tontechru

Where TON builders talk
TON Dev Chat (EN) • TON Dev Chat (RU)

Use this to start
Docs • build with SDKs • explore AppKit • work with TON Connect

How all parts connect and why this stack exists — read the full article

TON Connect work in progress: simplifying transaction UX on TON

Previously on TON, users often had to open an explorer just to check whether a transaction went through. With the sub-second update, that experience has changed — results now appear almost instantly.

But there’s another part of UX: how many steps it takes to get to the transaction. Today, the flow still looks like this: connect a wallet, return to the app, then confirm the action.

So the question is: why not let users open the wallet and confirm the action right away?

We’re working on an update to TON Connect that simplifies wallet interactions: removing unnecessary steps, allowing users to connect and sign a transaction in a single action and introducing support for gasless scenarios.

In the end, this all converges into a single flow: users perform an action and immediately see the result without extra steps or the need to manage a separate gas token.

Gasless transactions: the next step in TON Connect

In a standart flow, a user tops up their wallet with USDT, opens app, tries to make a purchase and gets stuck. Gas requires TON, which they don’t have. For the developer, this results in a drop in conversion at the final step: the user has already clicked “buy” but runs into a network requirement.

Gasless already exists in TON, but it currently lives at the wallet level. The W5 contract supports delegated fee payment, but only for transactions initiated from within the wallet. In TON Connect, applications have no mechanism to sponsor gas for the user.

We are integrating gasless into the standard TON Connect flow. The application requests a fee estimate from a gas provider, builds the transaction paid in USDT, and sends it to the user for signing. The signed transaction is then passed to the provider, which submits it to the network. For easier integration, this will be available via AppKit.

As a result, the user sees a single amount in the wallet, for example 100 USDT, signs one transaction (99.9 USDT for the purchase and 0.1 USDT to the gas provider), and completes the purchase. For the developer, this means preserving conversion at the final step.

Agentic Wallets on TON: enabling AI agents with dedicated on-chain wallets

TON Tech introduces Agentic Wallets — an open, self-custodial standard that lets AI agents manage funds and send transactions on TON without requiring user approval for every transaction, while keeping full user control. Each agent operates a dedicated on-chain wallet funded by the user, with no intermediary involved.

Getting started is straightforward: a user asks their agent to create a wallet, funds it and confirm setup. From there, control is clearly separated — the user retains ownership through their main wallet, while the agent can transact only within defined limits. Funds can be withdrawn at any time and access can be revoked.

The standard works with existing TON wallets — requires no upgrades, and integrates without vendor lock-in, allowing developers to implement and manage their own setups independently. It is compatible with leading AI models and agent frameworks, and includes MCP & CLI for building and managing agent workflows.

In Telegram, this becomes immediately actionable. Bot API and recent bot-to-bot communication allow agents to interact autonomously. Agentic Wallets extend that foundation: agents on Telegram can now not only communicate, but also make payments within the chat interface.

Launch an AI agent with Agentic Wallets

TON Tech x TOP Talks: Agentic Wallets on TON AMA

Join tomorrow’s AMA session on X Spaces, hosted by Tobias Jack Lewis, Head of BD & Partnerships at TOP, at 12PM UTC, where we’ll discuss how Agentic Wallets enable AI agents to manage funds and execute transactions on TON in practice.

We’ll explore how agents interact with DeFi protocols like STON.fi and what this shift means for user experience, market dynamics and the future of crypto.

→ Join here

How MCP enables on-chain actions for agents on TON

We publicly announced Agentic Wallets on TON — an open, self-custodial standard that lets agents manage assets through dedicated wallets. But just having a wallet isn’t enough. For an agent to use TON, it needs to be able to find and connect tools for interacting with the blockchain.

That’s why we built mcp.ton.org — a simple entry point for connecting AI agents to TON. MCP gives agents access to tools for working with the blockchain, while skills provide ready-to-use instructions. A user copies a single command, and the agent gets a ready way to work with the blockchain. All skills are open and available in the ton-org/skills.

Now developers have a ready-to-use execution layer for agents on TON. After connecting MCP and installing skills, an agent can check balances, send transactions, swap tokens, work with NFTs and execute more advanced scenarios like buying xStocks or managing Agentic Wallets. All actions are built from reusable primitives and executed through MCP, which allows developers to move directly to building agent logic.

Connect MCP and give your agent access to actions on TON

Why different staking protocols in TON show different APY?

After the sub-second update, validator rewards increased ~6x. Previously, different calculation models could show values like 4.19% and 4.28%, while after the update they show ~25.44% and ~22.83% depending on the formula and reward accounting mechanics. Let’s briefly break down where these numbers come from and why they differ.

In TON, staking works in cycles: rewards are distributed only during the active validation phase ~18 hours, while the full cycle including election and holding takes around ~36 hours. Because of this, a single validator participates in roughly half of all rounds per year ~240 out of ~481 — this is critical for APY calculation.

APY (annual percentage yield) accounts for compound interest: rewards are automatically added to the stake and start earning in subsequent validation rounds. In the formula below, which is currently used, compounding accumulates only over ~240 rounds in which the staked amount is actually active.

APY = ((1 + reward_per_round) ^ (rounds_per_year / 2)) - 1
APY = ((1.00085507) ^ 240) - 1
APY ≈ 22.83%

When you stake TON in liquid staking, half of the stake works in even rounds and half in odd rounds, so rewards are received roughly every ~18 hours. If you combine them, it results in a full reward over ~36 hours.

Read more about how staking works in TON

Hi, we’ve got a small dev inbox experiment here

We’re constantly building tools for TON — WalletKit, AppKit, TON Connect, AI agents and all that good stuff. And the more we build, the more new use cases and developer questions we see that are not always obvious upfront

So we’re opening a dev open mic for the community. Simple format: you drop a question → I answer as an engineer, not as a press release. If a question is really good, we might break it out into a separate post

Anyway, let’s have a proper dev conversation in the comments