Як повідомляє Cryptopolitan 10 червня, анонімні нападники через накопичення токенів Token of Power (TOP) із понад 50% від обсягу в обігу в межах одного операції завершили створення, голосування та виконання пропозиції з управління (governance). Після карбування значної кількості нових токенів вони спорожнили пул ліквідності Balancer V1 у мережі Ethereum і вилучили 944,2 WETH (приблизно 1,58 млн доларів).
Механізм атаки: як 8 192 TOP завершили перехоплення управління в одній транзакції
Загальна пропозиція токенів TOP становить 16 384 токени. Згідно з ончейн-аналізом Blockaid, нападники накопичили 8 192,000001 TOP — рівно понад поріг 50%, що дало їм право голосувати однією стороною за пропозицію з управління. Оскільки застосунок Aragon Voting не має часових блокувань, нападники через спеціальний контракт у межах однієї транзакції виконали три кроки:
Створення пропозиції з управління: вимога карбувати велику кількість нових токенів TOP на адресу нападника
Прийняття пропозиції: одноосібне схвалення завдяки праву голосу понад 50%
Негайне виконання й очищення пулу ліквідності: новокарбовані TOP-токени в Balancer V1 BPool обмінялися на 944,2 WETH
BlockSec Phalcon підтвердив процес виконання пропозиції та карбування токенів. Сам Balancer не має вразливостей: нападники лише використали пул ліквідності, щоб токени TOP із штучно розширеним обсягом пропозиції обмінялися на WETH.
Шлях коштів: поповнення Tornado Cash та поточний стан ончейн-трекінгу
Згідно з ончейн-аналізом Blockaid, початковим джерелом коштів гаманця нападників був Tornado Cash; атака виконувалася через спеціальний контракт у межах однієї транзакції. Станом на момент повідомлення 10 червня 2026 року 944,2 WETH усе ще відстежуються в ланцюжку, але початкове джерело коштів із Tornado Cash ускладнило відстеження, а також підвищило труднощі для повернення коштів і підтвердження особи нападників.
Корінна причина: відсутність налаштувань управління, а не баг у коді смартконтракту
Корінною причиною цього інциденту стало те, чого бракувало на рівні налаштувань управління, а не традиційна помилка у виконанні коду смартконтракту — усі функції контрактів працювали за задумом. Конкретні відсутні налаштування включали:
Без часових блокувань: після ухвалення пропозиції немає періоду очікування, інші власники токенів не мають часу відреагувати
Відсутній поріг кворуму, що відтерміновує: не вимагається участь щонайменше певної частки власників токенів у голосуванні
Немає затримки створення пропозиції: пропозицію можна створити та виконати в межах одного й того ж блока
Загальна пропозиція TOP становить лише 16 384 токени, тож вартість отримання більшості для контролю дуже низька. Офіційна документація Aragon чітко зазначає, що права на виклик чутливих операцій, зокрема карбування токенів, мають бути обмежені авторизованими адресами, але налаштування TOP цього не врахували.
Стан на момент публікації: відсутні заяви, кошти досі в ланцюжку
Повідомлення Cryptopolitan підтверджує, що станом на 10 червня 2026 року: команда Token of Power не опублікувала жодних заяв щодо цього інциденту; Aragon також не робив жодних заяв; 944,2 WETH усе ще можна відстежити в ланцюжку.
Поширені запитання
Чому цю атаку класифікували як «вразливість управління», а не «вразливість смартконтракту»?
Традиційні вразливості смартконтрактів означають, що нападники обходять очікувану логіку через недоліки в коді. У цьому випадку всі функції контрактів виконувалися відповідно до задуму — голосування з управління працювало коректно, а карбування токенів відповідало дозволам, заданим для DAO. Проблема в тому, що налаштування DAO для TOP дозволяють одному власнику повністю контролювати процес управління без будь-якої часової затримки — це недолік на рівні налаштувань, а не помилка в коді.
Чи має протокол Balancer нести відповідальність?
Згідно з аналізом Blockaid і BlockSec Phalcon, сам протокол Balancer не має жодних вразливостей. Нападники використовували стандартну функцію обміну токенів, перетворивши TOP-токени з штучно збільшеним обсягом пропозиції на WETH; Balancer як інструмент пулу ліквідності було використано, але він не є метою атаки й не є джерелом вразливості.
Які налаштування управління можуть запобігти подібним атакам?
Згідно з офіційною документацією Aragon та ончейн-аналізом цього інциденту, такі три налаштування можуть запобігти атакам подібного типу: часові блокування (встановлення періоду очікування між ухваленням пропозиції та її виконанням); кворум (вимога щодо участі мінімальної частки власників у голосуванні); затримка пропозиції (після створення пропозиції — дозволяти голосування лише через певний час). Станом на 10 червня 2026 року TOP не впровадив жодного з указаних налаштувань.
