Building on TON means building for scale. Code can reach real users quickly, creating incredible opportunities but also significant responsibility.

Most exploits don't use advanced attacks; they stem from avoidable mistakes: unchecked admin permissions, hardcoded logic, weak input validation. These gaps create opportunities for bad actors.

TON provides battle-tested contract examples, clear security practices, ecosystem support, and a developer community to help teams build safer products from day one.

Secure-by-design: the TON developer checklist

✅ Start with trusted, production-used contracts

Learn from what's already working:

• FunC developers: Use TON's core contract examples (Jetton, multisig wallet, nominator pool)
• Tact developers: Check awesome-tact for DeFi, Jetton, and NFT examples
• Tolk developers: Start with the Tolk overview, then explore tolk-bench examples

These aren't plug-and-play templates, but they're reliable blueprints that reduce risk and speed up development.

✅ Apply least-privilege design

The problem: Centralized admin control is the most common exploit vector.

The solution: Give each contract only the permissions it needs:

• Use multisig contracts for major upgrades and treasury functions
• Add time locks for high-impact changes
• Revoke developer privileges after deployment
• Avoid shared or exposed deployer keys

✅ Build modular, testable contracts

Break logic into small, well-defined components with single responsibilities. Use clear naming conventions and inline documentation.

Test thoroughly: FunC, Tact, and Tolk all support unit testing environments that catch edge cases before deployment. Clean, testable code makes future updates safer and collaboration smoother.

✅ Avoid hardcoded logic and fallbacks

Never hardcode:

• Wallet addresses
• Fee amounts
• Upgrade keys

Instead: Use secure, upgradable config mechanisms for flexibility without redeployment.

Control fallbacks: Disable or tightly control fallback functions. Unrestricted fallback logic creates unexpected execution paths prone to exploits.

✅ Secure the UI and transaction flow

Critical for Telegram Mini Apps:

• Display clearly: Show wallet addresses, transaction details, and actions before user confirmation
• Validate everywhere: Check inputs on both client and server side
• Prevent spoofing: Design UI that earns trust through clarity and consistency

Phishing and spoofed interfaces remain common attack vectors.

✅ Test against abuse and edge cases

Don't just test expected flows. Simulate:

• High-volume activity
• Spam inputs
• Unusual sequencing
• Bot-driven interactions

Use TON testnet for real-world testing. Invite internal red teams or trusted developers to review before mainnet deployment.

Key principle: Attack your code first, before anyone else can.

Essential resources for safer development

Learning & Best Practices

• TON Cookbook - DApp development guide
• Security Guidelines - What to focus on
• awesome-ton-security - Curated security resources

Code Examples & Tools

• awesome-ton - SDKs and tools
• FunC docs - FunC contract examples
• awesome-tact - Tact contract examples
• tolk-bench - Tolk contract examples
• Telegram Mini App Payments Demo - Integration example

Community Support

• TON Dev Chat - Developer community
• TON Nest - Early-stage team support

Note: Register on TON Builders before applying to TON Nest

What is Tolk? TON's next-generation smart contract language designed to replace FunC. Inspired by TypeScript and Rust, it offers clearer syntax, robust static typing, and built-in serialization - making it easier for EVM developers to get started while maintaining low-level control.

The bottom line

Users won't stick around if they can't trust your app. Security isn't just about preventing exploits. It's about building confidence that scales. Following these practices from the start creates a stronger foundation for attracting users, partners, and long-term success.