ton-vulnerability-scanner
by trailofbitston-vulnerability-scanner is a focused audit skill for TON smart contracts written in FunC. It helps identify integer-as-boolean misuse, fake Jetton contract handling, and missing gas checks when forwarding TON. Use it for a fast first-pass Security Audit before deeper manual review.
This skill scores 78/100, which means it is a solid directory candidate for users auditing TON/FunC contracts: it has a concrete security scope, explicit use cases, and enough pattern guidance to reduce guesswork versus a generic prompt. Directory users should still expect some adoption friction because the repo does not provide an install command or executable scripts, so it reads more like a detailed audit playbook than a fully automated tool.
- Clear triggerability for TON/FunC audits, Jetton reviews, and gas-forwarding checks, with explicit 'when to use' guidance.
- Substantive workflow content: 11k+ body length, multiple headings, and a dedicated vulnerability checklist for three TON-specific issues.
- Evidence-backed pattern library in resources/VULNERABILITY_PATTERNS.md helps an agent recognize concrete failure modes and inspect contracts more systematically.
- No install command and no scripts suggest manual use or prompt-guidance only, not a packaged runnable workflow.
- Scope is narrow to TON smart contracts in FunC, so it is less useful for broader blockchain or multi-language security reviews.
Overview of ton-vulnerability-scanner skill
ton-vulnerability-scanner is a focused audit skill for TON smart contracts written in FunC. It helps you catch platform-specific bugs that ordinary smart-contract prompts often miss, especially around boolean handling, Jetton logic, and gas forwarding. Use it when you need a fast first-pass security review before deeper manual analysis or external audit.
What the skill is best for
This ton-vulnerability-scanner skill is most useful for auditors, protocol engineers, and developers reviewing pre-launch TON code. It is a good fit when you need to check whether a contract’s control flow, token checks, or message handling matches TON conventions. It is not a general code review skill; it is designed around a small set of high-impact TON failure modes.
Core vulnerability focus
The repository centers on three critical patterns: integer-as-boolean misuse, fake Jetton contract handling, and forwarding TON without proper gas checks. That scope matters because it gives the skill sharper signal than a broad “find bugs” prompt. If your goal is Security Audit work on FunC contracts, this is the right kind of narrow tool.
When not to use it
Do not expect strong results on non-FunC stacks, generic EVM contracts, or architecture reviews that are not TON-specific. If you are looking for style issues, test generation, or a full formal audit, ton-vulnerability-scanner is too narrow on its own. It works best as a targeted scanner inside a larger review workflow.
How to Use ton-vulnerability-scanner skill
Install and locate the skill files
For the ton-vulnerability-scanner install step, use the directory’s normal skills flow, for example: npx skills add trailofbits/skills --skill ton-vulnerability-scanner. After install, read the skill entry point first, then follow the repo’s linked context. The most useful starting files are SKILL.md and resources/VULNERABILITY_PATTERNS.md.
Feed it the right input
The ton-vulnerability-scanner usage pattern works best when you give it a concrete contract, a review goal, and the scope boundary. Good inputs name the file type and the security question, such as: “Review contracts/wallet.fc for Jetton transfer validation, boolean flags, and gas forwarding risks.” Weak inputs like “scan this code” leave too much room for shallow output.
Turn a rough task into a strong prompt
Use the ton-vulnerability-scanner guide idea as a prompt template: identify the contract, note whether it is a Jetton, wallet, or transfer handler, and tell the skill what to prioritize. Example: “Audit this FunC contract for the three TON patterns in resources/VULNERABILITY_PATTERNS.md, and show any exact lines or conditions that would mis-handle booleans, spoof Jetton contracts, or forward value without checking gas.” That kind of prompt improves precision because it asks for pattern-based reasoning, not generic commentary.
Practical workflow and what to inspect first
Start with the contract entry points such as recv_internal, recv_external, message parsing, and any transfer-notification logic. Then inspect boolean flags, sender validation, and calls involving send_raw_message(), load_msg_addr(), or coin-loading and coin-storing helpers. If you need to understand the skill quickly, prioritize resources/VULNERABILITY_PATTERNS.md over the broader repository tree, because it shows the exact failure modes the scanner is built to find.
ton-vulnerability-scanner skill FAQ
Is this only for FunC contracts?
Yes, the ton-vulnerability-scanner skill is aimed at TON contracts written in FunC, especially .fc and .func files. If your project uses wrappers, tests, or TypeScript tooling, those can help with context, but the vulnerability logic is contract-level. For a Security Audit, the contract source is the key input.
How is this different from a normal prompt?
A normal prompt may notice “suspicious code,” but ton-vulnerability-scanner is tuned to TON-specific assumptions such as boolean truth values and Jetton message patterns. That makes it better at finding bugs that are easy to miss if you do not already know the platform. It is narrower than a general AI code reviewer, but that narrowness is the value.
Will beginners be able to use it?
Yes, if they can point it at a specific FunC contract and describe the review goal. Beginners get the best results when they ask for one security pass at a time, not a complete audit of an entire repo. The main limitation is not skill complexity; it is whether the contract uses TON patterns the skill understands.
What are the main boundaries of the skill?
The skill is strongest on boolean logic, Jetton authenticity checks, and gas-forwarding risks. It is weaker on business-logic review, cross-contract system design, and issues unrelated to TON message semantics. If your review needs those broader dimensions, combine it with a more general audit workflow.
How to Improve ton-vulnerability-scanner skill
Give it explicit audit targets
To get better ton-vulnerability-scanner results, tell it which of the three patterns matter most for the file you are reviewing. For example, “focus on transfer notifications and fake Jetton detection” is more useful than “check everything.” This narrows attention to the code paths most likely to fail.
Provide contract context, not just source text
The skill performs better when you tell it whether the contract is a wallet, Jetton minter, transfer handler, or receiver. That context changes how booleans, message addresses, and forwarded value should be interpreted. If you already know expected invariants, include them up front so the scan can compare code behavior against them.
Watch for the common failure modes
The biggest mistakes are using positive integers as booleans, trusting token-looking messages without verification, and forwarding TON without enough gas discipline. When you review the output, ask whether each finding points to a concrete line, a specific condition, and a realistic exploit path. If it does not, ask for a tighter re-check against the pattern checklist in resources/VULNERABILITY_PATTERNS.md.
Iterate with code excerpts and expected behavior
If the first pass is vague, resend the suspicious function and state the intended behavior in one sentence. For example: “This handler should only accept genuine Jetton transfer notifications from the expected master contract.” That kind of follow-up helps the ton-vulnerability-scanner skill distinguish true positives from TON-typical patterns and gives you a more actionable Security Audit result.