Bug bounty в TON: программы, payout и реализм (2026)

Bug bounty в TON — это узкая, но реальная ниша. Заявленные потолки выглядят впечатляюще: TON Foundation платит до $100 000, Tonstakers — столько же по своей программе, Tonkeeper — до $30 000. Но между «заявлено» и «реально получено» — большая дистанция. В этом playbook’е разбираем, кому подходит TON bug-hunting, какие программы активны в 2026, какие классы багов реально приносят payout, какими инструментами работает охотник и почему важен реализм: большинство принятых отчётов — это medium severity на $100–5 000, а не критические дрейны на шестизначные суммы.

TL;DR — что реально платят на TON

Большинство payout’ов в TON — четырёхзначные. Шестизначные — единичные случаи в год, как правило связанные с критическими находками в bridge или core protocol. Это нормальная картина для молодой экосистемы с TVL в районе $300–500M.

Кому подходит TON bug bounty

Профиль успешного TON-исследователя в 2026:

• Уверенно читает незнакомый код — это 90% работы.
• Понимает async-модели (actor model, event-driven, message-passing). TON ближе к Erlang/Akka, чем к синхронной Solidity-модели.
• Имеет терпение: одна охота на проект — 2–6 недель чтения, прежде чем появится первый кандидат на finding.
• Готов потратить 3–6 месяцев на обучение без гарантии payout.

Не подходит, если:

• Ищет быстрых денег. На TON их нет.
• Ожидает Solidity-style баги (reentrancy через call.value, integer overflow на uint256). Они здесь есть, но в другой форме.
• Не готов читать академические работы. Без статьи «From Paradigm Shift to Audit Rift» (анализ 34 публичных аудитов TON, 233 уязвимости) понимания экосистемы не будет.

Хорошая новость: конкуренция на TON ниже, чем на EVM. По данным той же работы, всего ~34 публичных аудита и менее 20 хорошо описанных классов багов. На Ethereum таких категорий — сотни, и каждой занимаются сотни специалистов. На TON — десятки.

Каталог активных программ (май 2026)

TON Foundation Core Protocol

Платформа — GitHub ton-blockchain/bug-bounty плюс Telegram-бот @ton_bugs_bot. Frontend — hackenproof.com/programs/ton-society.

Max payout: $100 000 в Toncoin. Для крупных сумм — lock-up Toncoin’ов на 1 год.

В скоупе:

• Blockchain core (C++): Simplex, Catchain, validator/full/DHT nodes, TonLib, FunC и Fift компиляторы.
• Стандартные контракты: Wallet V4/V5, multisig, nominator pools, jetton contracts, DNS, elector, network config.
• Сервисы: MyTonCtrl, HTTP API, Python SDK.

Вне скоупа: баги, требующие контроля локального хоста, client-SDK misuse без privilege escalation, баги input hygiene, debug-only crashes, известные design peculiarities (например, неопределённый порядок async-доставки сообщений между шардами — это feature, а не bug).

Tonkeeper

Сайт — tonkeeper.com/bug-bounty. Подача — email security@tonkeeper.com.

Max payout: $30 000. Тиры:

• $15 000–30 000 — reliable loss of funds или confidential data без user interaction (unauthorized tx signing, утечка приватного ключа).
• $5 000–10 000 — limited access to funds, требуется substantial user interaction.
• $1 000–2 000 — unauthorized personal data access, ограниченная потеря средств.
• +25% бонус для багов в beta-версиях.

Вне скоупа: brute-force, DoS, social engineering, third-party сервисы, встроенные в Tonkeeper (NFT-маркетплейс, swap-провайдеры).

STON.fi DEX (контракты v2.2.0)

Платформа — HackenProof + GitHub ston-fi/bug-bounty. Scope — контракты v2.2.0 на mainnet (роутер, пулы).

Жёсткие требования к PoC: должен быть fork mainnet, не локальный setup с чистыми контрактами. Подача — строго через HackenProof в течение 24 часов после обнаружения. Сумм в Terms of Participation нет, но оценочно — $5 000–50 000 для medium-critical, до $50 000–100 000 для критических находок с подтверждённым drain.

Вне скоупа: precision issues (округление при расчёте LP-долей), slippage, frontrun, backrun, sandwich-атаки. Это не баги, а особенность AMM-механики.

Tonstakers (LST-протокол)

Сайт — tonstakers.com. Программа на $100 000 упоминается на business-странице.

В скоупе: stake pool контракты, jetton minter, mTGV-пул, валидатор-управление. TVL протокола — $70M+, любой fund-loss bug автоматически = critical.

EVAA Protocol (лендинг)

Платформа — HackenProof (через партнёрство с TON Foundation).

В скоупе: EVAA master contract, user-SCs (sharded), isolated lending pools. Активы — TON, USDT, jUSDT, NOT, tsTON, stTON, hTON. TVL по данным blog.ton.org в 2026 — приближается к $1B.

Payouts публично не указываются — оценочно $10 000–100 000 для critical (стандарт для лендинговых протоколов). Параллельная возможность — Liquidator Hackathon через Telegram-бот EVAA, грантовая программа.

Bridges и DEX вне топ-3

Здесь — самая богатая по потенциальному payout категория и одновременно самая опасная. Случай TAC bridge drain в мае 2026 (~$2.5M+ потерь в wrapped jettons + 384k свежеминтнутых TAC) показал, что валидаторская логика мостов всё ещё хрупкая. У bridge admin контракта на 2 399 строк TASM не нашлось ни одного CHKSIGN опкода — подпись валидаторов вообще не проверялась on-chain. Подробный разбор — в нашем гайде про атаку на TAC bridge.

Программы:

• TON Diamonds (NFT) — на HackenProof, суммы не публикуются.
• DeDust — программа упоминалась, статус нужно проверять на HackenProof.
• Storm Trade (perpetuals) — потенциально большая программа в будущем (dvAMM-логика, omni-vault).
• TONCO (V3 CLMM) — новый стартап на форке Algebra Labs.

Главное действие: зайти на hackenproof.com/programs и отфильтровать по TON. Список меняется ежемесячно.

Платформы — HackenProof и Immunefi

HackenProof — основная платформа для TON-программ в 2026. Регистрация бесплатная, KYC не требуется до payout от $10 000. Submission через форму программы, треккинг статуса через личный кабинет.

Immunefi исторически больше работал с EVM, но в 2026 несколько TON-проектов туда подключились (TON Foundation размещает там часть программы). Регистрация и подача — аналогично.

Классы багов на TON, которые реально приносят payout

Список основан на каталогах CertiK Tact mistakes и SlowMist Toncoin Smart Contract Security Best Practices, верифицированных в 2025.

Reentrancy через async-сообщения

В TON нет синхронного call.value, как в Ethereum. Но есть длинные цепочки сообщений между контрактами, и intermediate state часто хранится в storage между шагами. Если параллельная транзакция перезаписывает state до использования — это reentry-like ситуация.

Митigация со стороны разработчика — carry-value pattern (передавать данные в теле сообщения, а не в storage). Если в коде видите хранение pending-state в storage между двумя сообщениями — это suspect.

TVM exotic cell attacks

Cell в TVM имеет 5 типов: ordinary, pruned_branch, library_ref, merkle_proof, merkle_update. Каждый exotic-тип обрабатывается специально. Forged proofs (claimed root не соответствует data ref hash) при попытке построить через opcode ENDXC валидируются TVM — exit code 8. Но при приёме внешнего сообщения с уже сериализованным exotic-cell контракт должен сам проверить, что cell relevant и не подделан.

Атаки: подмена library_ref на свою библиотеку, подсовывание pruned-branch там, где ожидается полное дерево, fake merkle_proof для claim-style контрактов (drop, airdrop). Все из них реально встречались в аудитах TON-протоколов.

Validator signature bypass

Класс багов, который дал самый громкий drain 2026 — TAC. В bridge-контрактах часто реализуется multisig через off-chain подписи валидаторов, которые потом on-chain проверяются через CHKSIGNU. Если хотя бы один из вариантов handler’а не вызывает CHKSIGN* или вызывает с неверным pubkey — атакующий может пройти аутентификацию через cherry-picked sender derivation.

Проверка: grep -E 'CHKSIGN|CHKSIGNU|CHKSIGNS' по TASM-дизассемблеру bridge-контракта. Если в admin-handler этого опкода нет — это либо by design (что подозрительно), либо bug.

Jetton replay и double-spend

Класс ошибок, связанный с приёмом TransferNotification без валидации sender() == expected_jetton_wallet. Атакующий деплоит fake jetton master, создаёт fake jetton wallet, шлёт TransferNotification с произвольной суммой — контракт верит и мажет атакующему депозит.

Митigация: всегда проверять, что отправитель TransferNotification — это легитимный jetton wallet для известного jetton master, через calculate_user_jetton_wallet_address(master, owner).

State-init derivation bypass

Когда контракт деривит адрес другого контракта через contracts::from_sources(idata, code) — это критическая точка. Все поля state_init, влияющие на адрес, должны проверяться. Если хоть одно поле под контролем атакующего, он может сделать fake contract с другим адресом и пройти проверку equal_slices(vault~address(), ctx.at(SENDER)).

Тонкость: code cell должен загружаться из storage, а не из тела сообщения, иначе атакующий подсунет свой code и получит произвольный адрес.

Highload V3 race conditions

Highload-кошельки используются проектами для массовых выплат (стейкинг-награды, дроп-листы). У них своя specfic — query_id с TTL, защита от replay через bitmap. Ошибки реализации highload-логики в новых контрактах (когда команда копирует pattern, но забывает про nonce-uniqueness) — частый medium-tier finding.

Bounce-handler misuse

Bounce-сообщение даёт только 256 бит, useful — 224. Сложные state recovery невозможны. Если в bounce-handler заложена логика «вернём пользователю jetton’ы, если outbound fail’нулся», но в bounced msg недостаточно данных для восстановления контекста — jetton’ы остаются в контракте permanently.

Антипаттерн: recv_internal без явного if ctx.at(IS_BOUNCED) {...} блока. Все outbound сообщения должны быть отправлены с bounceable=true (флаг 0x18), и контракт должен явно обрабатывать bounce.

Tact-специфичные ловушки

Из CertiK pitfalls:

• amount: Int вместо Coins или uint256 — допускает negative values, атакующий шлёт amount = -100, bypass balance check.
• response_destination: Address вместо Address? — транзакции с zero-address (addr_none) валятся.
• Сериализация index: Int как int257 вместо uint256 — сообщения становятся undecodable у получателя.

Инструменты охотника

Acton Foundry

Российская/постсоветская разработка 2025–2026, де-факто становится стандартом для TON-аудиторов. Делает три ключевые вещи:

• Mutation testing (показывает, какие проверки в коде «мертвы» — никакой mutation их не ломает).
• Retrace (восстановление полного контекста транзакции из mainnet или fork).
• Линт по правилам CertiK и SlowMist.

Глубже — в нашем гайде по Acton.

Misti — статанализатор для Tact

Репо — github.com/nowarp/misti. Установка — npm i -g @nowarp/misti. Запуск — misti /path/to/contracts/*.tact.

Готовые детекторы: CellOverflow, StringReceiversOverlap, SendInLoop, UnboundMap, DivideBeforeMultiply, SuspiciousMessageMode, ZeroAddress, InheritedStateMutation. Каждый warning — потенциальный bug, проверяется вручную.

Конкурент в EVM — Slither. Покрытие пока меньше, но активно растёт.

TSA (TON Symbolic Analyzer)

Symbolic execution всех путей кода — доказывает unreachable states, находит assert violations. Глубже Misti, но медленнее. Использовать после Misti как deep-check на выделенных handler’ах.

EmulatorEx и pytoniq

pytoniq_core.contract.emulator.EmulatorEx — локальный TVM-эмулятор. Эмулирует exploit-сценарий без газа, без deploy’а, без подключения к сети. Это золото для PoC: подтверждение бага через EmulatorEx — самый быстрый способ.

Альтернатива на TypeScript — @ton/sandbox (часть @ton/blueprint). Удобнее для тех, кто пишет тесты на TS.

Tonscan и TonAPI

Для on-chain forensics. Tonscan — UI для чтения транзакций и контрактов, TonAPI — программный доступ. Используются на этапе recon: смотрим, как реально взаимодействуют контракты в mainnet, кто кому какие сообщения шлёт, какой TVL под угрозой.

8-фазный workflow аудита

Методика собрана из практики аудита STON.fi v2 и funcbox весной 2026. Применима к любому контракту на FunC или Tact.

Фаза 1 — Recon (1–2 часа). Понять, зачем этот контракт существует и что защищает. Читаем README, whitepaper, audit reports (если есть), Twitter/blog за 3 месяца на post-mortem’ы. Отвечаем на вопросы: какие активы хранятся, кто платит газ, где админ-привилегии, какой TVL под risk.

Фаза 2 — Mapping (2–4 часа). Карта входных точек и storage. Подсчёт строк (find ... -name "*.fc" -o -name "*.tact" | xargs wc -l), сортировка по размеру (большой = сложный = больше attack surface). Каталог опкодов (grep -r "op::"). Каждый recv_internal — entry point, каждый branch внутри — отдельная attack surface.

Фаза 3 — Trust Model (1–2 часа). Для каждой операции — кто может её триггерить. Найти все equal_slices(ctx.at(SENDER), ...), выписать trust boundaries. Проверить state-init derivation: все ли поля влияющие на адрес проверяются, загружается ли code cell из storage, верный ли workchain.

Фаза 4 — Bug-class checklist. Для каждого entry point прогнать систематический чек-лист. TVM/FunC: impure-модификаторы, bounce-handlers, gas-checks, set_code под admin+timelock, force_chain() для критических адресов, end_parse(). Tact: amount не Int, jetton sender валидируется, bounce-mode корректный. Domain-specifics: slippage и reserves overflow для DEX, health factor и oracle freshness для лендинга, rate update atomicity для LST.

Фаза 5 — State Invariants. Для каждой операции — что должно остаться true после её выполнения. Это самая ценная часть аудита. Bug = нарушение invariant’а, которое атакующий может вызвать. Примеры для DEX: reserve0 * reserve1 >= k_before, total_supply_lp == sum(lp_balances). Для LST: pool.ton_balance / jetton.total_supply >= rate_at_last_rebase.

Фаза 6 — Bounce Path Analysis. Для каждого outbound сообщения — что будет если оно bounce’нется. Самый частый источник багов на TON. Реальный пример из STON.fi: vault шлёт vault_pay_to к router’у и разрушает себя (DESTROY_IF_ZERO); если target jetton-wallet не задеплоен — bounce обратно к router’у; router пытается refund vault — но vault уже уничтожен; fees потеряны.

Фаза 7 — PoC Construction. Превратить гипотезу в reproducible exploit. Setup в @ton/sandbox или через pytoniq EmulatorEx. PoC должен показать: initial state, crafted message, final state, quantified damage (сколько TON / jetton потеряно). Без quantified damage отчёт rejected.

Фаза 8 — Reporting. Структура: Severity (по таблице программы) → Impact → Affected Component (контракт, файл, line numbers) → Root Cause → Reproduction Steps → PoC → Suggested Fix → References (CertiK pitfall #N, SlowMist guide §N, similar bugs в других проектах).

Реалистичные ожидания

Главное, что нужно понимать перед стартом: 1–2 валидных находки за 3–6 месяцев соло-охоты, payout обычно $100–5 000. Это нормальная картина. Шестизначные payout — единичные события года, обычно связанные с критическими находками в bridge или core protocol.

Что это значит на практике:

• За первый год работы при дисциплине 10–15 часов в неделю реалистичный заработок — $3 000–15 000. Это не зарплата, это бонус к основному доходу.
• Для full-time TON bug hunting (доход $50 000+ в год) нужно либо системно работать с 5–10 программами параллельно, либо специализироваться на конкретной нише (например, исключительно bridges или DeFi-лендинг).
• Многие бросают на втором месяце, когда становится очевидно, что лёгких денег нет. Те, кто выдерживает, через 12–18 месяцев имеют шанс на $100k+ годовой доход, плюс возможность пойти в аудит-команду на full-time.

Альтернативные пути роста после первой находки:

• Top-tier аудит: Certora, Trail of Bits, OpenZeppelin платят $200–500k/год full-time.
• Code4rena и Sherlock контесты: после освоения TON добавить Solidity, top-1% участников зарабатывают $200k–1M/год.
• Свой аудит-сервис: после 5–10 публичных находок — собственные клиенты, freelance аудиты $5–50k каждый.
• TON Foundation grants: за интересные инструменты безопасности — гранты до $50k.

Disclosure path: как написать отчёт, чтобы его приняли

Что должно быть в отчёте:

1. Severity строго по таблице конкретной программы. Не завышайте — это раздражает reviewer’ов и снижает шансы. Завышенный severity обычно приводит к downgrade и meньшему payout.
2. Impact в одном-двух предложениях. Что атакующий получает, сколько денег может извлечь, при каких условиях.
3. Affected Component — точные строки в коде. Не «функция swap», а «contracts/router.fc, line 247–268, handle_swap handler».
4. Root Cause — точная техническая причина. Какая проверка отсутствует или какая логика неверна. Не «контракт небезопасен», а «отсутствует валидация sender == expected_jetton_wallet перед обработкой transfer_notification».
5. Reproduction Steps — пошагово, с конкретными значениями.
6. PoC — ссылка на gist или embedded code. Должен запускаться на чистом окружении (git clone && npm install && npm test).
7. Quantified Damage — обязательно. «10 000 USDT извлечено за одну транзакцию» или «весь TVL пула заперт permanent». Без цифр — теоретическая уязвимость, на которую обычно не платят.
8. Suggested Fix — конкретный change в коде. Показывает, что вы понимаете root cause, а не просто наткнулись на symptom.
9. References — какой pitfall из CertiK / SlowMist / arxiv-работ это иллюстрирует. Если это известный класс ошибок — назовите его. Если это новый паттерн — объясните, чем он отличается от известных.

Как НЕ делать — антипаттерны

Эксплойт в mainnet без авторизации. Любая транзакция, демонстрирующая bug на mainnet, — это уже состав уголовной статьи. Даже если вы тут же вернули средства, факт неправомерного доступа зафиксирован on-chain. PoC только в fork mainnet или testnet, никогда в реальной транзакции.

Публикация PoC до фикса. Disclosure breach = ноль payout + бан в программе + риск отзыва payout у других researcher’ов, которые использовали тот же канал. Не публикуйте баг в Twitter/Telegram/GitHub Issues до окончания disclosure window (обычно 90 дней или после подтверждённого фикса).

Retaliation за низкий payout. Если команда заплатила $500 вместо ожидаемых $5 000 — это, возможно, неприятно, но публичная реакция («команда X кинула меня на bug bounty») гарантированно закрывает вам путь в индустрию. Все security-команды общаются между собой. Лучше — спокойно перейти к следующей программе.

Inside trading на знании undisclosed vulnerability. Если вы нашли bug в DEX и заранее зашортили его токен — это крипто-аналог инсайдерской торговли. Регуляторы пока на TON не дотягиваются, но репутационно — это убийство карьеры.

Контакт с командой через нерекомендованные каналы. Только официальная форма submission. Telegram личного разработчика команды — не канал для security disclosure. Это создаёт серую зону, в которой ответственность за обработку отчёта размыта.

Будущее TON bug bounty

К концу 2026 ожидается:

• Рост программ от перспективных DeFi-проектов. По мере роста TVL экосистемы (на май 2026 — около $300–400M, прогноз на конец года — $500M–1B) больше команд могут позволить себе выделять бюджеты на bounty.
• Появление TON-специфичных аудит-фирм. Сейчас TON-аудит делают преимущественно SlowMist, CertiK, Trail of Bits — все они в основе EVM-команды с TON-практикой. К 2027 ожидаются native-команды.
• Стандартизация HackenProof как основной платформы для TON. Immunefi пока работает в основном с EVM, и догнать темп интеграции в TON для него сложно.
• Категория bridge-программ вырастет. После TAC drain и ряда других инцидентов 2026 года все мосты пересматривают свои security-программы.

Окно для соло-исследователя на TON ещё открыто, потому что инструменты молодые, классы багов каталогизируются, FunC и Tact знают на порядок меньше людей, чем Solidity. Через 2–3 года конкуренция вырастет, payout’ы выровняются с EVM, и зайти будет сложнее. Сейчас — лучшее время.