TON Consensus Bug Bounty Challenge

Overview

In the TON Blockchain, validators are responsible for maintaining network safety and liveness. The goal of this challenge is to identify vulnerabilities in the implementation of New TON Consensus Algorithm.

Update on March 13, 2026:
The rules were clarified after the challenge started.
In particular, we accept only issues that participants have reproduced themselves, and each report must include either a reproduction script or an archive containing the full reproduction.

Reference Implementation
The reference implementation is the testnet branch of the TON repository.

Testnet Deployment
The same code is currently running on TON testnet.

Important Notes:
1. The testnet branch may change during the challenge. (No major changes are expected.)
2. You should treat the current state of the testnet branch as the reference implementation.
3. We accept only issues that you have reproduced yourself.
4. Do not submit a report before reproducing the issue.
5. Each report must include either a reproduction script or an archive containing the full reproduction.
6. You may attach the script or archive directly to your Telegram message.

The Task

The Task is to find and report real vulnerabilities in the implementation of the New TON Consensus Algorithm. The core focus of the challenge is the consensus algorithm itself. Reports about other vulnerabilities in the TON validator implementation are welcome but have lower priority.

  • Each report you submit must describe a real issue that is in scope, actionable, and verifiable from the submitted materials. To be fixed, the issue must require a code change.
  • Each report must contain a reproduction of the issue. tontester and the TON bug triage skill could be helpful.
  • For duplicates, the first valid report takes precedence. Reports submitted after the relevant fix has already been implemented in testnet will not be accepted.

Technical Details

Scope

Primary scope:
- Bugs in the implementation of the new TON consensus algorithm.
- The main consensus code area is validator/consensus/, excluding validator/consensus/null.
- Reports about code outside this directory are also in scope if they directly affect the new consensus algorithm.

Secondary scope:
- Other vulnerabilities in the TON validator implementation, including new features such as QUIC support and TwoStep broadcast.

Reference materials:
- TON bug triage skill
- Consensus specification. This document is a work in progress and has known problems. For this challenge, the testnet implementation is authoritative.

Reproducible consensus bugs

For consensus bugs, the reproduction must satisfy both of the following limits:
- Fewer than 10^4 slots.
- No more than 100 validators.

Resource-exhaustion bugs

For resource-exhaustion reports, the reproduction must satisfy at least one of the following conditions:
- They cause superlinear resource growth over time under the admissible attacker model.
- They remain linear in time but can still realistically cause a denial of service for a validator running on average hardware, for example by requiring more network bandwidth than a 1 Gbps validator link can provide.

When evaluating such reports, assume that a Byzantine node can send only a linear-in-time number of messages to each honest node. Growth in the number of validators, including quadratic-in-validator effects, may still be relevant if the issue is reproducible within the limits above and results in a realistic denial of service in a real network.

Reports that will be ignored

Reports may be ignored if any of the following applies:
- The report is out of scope.
- It is assumed that a node can trust its local environment. Issues related to key theft, local database corruption or compromise, and similar local-environment attacks will not be accepted.
- The report is speculative, unverifiable, or too incomplete to triage.
- The report is a duplicate and another participant submitted the same issue first.
- The relevant fix has already been implemented in testnet.
- The report is low-quality or spam.
- The report is AI-generated slop.

Submission

Rapid Reports

Your reports must be submitted via the TON Bug Bounty Contest account.

Submission rules:
- Each distinct issue must be submitted as a separate Telegram message.
- You may submit any number of reports.
- Do not submit a report until you have reproduced the issue yourself.
- Each reproduction must include either a reproduction script or an archive with the full reproduction. You may attach it directly to the Telegram message.
- Send reports as early as possible. Fixes may be published during the challenge.
- If a report does not fit into a Telegram message, include a link to a secret gist containing the full report.

Required report format:
1. Report title.
2. Report impact.
3. Short description.
4. Reproduction details and either a reproduction script or an archive with the full reproduction. If needed, you may include a secret gist with the full report.

Final Reports

Participants will also be required to submit a final summary of all submitted reports closer to the deadline of this challenge.
Instructions for final summaries will be announced on @contest.

LLM Usage

Using LLMs is allowed.

However:
- Participants are encouraged to use the provided TON bug triage skill.
- You are responsible for validating every claim before submission.
- Low-effort AI-generated reports will be ignored and may lead to your suspension from this challenge.