Smart contract audit

Smart contract audit is a standard practice for serious DeFi projects: before launch (and often after major upgrades), an external team of security specialists reviews the code. The goal is to find vulnerabilities that could lead to loss of funds before the contract is deployed and filled with user assets.

What an audit covers

• Logic and invariants. Does the contract do what it claims? Are key properties preserved in edge cases — for example, does the sum of all jetton balances always equal total supply?
• Economics. Can the price be manipulated through flash loans, sandwich attacks, or MEV? Are fees distributed correctly? Are there gaps in the incentives for validators or LP providers?
• Gas and DoS. Are there scenarios where the contract gets stuck — for instance, a loop over a user list that exceeds the gas limit as the list grows?
• Access and permissions. Who can call privileged methods? Is the owner/admin/upgrade authority implemented correctly? Are there backdoors left in?
• Initialization. Are the first calls after deployment safe? Can the project be hijacked through an attack on an uninitialized contract?
• Standards compliance. For a jetton — conformance to TEP-74, for NFTs — TEP-62. Non-compliance can break integrations with wallets and explorers.

Known firms auditing TON projects

• CertiK — the largest player, does a lot of audit-as-marketing, though report quality varies.
• Trail of Bits — deep reports, academic approach. Doesn’t take every project.
• Halborn — solid player in DeFi auditing.
• SlowMist — Asian leader, both audits and incident forensics.
• TON-focused teams — SecureLayer, CertiK’s TON team, plus several boutiques specializing in FunC and Tact. Their advantage is understanding TVM-specific issues.

Audit costs typically range from 15,000 to 200,000 USD depending on code complexity and timeline.

Specifics of auditing TON contracts

TON differs fundamentally from EVM chains, and auditors without TVM experience can miss entire classes of vulnerabilities that simply don’t exist on Ethereum:

• Asynchronicity. In TON, you cannot synchronously “get a return value” from another contract. All calls are asynchronous messages. This changes the reentrancy model and requires a careful state machine across messages.
• BoC and cell-based storage. State is stored in cell structures. Serialization and deserialization errors can lock the contract forever.
• Get-methods. Free read-only calls that don’t write to state. The auditor must verify they have no side effects and don’t expose sensitive data through public getters.
• Messages and bounce. What happens if an internal message bounces — is the return path handled correctly?
• TVM stack. Unlike EVM, TVM is stack-based. Opcodes and limits differ. Attacks via stack overflow or unhandled exceptions are TON-specific.
• Storage rent. A contract can be “frozen” if its balance runs out for storage payments. This affects fund availability.

What an audit does NOT guarantee

• An audit is not insurance. Time and again, contracts with two or three audits have been exploited through vulnerabilities everyone missed.
• An audit checks code, not the team. If developers run a rug pull through legitimate admin functions, the auditor will see it and flag it but won’t prevent the act itself.
• An audit is point-in-time. If an upgrade is deployed afterward, the new code is not covered.
• Coverage depends on scope. Sometimes the client narrows scope to part of the contracts; a critical hole may sit in the unaudited portion.

For users, “has an audit” is a necessary but insufficient condition for trust. It pays to read the report itself: what was found, what was fixed, what was accepted as a “known risk.” A quality report reads like a technical document, not a marketing certificate.