Tact: a TON smart contract language that is now deprecated

The deprecation notice comes before the documentation

The first thing in the Tact repository is a caution block, and it is not a footnote. Tact is deprecated. Please learn the Tolk language instead. Pull requests are not accepted at the moment, and problems or tasks are to be brought to the issue tracker.

That single line changes what this project is today. Everything below it describes a language that was significant and is now closed to new development. The rest of the README is a description of what the language was, and it is worth reading with that in mind, because the reasons a project gets deprecated are usually the reasons it was adopted in the first place.

The repository is not archived. The last push was on 2026-06-23, and the recent releases are v1.6.13 from 2025-05-29, v1.6.12 from 2025-05-27 and v1.6.11 from 2025-05-26. So there was recent activity on the branch without a new release, which fits a project that is being kept in a runnable state rather than extended.

The people behind it were TON Studio, and the project describes itself as powered by the community. The licence is MIT, the homepage is tact-lang.org, and the documentation lives separately at docs.tact-lang.org.

Why a language existed for TON at all

Tact is described as a next-gen smart contract programming language for TON Blockchain focused on efficiency and ease of development, and it is presented as a good fit for complex smart contracts, quick onboarding and rapid prototyping.

The design decisions in the feature list explain what problem it was solving. The syntax is familiar and user-friendly, TypeScript-like, which is the onboarding argument: a developer who knows TypeScript can read and eventually write a Tact contract. The type system is strong and static, with built-in structs, messages and maps.

The features that are more than syntax are the ones that remove work from contract development. There is first-class maps support with many methods and a foreach statement for traversing. Incoming messages and data structures are serialized and deserialized automatically, so a contract does not hand-roll a parser for every message it receives. Internal, external and bounced messages are routed automatically, and message types are handled automatically, including binary, text and fallback slices. Sending messages and deploying child contracts need no boilerplate functions. Reusable and composable behaviours use traits, which the documentation compares to interfaces or mixins.

There is also an escape hatch, support for low-level programming with asm functions, and the project claims a rich standard library and extensive documentation alongside the tooling it ships.

The generated TypeScript wrapper is the real deliverable

One feature deserves its own look, because it is the part of the workflow that a team outside the core developers interacts with most. Tact generates single-file TypeScript wrappers for convenient interactions with compiled contracts.

What is in the wrapper is specified. Type definitions for structs and messages, observable in the compilation report. Corresponding storeStructureName() and loadStructureName() functions for serialization and deserialization, which means the off-chain code and the on-chain code agree on the layout by construction. All global and contract-level constants. Bi-directional records of exit codes, from their names to numbers and vice versa, so a failed call can be read as a name rather than as a number. The opcodes of all messages. And a contract wrapper class with helper functions for initialization, deployment and message exchange.

The bi-directional exit code mapping is the detail with the most practical value. A contract that returns a named exit code produces a typed constant on the off-chain side, and the wrapper resolves it back to the name, so a failure is a readable string rather than an integer you have to look up.

This is a compiler that is conscious of the whole development loop rather than of the contract file alone. The compilation report is a first-class artefact in the design, since the wrapper's types are described as observable in it.

Adoption numbers and the security audit

The README gives a specific adoption figure, and it is worth quoting as the project states it rather than paraphrasing. As of the beginning of 2025, the number of unique code contracts deployed on the mainnet reached almost 28 thousand, of which about 33 percent were written in Tact.

That is a meaningful share for a language that is not the platform's default, and it is the kind of number that makes a language worth considering seriously. It is also a number from early 2025 for a language that is now deprecated, and a reader should hold both facts at once. The deprecation does not retroactively invalidate the contracts, but it does change the maintenance story for everyone holding one.

On security, Tact underwent a comprehensive security audit by Trail of Bits, described in the README as a leading Web3 security firm, and the report is published as a PDF with a backup link. The projects listed under Tact in production have their own audits too, and the list is a mix of open source and closed source work.

Proof of Capital is a market-making smart contract that protects the interests of all holders, audited by Nowarp. Tradoor is a fast and social DEX on TON, audited by TonBit. PixelSwap is described as the first modular and upgradeable DEX on TON, audited by Trail of Bits. GasPump is a TON memecoin launchpad and trading platform. The audits are the relevant part: an audit of the compiler and an audit of the contracts are different things, and a project that lists both is showing which is which.

Installing the compiler as a Node package

The compiler is distributed as an NPM package, @tact-lang/compiler, bundled with the Tact standard library. The recommended Node.js version is 22 or higher and the minimum is 18, and the project recommends yarn although it does not require it:

# yarn is recommended, but not required
yarn add @tact-lang/compiler

The same package installs with the other major package managers, and the README gives each form:

# you can also use npm
npm i @tact-lang/compiler@latest

The manifest shows what the package contains and how it is built. The name is @tact-lang/compiler at version 1.6.13, and the scripts reveal a build pipeline with a grammar generation step, a standard library generation step and a JavaScript function generation step, all driven by ts-node scripts, plus a TypeScript compile and a copy step. The grammar itself is generated from a peggy grammar file, which is the sort of arrangement you need when the language has a custom syntax.

The repository is more than the compiler. Alongside src/ there are dev-docs/ and docs/, a spell/ directory with a cspell configuration, a knip configuration for unused dependency detection, four separate jest configurations for fast runs, coverage runs and CI, a crowdin.yml for translation of the documentation, and a .lycheeignore for link checking. The crowdin configuration is worth noting, since it tells you the documentation was being translated for a wider audience, and the link checking configuration tells you the documentation links are verified automatically.

What the deprecation leaves behind

The first consequence is contractual. Contracts deployed on the TON mainnet are not rewritten by a language deprecation. A Tact contract keeps executing its compiled FunC or TVM code, and the wallet, the DEX or the vault that depends on it does not change behaviour. What changes is who fixes a bug in the compiler, who updates the standard library, and whether a future version of the chain requires a recompile.

The second consequence is for developers. Anyone starting a TON contract now is being pointed at Tolk, and the contract they write will live in a different language with a different toolchain. Reading Tact code is still valuable, since a third of the deployed contract code was written in it, but writing new Tact code is a decision with a maintenance cost attached.

The third is about what a language's adoption really means. Tact achieved the things a good smart contract language is supposed to achieve. It had a familiar syntax, a strong type system, automatic serialization, generated off-chain wrappers, an audit by a well known firm, and roughly a third of the mainnet contract code. And it was still deprecated within a few years of its last release, because the platform ecosystem made a decision, not because the language was weak.

The alternative path here is Tolk, which the deprecation notice points to as the replacement, and the honest comparison is between two languages rather than between a language and nothing. Tact's pitch was tooling and ergonomics on top of a TypeScript-like surface, and it won on adoption. Tolk is the platform's own direction, and for a contract that will be maintained by a team rather than a person, aligning with the platform's own language is the lower risk choice even if the syntax is less familiar. For existing Tact code, the work is the audit, the interface surface and the rewrite, and none of that is free.

Editorial conclusion

Read Tact as a case study if you are choosing a language for TON today, because it shows what a well-audited, well-adopted language achieved and what a deprecation costs the contracts already written in it. Do not start new work in Tact, since the repository states it is deprecated and directs you to Tolk, and do not assume the compiler package still receives the fixes a production contract needs. If you are looking after existing Tact contracts, verify which compiler version deployed them, check the Trail of Bits audit report for the issues it raised, and confirm that the contract interface you depend on is unchanged in whichever language you migrate to.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tact-lang/tact on GitHub