Acton v1.0 — Foundry for TON: the complete guide (2026)

TL;DR. On May 11, 2026, TON Foundation shipped Acton v1.0 — a Rust-written all-in-one CLI that consolidates the fragmented TON stack under a single command. Blueprint, @ton/sandbox, Misti, the func compiler, the deployer, the debugger — all of them are now subcommands of acton. As bonuses you get mutation testing, fuzzing through @test.fuzz, on-chain acton retrace for replaying real transactions, and automatic FunC → Tolk conversion. This is the first stable Foundry-class toolkit on TON. The first-mover window is 2-4 months.

What Acton is

Acton is Foundry for TON. The analogy is literal: the same blend of speed (Rust runtime), integration (everything in one CLI), and cultural shift (the old JavaScript stack steps aside for a fast native tool).

Before Acton, TON development looked like this: func separate, blueprint separate, @ton/sandbox separate, the Misti static analyzer separate, no debugger, no mutation testing, no native fuzzing. Each tool was written independently, with different conventions and different configs.

After Acton it’s one manifest, Acton.toml, one command, a unified workflow. Under the hood — 30 Rust crates, from the Tolk parser to the TVM emulator and the on-chain indexer.

What Acton replaces

This is a massive infrastructure consolidation. Not a marketing one, a real one: every right-hand column is a working v1.0 command.

Architecture: 30 Rust crates

Under the hood Acton is a modular pipeline:

tolk-syntax + tolk-resolver + tolk-analysis + tolk-ty
                    ↓
              tolk-compiler  ← Tolk → TVM bytecode compiler
                    ↓
         tasm-core + tasm-syntax  ← TVM assembler
                    ↓
              ton-emulator  ← local TVM emulator for tests
                    ↓
              ton-executor  ← transaction execution
                    ↓
         ton-networks + ton-api  ← testnet/mainnet integration
                    ↓
         ton-localnet + acton-localnet-ui  ← local chain

Additional crates:

• tolk-linter — 29 static analysis rules
• tolk-fmt — formatter
• tolk-dataflow — CFG and dataflow analysis for the linter
• acton-debug + dap-client — debugger via the Debug Adapter Protocol
• ton-indexer — on-chain state indexing
• acton-test-ui — browser UI for tests
• fift-syntax and tlb-syntax — Fift and TL-B (Type Language Block) support

What this gives you in practice: tests run many times faster than on @ton/sandbox (Node.js JIT vs native Rust). The Tolk compiler doesn’t transpile through FunC, it emits TVM bytecode directly. The linter does dataflow analysis at the level of professional analyzers like Slither or Mythril in the EVM world.

Installation: WSL only on Windows

Native Windows is not supported. Supported platforms:

• macOS (ARM64, x86_64)
• Linux GNU (x86_64, ARM64), Ubuntu 20.04+

On Windows — WSL is required with Ubuntu 20.04 or newer. We recommend 22.04 or 24.04 LTS.

Install WSL

wsl --version
wsl --list --verbose
wsl --install -d Ubuntu-24.04

After install, enter WSL:

wsl -d Ubuntu-24.04

Install Acton inside WSL

The official installer (no sudo, drops the binary into ~/.local/bin/):

curl -LsSf https://github.com/ton-blockchain/acton/releases/latest/download/acton-installer.sh | sh

Alternative tarball:

wget https://github.com/ton-blockchain/acton/releases/latest/download/acton-x86_64-unknown-linux-gnu.tar.gz
tar -xzf acton-*.tar.gz
sudo mv acton /usr/local/bin/
acton --version

Output should be 1.0.0 plus a build hash.

Node.js 22 LTS for frontend and func2tolk

Linux-native Node is required for two cases: acton func2tolk (it uses npx @ton/convert-func-to-tolk) and --app templates (Vite + React).

cd /tmp && wget https://nodejs.org/dist/v22.11.0/node-v22.11.0-linux-x64.tar.xz
mkdir -p ~/node_extract && cd ~/node_extract
tar -xJf /tmp/node-v22.11.0-linux-x64.tar.xz
mv node-v22.11.0-linux-x64 ~/.local/node

In ~/.bashrc:

export PATH="$HOME/.local/node/bin:$HOME/.local/bin:$PATH"

Important gotcha: Windows-native Node from /mnt/c/Program Files/nodejs/ does not work with Linux-side paths. npx fails with a UNC path error. That’s why Node is installed inside WSL.

Docker alternative

If you’d rather skip WSL setup:

docker run --rm ghcr.io/ton-blockchain/acton:1.0.0 --version
docker run --rm -v "$PWD":/workspace -w /workspace ghcr.io/ton-blockchain/acton:1.0.0 build

Tolk: the language everything builds on

Acton is Tolk-first. Tolk is the official successor to FunC from the TON Core team, designed to answer the main FunC complaints: unreadable stack-manipulation code and a lack of modern types.

What characterizes Tolk:

• TypeScript-flavored syntax (much friendlier than FunC)
• Strong typing: int, coins, address, cell, slice, plus custom types
• Supports structs, enums, lazy types, pattern matching
• Compiles directly to TVM bytecode without transpilation
• Has a standard library @stdlib plus Acton-extensions @acton

A minimal example — counter from the template:

import "@stdlib/tvm-dicts"

struct Storage {
    id: uint32
    owner: address
    counter: int32
}

@inline
fun loadStorage(): Storage {
    return Storage.fromCell(contract.getData())
}

@inline
fun saveStorage(storage: Storage) {
    contract.setData(storage.toCell())
}

struct IncreaseCounter {
    static OPCODE = 0x12345678
    queryId: uint64
    delta: int32
}

fun onInternalMessage(in: InMessage) {
    val storage = loadStorage()
    val body = in.body

    if (body.matches<IncreaseCounter>()) {
        val msg = body.parseAs<IncreaseCounter>()
        assert (in.senderAddress == storage.owner) throw Errors.NotOwner
        storage.counter += msg.delta
        saveStorage(storage)
    }
}

The equivalent FunC is roughly 30 lines of unreadable stack manipulation. For a senior developer with a TypeScript or Python background, the Tolk learning curve is two weeks rather than the month FunC tends to require.

Core commands

Five-minute quickstart

acton new my_first --template counter --app
cd my_first
acton build
acton test
acton wallet new --name deployer --local --airdrop --version v5r1 --secure false
acton run deploy-testnet
npm ci && npm run dev

Five minutes from zero to a deployed counter contract on testnet with a React frontend, wallet connection via TON Connect. Templates: counter, empty, jetton (TEP-74), nft (TEP-62), w5-extension (extension for WalletV5R1).

Build and test

acton build                                # compile the whole project
acton test                                 # run all tests
acton test --coverage                      # with coverage
acton test --filter "increase"             # only tests with "increase" in the name
acton test --ui --coverage                 # browser UI with line highlighting
acton test --debug --debug-port 4711       # with DAP debugger (attach from VS Code)

Coverage reports both line-percent and branch-percent. On the counter template lines hit 100% but three branches stay uncovered — a healthy signal that tests cover the hot path while edge cases are skipped.

Lint

acton check                                # all rules
acton check Counter                        # one contract
acton check --explain E013                 # detailed rule description
acton check --fix                          # auto-fix simple issues

29 built-in rules — from security-critical (E007 no-bounce-handler, E013 unauthorized-access, E018 random-requires-initialization, E019 divide-before-multiply) to stylistic ones. E013 uses CFG + dataflow analysis — it flags storage.save() without a preceding admin sender-check, which is equivalent to a permissionless write. Finding such a bug manually is hard; Acton does it automatically.

Format

acton fmt                                  # format
acton fmt --check                          # CI check (exit 1 if anything unformatted)

Wallet and deploy

acton wallet new --name deployer --local --version v5r1 --secure false
acton wallet airdrop deployer              # testnet faucet
acton wallet list --balance
acton script scripts/deploy.tolk           # emulation only, no send
acton script scripts/deploy.tolk --fork-net testnet  # emulation with live testnet state
acton script scripts/deploy.tolk --net testnet       # real send

The --secure false flag bypasses an interactive keychain prompt — WSL has no keychain by default, so the mnemonic is written to wallets.toml (which is auto-added to .gitignore).

Verification

acton verify Counter --net mainnet --address EQB...

Acton compiles the local source, uploads to the verifier backend, gathers signatures, and submits a verification tx. The verified contract is published on tonviewer and tonscan — the analog of Etherscan verification.

Mutation testing — the main weapon

acton test --mutate --mutate-contract Counter

Acton automatically modifies the contract source: swaps += for -=, == for !=, removes assert, flips >= to >. Then it runs the tests against every mutation. If all tests still pass on mutated code — the mutation survived, which means that line isn’t actually verified.

Sample output on the counter template:

Total mutants:        15
Killed:               12
Survived:             3
Mutation Score:       80.0%

◉ Counter.tolk:29   Remove assert storage.owner == in.senderAddress   SURVIVED
◉ Counter.tolk:30   Replace >= with >                                  SURVIVED
◉ Counter.tolk:37   Remove assert in DecreaseCounter                   SURVIVED

“Remove assert at line 29” means the tests don’t verify that a non-owner cannot decrement the counter. In the official TON Foundation template. That’s not a knock on the TON team — it’s an illustration of how mutation testing surfaces real coverage holes even where line-coverage shows 100%.

For audits and bug hunting it’s the perfect tool: take someone’s contract, run mutation against their tests, look at survivors, and each survivor is a potential bug vector. “Here’s line X, nobody notices when you change it” — if you can build an exploit that uses this behavior, it’s a valid bug.

Fuzzing via @test.fuzz

Fuzzing ships inside the Acton stdlib (@acton/testing/fuzz):

import "@acton/testing/expect"
import "@acton/testing/fuzz"

@test.fuzz
get fun `test balance stays bounded`(value: int) {
    val bounded = fuzz.bound(value, 0, 100)
    fuzz.assume(bounded != 13)
    expect(bounded >= 0).toBeTrue()
}

Annotations:

• @test.fuzz — fuzz test with the default run count
• @test.fuzz(1000) — explicit iteration count
• @test.fuzz({ ... }) — custom config

Helpers:

• fuzz.bound(value, min, max) — clamp to a range
• fuzz.assume(condition) — discard input if condition is false (analog of Foundry’s vm.assume)

Use it like this: write a test that checks a contract invariant (e.g., “total_supply always equals the sum of balances”), run it under fuzz — Acton drives hundreds of generated inputs through it. If even one fails, that’s a bug.

On-chain retrace — a debugger for real transactions

acton retrace <TX_HASH> --contract MyContract --debug --debug-port 4711

This is magic that no other TON tool offered before Acton. You take a real transaction hash from mainnet, and Acton:

1. Pulls on-chain state from the moment of that transaction
2. Reconstructs it locally inside the TVM emulator
3. Runs the trace with a DAP-debugger

VS Code attaches to the port, you can set breakpoints on any line of Tolk, step into (including inlined functions), inspect TVM registers, stack frames, and variables.

Use cases:

• Suspicious activity on a contract — copy the tx hash, retrace in debug mode, step through, look for an invariant violation
• A contract failed on mainnet — replay the tx and see the exact location and variable values
• You want to understand someone’s mainnet contract without sources — acton disasm + retrace gives you the full picture

func2tolk: automatic FunC → Tolk conversion

acton func2tolk path/to/contract.fc

Under the hood it’s npx @ton/convert-func-to-tolk@1.0.0. Requires Linux-native Node.js (see the install section).

FunC in, idiomatic Tolk out:

• () storage::load() impure inline { ... } becomes @inline fun storage_load() { ... }
• ds~load_msg_addr() becomes ds.loadAddress()
• throw_if(err, condition) becomes assert(!condition) throw err
• TVM opcodes are converted to UPPER_SNAKE_CASE constants
• Identifiers containing :: are preserved through backtick-escaping

This matters for existing FunC codebases. STON.fi v2 (4,355 lines of FunC), EVAA (10,804 lines) — all of it can be converted to Tolk automatically and gain the full power of Acton: mutation testing, fuzzing, debugger, coverage.

What to build in the first wave

The release is fresh, so the first-mover window is open for 2-4 months. Concrete niches:

Apps

Toolchain

• VS Code extension with an AI assistant for Tolk (autocomplete, bug-fix suggestions)
• Tolk-cookbook: best practices, patterns, anti-patterns
• Testing patterns library — ready-made invariant tests as a cargo/npm package
• Acton plugin for bug-bounty platforms — auto-submit reports with CI
• TonScan-like explorer on top of the ton-indexer crate

Content and education

The English educational niche for Acton is wide open. YouTube tutorials, a Telegram channel about TON dev, paid workshops, a Gitbook-style guide — all of it is currently unclaimed.

TON Foundation grant opportunities

TON Foundation systematically funds infrastructure around its own tools through the ton-society/grants-and-bounties program. What gets funded:

• Extensions and plugins for official tools (VS Code, JetBrains, Acton plugins)
• Educational projects: courses, documentation, translations
• Indexers, explorers, dev tools built on Acton crates
• Ecosystem content localization

Grant sizes range from $5k for small educational projects to $50k+ for serious infrastructure work. The approval rate is above normal right now — because Acton is fresh and the Foundation is actively looking for teams that will help with the ecosystem.

When to choose Acton, and when not

Acton — yes, if:

• A new project on Tolk
• You want mutation testing, fuzzing, retrace out of the box
• The team is comfortable working in WSL or Linux
• A built-in formatter and lint matter
• You want to replace a “zoo” of 5-7 tools with one CLI

Acton — wait, if:

• Large existing FunC codebase with hundreds of Jest tests against @ton/sandbox. func2tolk conversion works, but rewriting tests is its own project. A reasonable strategy: stay on Blueprint, port new contracts to Acton gradually.
• A Tact-only project. Tolk-first means not every feature (mutation, fuzz) works equally well with Tact.
• Windows with no WSL and no way to install one (corporate restrictions). Docker as a fallback is fine for CI but not for active development with a debugger.

Related reading

Acton is ecosystem-grade infrastructure, and understanding where it sits in the TON stack is easier with the broader project context. Who runs TON Foundation and what their priorities are — we cover in the TON Foundation overview. What’s coming in the next two years — in the 2026-2027 roadmap. A comparison of TON’s three smart contract languages — FunC, Tact and Tolk — in the developer’s guide. When to move from testnet to mainnet — in the testnet vs mainnet article. Why TON differs technologically from EVM chains — in the EVM-compatibility explainer.

Links

• Acton repository: github.com/ton-blockchain/acton
• Documentation: ton-blockchain.github.io/acton/
• Tolk language reference: docs.ton.org/languages/tolk
• Acton libraries: @acton/env, @acton/io, @acton/emulation/network, @acton/emulation/scripts
• TON Foundation grants: github.com/ton-society/grants-and-bounties
• TON Society: society.ton.org

Acton is open-source under the Apache 2.0 license, contributions welcome. The CHANGELOG in the repository is updated actively — worth re-reading every two weeks so you don’t miss new features.