≈ 7 мин чтения

Смарт-контракты сработали. Почему 737 аккаунтов всё равно потеряли $2,73 млн?

Смарт-контракты сработали. Почему 737 аккаунтов всё равно потеряли $2,73 млн?

29 октября пользователи международной платформы Polymarket начали сообщать о продаже позиций и выводах средств, которые они не инициировали. Платформа временно остановила новые сделки и операции через relayer, а затем сообщила, что причиной стала компрометация стороннего провайдера.

По оценке Bitquery, за один час средства ушли с 737 аккаунтов, а общая сумма достигла примерно $2,73 млн. Это не официальный итог Polymarket: сама платформа пока не раскрыла ни количество пострадавших, ни размер ущерба.

Главная особенность инцидента заключается не только в его масштабе. Bitquery не обнаружила взлома смарт-контракта или обхода правил блокчейна. Подозрительные операции получили действительные разрешения и прошли через штатную инфраструктуру Polymarket.

Иными словами, система исполнила транзакции, которые технически выглядели авторизованными, хотя владельцы аккаунтов утверждали, что не давали согласия на вывод средств.

Что произошло 29 октября

Согласно on-chain анализу Bitquery, основная волна началась в 17:10 UTC. Сначала были опустошены пять аккаунтов, один из которых потерял около $75 000. После паузы продолжительностью 13 минут количество операций резко выросло и в отдельные минуты достигало 40 выводов.

К 18:10 UTC Bitquery насчитала 737 затронутых аккаунтов. Крупнейшая отдельная потеря в исследовании составила около $358 000. При этом распределение было крайне неравномерным:

  • 39% затронутых кошельков потеряли менее $100;
  • четыре крупнейших аккаунта дали 43% всей отслеженной суммы;
  • с 33 аккаунтов были выведены не только денежные остатки, но и открытые позиции.

В 18:05 UTC официальная страница статуса Polymarket сообщила о переходе биржи в режим cancel-only: существующие заявки можно было отменять, но новые заявки и сделки не принимались. Одновременно были приостановлены операции через relayer.

В 18:37 UTC Polymarket заявила, что проблема обнаружена и исправлена. Компания сообщила о компрометации одного из сторонних провайдеров, передаче дела правоохранительным органам и намерении полностью компенсировать потери пострадавшим.

В 19:05 UTC инцидент на странице статуса был отмечен как устранённый. Таким образом, официально ограничения продолжались около часа.

Как сторонний скрипт мог повлиять на деньги

Современная торговая платформа редко состоит только из собственного кода. Веб-страница может загружать внешние компоненты для аналитики, мониторинга производительности, поддержки пользователей, рекламы и обнаружения ошибок.

Такую интеграцию подключает владелец сайта, а не каждый пользователь отдельно. В данном случае речь идёт о скрипте мониторинга, который был встроен в сайт Polymarket. Когда человек открывал платформу, его браузер автоматически загружал этот компонент вместе с остальной страницей. Устанавливать программу, расширение или отдельный инструмент DebugBear пользователю не требовалось.

Внешний компонент выполняется в браузере рядом с основным приложением и внутри уже открытой страницы Polymarket. Если поставщик такого скрипта оказывается скомпрометирован, вредоносный код может попасть на доверенный сайт через штатную интеграцию и взаимодействовать с активной пользовательской сессией.

Polymarket официально не назвала провайдера. Однако Associated Press и другие издания связали инцидент с сервисом мониторинга производительности DebugBear. Сам DebugBear в тот же день сообщил о собственной проблеме безопасности и рекомендовал клиентам удалить встроенный код продукта Real User Monitoring.

BleepingComputer изучил копию вредоносного JavaScript и пришёл к выводу, что он проверял активную сессию Polymarket, оценивал доступные остатки и позиции, а затем пытался использовать обычные функции платформы для их вывода.

Это принципиально отличается от взлома смарт-контракта. Контракт мог правильно проверить полученное разрешение и точно выполнить заданную операцию. Проблема возникла раньше: в интерфейсе, который подготовил действие от имени уже авторизованного пользователя.

Что такое deposit wallet, approval и relayer

Чтобы понять механику, достаточно разделить три элемента.

Deposit wallet хранит средства конкретного аккаунта в сети Polygon. По описанию Bitquery, внутри использовался pUSD, обеспеченный USDC в соотношении один к одному.

Approval подтверждает, что кошелёк разрешает определённое действие. Для блокчейна это криптографически корректная команда. Но блокчейн не может определить, действительно ли человек осознанно хотел выполнить её, был ли интерфейс подменён или авторизованная сессия использовалась посторонним кодом.

Relayer отправляет операцию в блокчейн и оплачивает сетевую комиссию вместо пользователя. Благодаря этому работа с платформой выглядит проще: человеку не приходится отдельно оплачивать каждое действие нативной монетой сети.

При обычном выводе пользователь выбирает актив и адрес, подтверждает действие, после чего relayer передаёт его в сеть. По данным Bitquery, 29 октября этот маршрут продолжал работать штатно. Изменился конечный адрес: средства направлялись на кошелёк, контролируемый атакующей стороной.

Поэтому формулировка «транзакция имела действительное разрешение» не равна формулировке «пользователь добровольно подтвердил вывод». Первая описывает то, что увидел блокчейн. Вторая касается намерения человека, которое невозможно восстановить только по записи в сети.

Почему остановка relayer прекратила основную волну

Bitquery обратила внимание, что подозрительные выводы прекратились практически одновременно с остановкой relayer. Это не доказывает всех деталей атаки, но хорошо показывает роль инфраструктуры исполнения.

До инцидента вывод средств с конвертацией в POL через Relay происходил относительно редко. По подсчётам Bitquery, медианное значение за предыдущие две недели составляло около 47 таких операций в день. 29 октября один адрес получил 981 перевод.

Такое отклонение было заметно непосредственно в блокчейне. Оно ставит отдельный вопрос к мониторингу: должна ли система автоматически приостанавливать поток, когда один новый адрес за короткий период получает средства от сотен независимых аккаунтов?

Ответ не так прост, как кажется. Слишком жёсткие ограничения могут блокировать законные массовые операции и нарушать работу платформы. Но сочетание нескольких признаков выглядит значительно сильнее одного показателя:

  • необычно большое количество аккаунтов;
  • один и тот же адрес назначения;
  • резкий рост частоты выводов;
  • продажа открытых позиций перед выводом;
  • значительное отличие от обычной активности предыдущих дней.

Именно такие комбинации могут использоваться системами обнаружения аномалий без анализа торговой стратегии конкретного пользователя.

Куда ушли средства

По данным Bitquery, деньги конвертировались в POL, поступали на один основной адрес, а затем распределялись между новыми кошельками и начинали перемещаться в сторону Ethereum через мосты.

Исследование также описывает отдельный новый аккаунт Polymarket, который использовался для работы с украденными открытыми позициями. Outcome shares нельзя так же просто вывести, как обычный денежный остаток: сначала их нужно продать или погасить через инфраструктуру рынка. По версии Bitquery, часть этих позиций поступила на новый аккаунт и была конвертирована обратно в pUSD.

На момент последнего снимка данных, 19:49 UTC 29 октября, большая часть отслеженных средств всё ещё оставалась в сети Polygon. Эти сведения описывают только состояние блокчейна в конкретный момент и не являются окончательным отчётом о возвращённых или потерянных средствах.

Почему $2,73 млн и 737 аккаунтов остаются оценкой

Bitquery связала подозрительные переводы с одним адресом и проследила операции в Polygon и Ethereum. Однако on-chain анализ имеет ограничения.

Он показывает адреса, суммы, время и последовательность транзакций, но сам по себе не устанавливает личность атакующего и не объясняет, каким именно способом было получено каждое разрешение. Метки публичных аккаунтов также могут быть неполными.

Кроме того, оценка учитывает средства, прошедшие по найденному маршруту. Если существовали другие адреса или способы вывода, итоговая сумма могла отличаться. Стоимость POL и ETH также зависит от цены, выбранной для конкретного момента расчёта.

Поэтому корректная формулировка выглядит так: Bitquery оценила отслеженные потери в $2,73 млн с 737 аккаунтов. Polymarket эти цифры официально не подтвердила.

Что известно о компенсации

Polymarket заявила, что все пострадавшие будут полностью компенсированы. На момент подготовки статьи компания не опубликовала детальный отчёт с окончательным количеством аккаунтов, общей суммой выплат и сроками завершения компенсаций.

Это означает, что обещание платформы подтверждено, но история ещё не закончена. Окончательную оценку реакции можно будет дать после публикации результатов расследования или подтверждения фактических выплат.

Для пользователей источник проблемы не отменяет ответственность платформы за весь торговый маршрут. Клиент взаимодействует не с отдельным смарт-контрактом, relayer или поставщиком мониторинга, а с продуктом целиком. Если внешняя зависимость работает внутри доверенного интерфейса и получает доступ к авторизованной сессии, её безопасность становится частью безопасности платформы.

Это уже второй инцидент со сторонней зависимостью

В июне 2026 года Polymarket сообщала о другом случае, когда скомпрометированный сторонний поставщик внедрил вредоносный скрипт во фронтенд для части пользователей. Тогда компания также заявила о локализации проблемы и полной компенсации пострадавших.

Сходство двух историй очевидно: в обоих случаях Polymarket указывала на стороннюю зависимость, а воздействие происходило на уровне пользовательского интерфейса. Но пока нет достаточных оснований утверждать, что использовался одинаковый технический механизм или что инциденты связаны между собой.

Повторение общей категории риска всё равно важно. Безопасность внешнего JavaScript нельзя полностью передать его поставщику. Платформе приходится контролировать, какой код загружается в браузер, какие действия ему доступны, как быстро можно отключить интеграцию и какие аномалии должны остановить вывод средств автоматически.

Исправный смарт-контракт защищает не от всех угроз

В блокчейн-проектах безопасность часто обсуждают через аудит контрактов: можно ли обойти проверку, вывести чужие средства или изменить баланс вопреки правилам протокола.

Инцидент Polymarket показывает другую границу. Даже без ошибки в контракте пользователь остаётся зависимым от браузерного интерфейса, авторизованной сессии, внешних скриптов, механизма подписания и сервиса, который передаёт операцию в сеть.

Блокчейн способен подтвердить, что транзакция соответствует техническим правилам. Он не способен подтвердить, что человек видел корректный интерфейс, понимал конечный адрес и действительно хотел совершить именно это действие.

Поэтому безопасность торговой платформы нельзя оценивать только по надёжности её смарт-контрактов. Она охватывает всю цепочку:

сторонний код → браузерная сессия → разрешение → relayer → смарт-контракт → адрес получателя

29 октября последняя часть этой цепочки сработала именно так, как была спроектирована. Но компрометации в начале маршрута оказалось достаточно, чтобы корректное исполнение привело к неправильному для пользователя результату.

Polymarket быстро ограничила операции, восстановила торговлю и пообещала компенсации. Теперь важны две вещи: подтверждение выплат и объяснение того, какие изменения не позволят сторонней зависимости снова превратить доверенный интерфейс в источник авторизованных, но нежелательных транзакций.