TON Tech

🪙 Toncoin Name Change — Community Vote TON has changed substantially in recent months. Telegram is taking on a leading role in the network and is becoming its largest validator. The chain itself is now 10× faster with fees down 6×. Gram was the name the network's founders gave the token in the original TON White Paper, and it's never left the codebase. That is why Telegram is proposing to rename the native token from Toncoin to Gram, a fitting moment to bring it forward. The blockchain stays TON / The Open Network, only the token's name and ticker change. Balances, addresses, contracts, NFTs, staking, DeFi, all unchanged. No swap, bridge, claim, or migration. No action required. ⚠️ Any site, bot, or link asking you to "claim GRAM" or "migrate TON" is a scam. How the vote works Runs for one week on TON Vote, an established open DAO platform on TON ▪️ Voting power is weighted by TON balances 👉 Vote here

docs.ton.org — updated structure, improved search and much more TON Tech team shipped a major documentation update. Here are the highlights: — new navigation built around developer flows — dedicated Applications section for AppKit, TON Connect, TON Pay and WalletKit — redesigned TON Center API reference — new search with proper prioritization — llms.txt and markdown endpoints for AI agents — hundreds of DX and UX fixes across the documentation Read more about the docs.ton.org update here

TON developer documentation has been fully updated Now everything needed to build in TON ecosystem is gathered in one place: — smart contract documentation — application development flows — SDKs and tools — general documentation for TON blockchain Navigation is now much simpler, the structure is clearer; finding what you need is way much faster. Click to see fully revised TON documentation

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

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

🏁 TON leads Layer-1 blockchains in finality time. 🔗 Sources: https://telegra.ph/Comparison-of-Layer-1-blockchains-by-finalization-time-05-01

⚡️ Fees in TON have dropped 6× — to nearly zero. Next step — Telegram replaces the TON Foundation as the driving force behind TON and becomes its largest validator. ⚙️ The focus shifts to tech superiority. 🧩 New ton.org, new dev tools, new performance upgrades. 🧭 Timeline — 2-3 weeks. 🪙 This is step 3 of 7 to Make TON Great Again.

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

🔊 The AMA session is now live We’re talking about Agentic Wallets, AI agents and on-chain execution on TON Join the stream on X

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

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

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.

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.

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

💎 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

💎 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

✈️ We Need Your Feedback on TON Roadmap We’re updating TON strategy and need direct input from active builders. The form is very short — just 3 questions about your real blockers and opportunities. Your answers will directly influence what we fix and prioritize next. 📎 https://walletresearch.typeform.com/to/IwFt5CSL

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