On November 5, TON Core rewrote the rules of its bug bounty program, which pays rewards for discovered vulnerabilities. Out-of-memory (OOM) and DDoS attacks are no longer paid for at all, and Toncenter API, the Fift, FunC and Tolk compilers, the DHT node, the testnet branch, websites and SDKs have left the program. The reward ceiling is unchanged: up to $100,000 in Gram or USDt per vulnerability. This matters to security researchers, above all those who hunt bugs with language models: a line saying that report processing is delayed by spam from LLM-generated reports has been in the rules since August. A report written by a neural network is now checked by the researcher's neural network, and then by the bot's.
What changed in the rules
The change landed in two commits to the repository README: on November 2 Toncenter was removed (commit message: "Descope TonCenter"), and on November 5 the file was rewritten from scratch, with 76 lines added and 104 deleted.
| Before November 2 | Since November 5 | |
|---|---|---|
| TON node | Validator Node, Full Node, DHT Node, Simplex; testnet branch bugs accepted | Validator Node, Full Node, Simplex; master branch and latest global_version only |
| What counts | anything that causes a node crash, a blockchain halt, theft of coins or an incorrect state change | unauthorized manipulation of state or funds, a network halt, a node halt triggered by a single request |
| OOM and DDoS | no separate line | all excluded |
| Compilers | FunC and Fift out of scope | Fift, FunC and Tolk out of scope |
| Toncenter | HTTP API and indexer listed | out of scope |
| Websites and frontend | accepted via HackenProof | out of scope |
| SDKs | Python SDK pytonlib listed | SDKs and developer tools out of scope |
| Large rewards | paid with a one-year lock-up | may be paid with a lock-up or vesting |
The exclusions also gained lite-client and the first version of RLDP; RLDP2 was already there. During 2026 the TON network is moving off these protocols to QUIC.
The Tolk language did not leave the program entirely. The compiler is excluded, but the standard contracts written in Tolk, jetton v2.1 and NFT v1.1 from the acton-contracts repository, were on the contrary added to the list of targets next to the older FunC versions. Still covered are wallets v1, v3, v4r2 and v5, Telegram Wallet's tg-wallet-v1, Multisig V2, Highload V3, the nominator contracts, Elector, Config and TON DNS. MyTonCtrl, the validator toolkit, now counts only for bugs that lead to loss of funds or unauthorized access to the server.
The main change for the core is the line about node halts. A node crash used to be paid without qualification. Now only a crash from a single request counts, and resource exhaustion is excluded even when a report calls it a network halt or a threat to funds: the self-check guide that accompanies the rules says so explicitly.
What a researcher should do
- Check the target against the list. For the core that means only Validator Node, Full Node and Simplex on
master; for contracts, only the versions named in the README. The program does not consider anything else, and third-party products in the ecosystem run their own bounties. - Do not submit resource attacks. A node that a flood of requests drives out of memory does not qualify under the new rules. A crash from a single request does.
- Attach a self-check. The report goes to the bot @ton_bugs_bot together with a
self-check-report.mdfile, which, per the guide in the repository, a language model writes by checking the finding against the rules and the current code. Both files go in at once; if the bot rejects a report with theno_inputverdict, both are sent again rather than the self-check on its own. - Mind duplicates. Of identical reports, only the earliest counts; most reports are processed within 90 days.
Where the flood of reports came from
The self-check guide appeared in the repository on May 12. It is not a memo for a human but a skill for an LLM agent: the model reads the README, fetches the relevant repository, reproduces the finding locally and writes a report in a strict format, with a status, component, vulnerability class, two confidence scores and a verdict. If the finding is not ready, the agent must put "DO NOT SEND!!!" at the start of the short assessment.
The report then reaches the bot, which runs its own automated check: the same guide lists its verdicts (correct, incorrect, out_of_scope, escalate, no_input) and the ai_checked status. Judging by the fields named there, the bot compares the researcher's self-check with its own.
The day before the guide appeared, on May 11, a story about a 4,000 USDT payout for a bug in the TON blockchain spread across channels: according to them, it was found by a 13-year-old schoolboy who asked Claude Code to look for a vulnerability. TON Core confirmed the payout in the comments and added a few details. Over the next few hours the same, already fixed bug was submitted several more times. Most incoming reports, including correct ones, are found with LLMs. The workable path, according to the team, is to get a dozen false positives, verify each one and submit the single real one, and authors of sloppy reports get banned. Age and search method, according to the team, have no bearing on the payout.
On August 8 a line appeared in the README about delays caused by LLM-generated spam. In the November edition it shrank to "LLM-generated spam may cause delays".
The README does not explain the link between the flood of machine-made reports and excluding OOM, DDoS and Toncenter specifically. It shows indirectly in the guide, which spells out that resource exhaustion does not become eligible if it is renamed a network halt or a threat to funds. Judging by that caveat, such reports have already arrived.
The same tool on the other side
Language models find more than noise. The research shown at OffensiveCon in October took about a year: fuzzing the rlottie library with a language model found memory corruption bugs, and the end result was a zero-click chain through Telegram's animated stickers reaching code execution on iOS. The finding was taken from a crash to a working chain before it went on stage.
