---
title: "Как работают программы вознаграждений за уязвимости в криптосистемах"
description: "Криптовалютная bug bounty — версионируемый процесс раскрытия и вознаграждения, в котором отдельно проверяются охват, разрешение, доказательства, серьезность, исправление, раскрытие и условия выплаты."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Как работают программы вознаграждений за уязвимости в криптосистемах
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Криптовалютная bug bounty — версионируемый процесс, в рамках которого проект принимает закрытые сообщения об определенных уязвимостях и может вознаградить отчеты, соответствующие действующим правилам. Это не то же самое, что политика раскрытия уязвимостей: такая политика может задавать канал связи и условия разрешенного исследования без обещания оплаты. Ни один из этих документов не является сертификацией, страховкой, трудовыми отношениями или доказательством безопасности системы.
Определяющим документом служит сохраненный снимок программы, а не название проекта или сегодняшняя веб-страница. Зафиксируйте URL, редакцию и время политики; точные сети, контракты, реализации прокси, репозитории, коммиты и релизы; допустимые последствия; исключенные системы и методы; таблицу и предел вознаграждений; правила подачи и раскрытия; формулировку безопасной гавани; условия идентификации, санкций, налогов и выплаты. Охват определяется пересечением актива, версии, сети, последствия и разрешенного метода тестирования.
Безопасная гавань может описывать намерение организации в отношении добросовестного исследования по ее правилам. Она не расширяет охват, не связывает третьих лиц или правоохранительные органы, не отменяет нормы других юрисдикций и не оправдывает нарушение приватности, сбои, вымогательство или несанкционированное перемещение средств. Если разрешение неясно, до тестирования задайте вопрос через официальный канал.
Ведите четыре раздельных реестра: разрешение и доказательства; техническая эксплуатируемость и экономический ущерб; временные меры, окончательное исправление и раскрытие; вознаграждение, комплаенс и выплата. Метка `critical` сама по себе не определяет вознаграждение, решение о нем не является платежной квитанцией, а один пройденный модульный тест не доказывает безопасность затронутого развертывания.
## Как это работает
Тестирование должно оставаться в пределах сохраненных правил. Минимальный PoC обычно развивается от статического анализа и модульных либо property-тестов к локальному форку или иной явно разрешенной среде. Тестирование в основной или публичной тестовой сети, отказ в обслуживании, социальная инженерия, сторонние системы или персональные данные могут быть запрещены. Не перемещайте и не удерживайте реальные пользовательские активы только ради доказательства ущерба и не считайте спасение средств во время активной атаки разрешенным обычной программой.
Полезный отчет фиксирует сеть, адрес, реализацию, коммит, блок состояния и снимок политики. В нем указываются предпосылки, точные шаги воспроизведения, ожидаемое и фактическое поведение, последовательность транзакций или calldata, хэши артефактов, технический путь, реалистичная граница ущерба, капитал и привилегии атакующего, допущения и защищенный канал связи. Шифруйте пригодные для атаки материалы и чувствительные данные, минимизируйте сбор, регистрируйте доступ и сохраняйте хронологию.
При разборе следует отдельно определять охват, дубликат или известную проблему, техническую эксплуатируемость, экономический ущерб, серьезность и право на вознаграждение. Технический класс не определяет реализуемый убыток. Капитал, права, конкуренция, ликвидность, окна оракулов, лимиты, паузы, риск реорганизации, повторяемость и действия пользователя меняют результат. Первое сообщение не обязательно является первым полным допустимым отчетом; решают сохраненное правило о дубликатах и доказательства прежнего знания.
Подтверждение, воспроизведение, решение о серьезности, срочное ограничение, окончательное исправление, раскрытие, утверждение награды и выплата — разные состояния и интервалы. Цели `24 hours` или `72 hours` имеют значение только тогда, когда их определяет конкретная программа или план инцидента. Молчание операционно вредно, но из слов bug bounty нельзя вывести универсальный срок ответа.
Срочная мера может остановить функцию, снизить лимит, убрать маршрут из интерфейса или изменить мониторинг, однако это не окончательное исправление. Обновление должно проверять полномочия, timelock или аварийные права, реализацию и инициализатор, схему хранения, миграцию и откат. Превратите исходный PoC в регрессионный тест, проверьте соседние пути и инварианты, смоделируйте развернутое состояние, подтвердите квитанции исполнения и следите за фактическими версиями во всех затронутых сетях.
Для раскрытия нужны закрытый канал, начало эмбарго, частота обновлений, правила продления и экстренной публикации, авторство или анонимность исследователя, а также условия хранения или удаления доказательств. Выплата требует отдельной сверки: номинальная награда, формула или усмотрение, валюта и снимок курса, KYC или санкционная проверка, налоговые формы либо удержание, сеть и адрес назначения, комиссии, статус утверждения, идентификатор транзакции и полученная сумма.
Используйте следующий порядок:
1. Сохраните снимок программы: URL, редакцию и время, точные активы, сети, адреса, реализации, коммиты, допустимые последствия, исключения, условия награды, безопасную гавань и политику раскрытия.
2. Получите письменное разрешение для исследователя, системы, среды, метода, частоты запросов, обработки данных и границы третьих лиц; при неясности остановитесь и спросите.
3. Создайте минимальный безвредный PoC в специально разрешенной среде; зафиксируйте код и состояние, оцените предпосылки и ущерб и остановитесь, когда доказательств достаточно.
4. Отправьте отчет через разрешенный защищенный канал с идентификатором, временем, зашифрованными артефактами, хэшами, шагами, реестром ущерба, допущениями и историей связи.
5. Определите охват и статус дубликата или известной проблемы, затем независимо оцените эксплуатируемость, экономический ущерб, серьезность и право на награду по сохраненным правилам.
6. Отслеживайте временные меры, патч или миграцию, проверку обновления и хранения, регрессионные и инвариантные тесты, квитанции развертывания, мониторинг и согласованное раскрытие как разные состояния.
7. Сверьте утвержденную награду, валюту и курс, KYC, санкции, налоги, сеть, адрес, комиссии и платежную квитанцию; храните проверяемую запись без лишних чувствительных данных.
## Примеры
- **Охват уже совпадения по названию.** Снимок программы содержит `12 assets`. Отчет упоминает `9`; только `7` соответствуют указанным сети и развернутой версии, один является сторонним оракулом, другой — невыпущенным коммитом. Совпадение имен равно `9 / 12 = 75%`, но разрешенное покрытие охвата — `7 / 12 = 58.33333333%`. Право определяет снимок, а не процент.
- **Ущерб, серьезность и возможная награда различны.** Воспроизводимая прямая стоимость под риском равна `$8,000,000`. Гипотетическое сохраненное правило платит `10%` с минимумом `$50,000` и пределом `$500,000`. Исходный расчет — `$8,000,000 * 0.10 = $800,000`, поэтому после предела возможная награда равна `$500,000`. Требование привилегированной подписи может перевести отчет в иной уровень серьезности или награды; расчет не создает права и не является универсальной формулой.
- **Каждый интервал ответа измеряет отдельное состояние.** Отчет подан `2026-08-13 09:00`; подтверждение в `11:30` заняло `2.5 hours`; разбор в `2026-08-14 16:00` — `31 hours`; временный лимит в `21:00` — `36 hours`; развертывание патча в `2026-08-16 21:00` — `84 hours`; согласованное раскрытие в `2026-08-23 09:00` — `240 hours`, или `10 days`. Быстрое подтверждение не означает быстрого исправления или платежа.
- **Номинальная награда и расчет разделены.** Утвержденные `$500,000` выплачиваются в USDC по фиксированному курсу `$1.002 per USDC`, поэтому причитается `$500,000 / $1.002 = 499,001.996008 USDC`. Если проект отдельно платит сетевую комиссию `$18`, исследователь получает `499,001.996008 USDC`; если комиссия вычитается, полученная стоимость равна `$499,982` по фиксированному курсу. Налоги и удержания остаются отдельными записями.
## Риски
- Страница политики меняется, а датированного снимка нет.
- Проверяемые актив, версия, сеть, адрес или реализация находятся вне охвата.
- Обновление прокси меняет затронутый код во время исследования или исправления.
- Безопасную гавань принимают за всеобщий юридический иммунитет.
- Тест достигает исключенного поставщика, оракула, аккаунта пользователя или иной третьей стороны.
- Действия в основной или публичной тестовой сети нарушают правила среды.
- PoC перемещает реальные средства, нарушает работу или получает персональные данные.
- Автоматизация превышает предел нагрузки или превращается в отказ в обслуживании.
- Социальная инженерия, фишинг, принуждение или вымогательство выходят за разрешение.
- PoC собирает или раскрывает больше пригодных для атаки данных, чем нужно.
- Незащищенный канал подачи раскрывает секреты, пользовательские данные или детали атаки.
- Хэши, время, версии кода или состояние сети невозможно воспроизвести.
- Доказательства дубликата, прежнего знания или первого допустимого отчета неполны.
- Название класса уязвимости задает уровень без проверки предпосылок и достижимости.
- Теоретическую стоимость под риском принимают за реализуемый убыток или прибыль атакующего.
- Неверно читаются минимум, предел, усмотрение, валюта или условия права на награду.
- KYC, санкции, налоги, счет или платежная сеть задерживают либо блокируют расчет.
- Молчание, неясные интервалы или преждевременное раскрытие повышают риск атаки.
- Срочная пауза, лимит, обновление, изменение хранения или миграция создают новый ущерб.
- Награда, аудит, формальное доказательство или мониторинг считаются гарантией безопасности.
## Распространенные заблуждения
- **Публичная программа разрешает тестировать все связанные активы и методы.** Разрешение ограничено сохраненными активом, версией, последствием, средой и правилами поведения.
- **Безопасная гавань гарантирует иммунитет в любой юрисдикции.** Это условная политика, которая не связывает каждую третью сторону или государственный орган.
- **Метка critical или процент ущерба автоматически определяет выплату.** Серьезность, право, условия, пределы, усмотрение и расчет остаются разными.
- **Первое сообщение всегда выигрывает дубликат, а перемещение средств доказывает ущерб.** Программа может требовать первый полный допустимый отчет, а несанкционированный вред способен лишить награды и создать юридический риск.
- **Награда и аудит доказывают отсутствие ошибок после успешных тестов патча.** Аудиты, формальные методы, тестирование, bounty, мониторинг и реагирование покрывают разные версии, допущения и отказы.
## Связанные темы
- [Аудит смарт-контракта](/ru/crypto/contract-audit/)
- [Смарт-контракт](/ru/crypto/smart-contract/)
- [Атака повторного входа](/ru/crypto/reentrancy-attack/)
## Источники
- [Immunefi Rules](https://immunefi.com/rules/) - Immunefi (дата обращения: 2026-08-13)
- [Immunefi Vulnerability Severity Classification System v2.3](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/) - Immunefi (дата обращения: 2026-08-13)
- [Binding Operational Directive 20-01](https://www.cisa.gov/sites/default/files/bod-20-01.pdf) - Cybersecurity and Infrastructure Security Agency (дата обращения: 2026-08-13)
- [Department of Justice Announces New Policy for Charging Cases under the Computer Fraud and Abuse Act](https://www.justice.gov/archives/opa/pr/department-justice-announces-new-policy-charging-cases-under-computer-fraud-and-abuse-act) - U.S. Department of Justice (дата обращения: 2026-08-13)
- [Safe Harbor Overview & FAQ](https://docs.hackerone.com/en/articles/8494502-safe-harbor-overview-faq) - HackerOne (дата обращения: 2026-08-13)
- [Bug Bounty Program](https://ethereum.org/bug-bounty/) - ethereum.org (дата обращения: 2026-08-13)
- [Writing Upgradeable Contracts](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin Docs (дата обращения: 2026-08-13)
- [Secure Software Development Framework (SSDF) Version 1.1](https://csrc.nist.gov/pubs/sp/800/218/final) - National Institute of Standards and Technology (дата обращения: 2026-08-13)
Source: https://wiki.fcontext.com/ru/crypto/bug-bounty/index.mdx