How Much Does a TON Smart Contract Audit Cost in 2026
TON smart contract audit cost in 2026 ranges from $3k automated scans to $15k+ manual reviews — here's what sets the tiers apart.
A TON smart contract audit in 2026 runs anywhere from $3,000 for a scripted scan of a simple jetton to $25,000+ for a multi-contract DEX with a formal certificate and two review rounds. The spread isn't padding — it maps directly to how many storage layouts, message flows, and bounce-handling edge cases a reviewer has to trace by hand. If a quote lands far outside that range, either the scope is trivial or someone is guessing.
TON pricing looks different from Solidity audits because the execution model is different. There's no reentrancy guard pattern to check off a list, no require statement density to eyeball. Instead you're paying someone to trace asynchronous message chains across multiple contracts, verify gas reserves survive a bounce, and confirm that op-code routing in recv_internal can't be tricked into skipping an access check. That work doesn't scale down well, which is why "quick audit" offers under $2k almost always mean automated-tool-only.
The three pricing tiers
Tier 1 — Automated scan, $2,500–$4,500. This is static analysis (think custom lint rules against FunC/Tact ASTs, plus tools like func-check output review) layered with a manual pass over storage read/write ordering and the standard jetton/wallet checklist: TEP-74 compliance, correct forward_ton_amount handling, no unhandled bounce=true case. You get a PDF, maybe a severity table, no certificate. Fine for a wallet contract or a jetton that's a near-verbatim fork of the standard implementation with no custom transfer hooks.
Tier 2 — Manual audit, single contract, $5,000–$9,000. A human reads every function, builds a message-flow diagram, and tests fee/gas edge cases against real TON fees (0.05 TON minimum for jetton transfers can silently eat a poorly reserved balance). This tier covers a jetton with custom logic — burn-on-transfer, allowlists, rebasing — or a single-contract wallet with session keys. You get a written report with PoC reproduction steps for anything above Low severity, and usually one free re-check after fixes.
Tier 3 — Full manual audit with certificate, $8,000–$25,000+. Multi-contract systems: a DEX pool + router + LP jetton, a lending protocol with oracle contracts, anything where contracts call each other asynchronously and state has to stay consistent across a chain of bounced or delayed messages. This tier includes economic/game-theory review (can a flash-loan-style sequence drain a pool before the second message lands?), a second reviewer cross-checking findings, and a signed certificate suitable for a listing application or investor due diligence. Two-week minimum turnaround is normal; complex DEXs run four to six.
What actually drives the price within a tier
Four things move the number more than anything else:
- Number of contracts and their message graph. A jetton-minter + jetton-wallet pair is two contracts but a known pattern, so it prices near the bottom of its tier. A DEX with router, pool, staking, and a separate LP-token minter is four contracts with a dozen possible message paths between them — that's a full tier jump.
- Custom logic versus standard fork. Auditors keep a mental (and often literal) diff against the canonical TEP-74/TEP-89 jetton implementation. Every function that deviates from the standard is billable review time because it can't be checked against known-safe reference behavior.
- Upgradeability. A contract with a
set_codeadmin function needs its access control and code-hash validation audited as carefully as the business logic, because a broken upgrade path is a full protocol takeover, not a bug. - Gas and fee-reserve correctness. TON's async model means every outbound message needs enough attached TON to cover forward fees and storage rent, or it silently fails and the sender's assets can get stuck. Auditors trace this path by hand for every external call; it's the single most common finding in first-round reports and the one most junior teams get wrong.
A worked example
Say you're shipping a jetton with a transfer tax and a blacklist — not a stock TEP-74 fork. Here's the kind of check that pushes this into Tier 2 pricing rather than Tier 1:
() recv_internal(int msg_value, cell in_msg, slice in_msg_body) impure {
slice cs = in_msg.begin_parse();
int flags = cs~load_uint(4);
if (flags & 1) { return (); } ;; bounced, ignore
int op = in_msg_body~load_uint(32);
if (op == op::transfer()) {
;; missing: check sender against blacklist before mutating balance
var (balance, owner, jetton_master, jetton_wallet_code) = load_data();
...
}
}
The bug here is ordering: balance state gets mutated before the blacklist check runs later in the function, which means a blacklisted address that races two transfers in the same block can get one through before the check catches up in some execution orderings. A scripted tool flags "blacklist check exists" and moves on. A manual reviewer traces execution order against TON's actual message-processing guarantees and catches that the check needs to happen before any load_data() mutation, not after. That's a Medium or High finding depending on the token's value, and it's exactly the class of bug that separates a $3k scan from a $7k audit.
What "certificate" actually buys you
A certificate is not a warranty. It's a dated, signed statement that a named team reviewed a specific commit hash against a defined scope and found no unresolved Critical/High findings at delivery time. Exchanges and launchpads ask for it because it creates a paper trail, not because it eliminates risk. If your contract changes after the audit — even a "minor" constant tweak — the certificate no longer covers the deployed code, and you need a scoped re-check, usually 20–30% of the original fee.
Picking the right tier for your project
If you're forking a standard jetton or wallet with no custom logic, Tier 1 is defensible — the risk surface is genuinely small and well-trodden. The moment you add custom transfer logic, staking, or cross-contract calls, pay for manual review; the delta in audit cost is trivial next to the cost of a drained pool. For anything going on a DEX or handling third-party deposits, budget for Tier 3 and build the timeline into your launch plan rather than treating the audit as a pre-launch afterthought.
For ongoing protocols, a one-time audit isn't the end of the story — new features and upgrades reopen the attack surface, which is where a line-by-line code review before each release or an ongoing maintenance retainer earns back its cost. If your project touches jettons or NFTs specifically, it's worth reading through the common jetton and NFT standard pitfalls we see in TON audits before you even request a quote — fixing them pre-audit shifts your project into a cheaper tier. Teams running a live trading or liquidity product should also see how audit findings map onto operational monitoring in a trading dashboard setup.
Get a scoped quote from our TON smart contract audit team before you lock a launch date — the tier your contract falls into is usually obvious within a 15-minute look at the codebase.
Need a bot like this built?
We design, build and run trading bots on Solana, Hyperliquid and Polymarket.
Start a projectMore from the blog
Public vs Paid RPC: How to Run a Fair Benchmark
A fair comparison of public and paid RPC endpoints must account for quotas, workload, freshness and support guarantees.
Read articleRPC Benchmark Percentiles Explained: p50, p95 and p99
Why averages hide the latency spikes that break trading bots, wallets and production blockchain applications.
Read articleHyperliquid REST vs WebSocket Benchmark: What to Measure
A benchmark plan for Hyperliquid market data that separates request latency from streaming freshness and recovery.
Read article