Вибухова правда про криптоботи, які передують крадіям, щоб "зберегти" кошти — але саме вони вирішують, кому повернуть гроші

Source: CryptoNewsNet Original Title: Explosive truth behind crypto bots that front-run thieves to “save” funds — but they decide who gets paid back Original Link:

Інцидент з Makina Finance

Makina Finance втратила 1299 ETH, приблизно 4,13 мільйонів доларів, через експлойт з флеш-замовленнями та маніпуляції з оракунами.

Зловмисник висмоктав кошти протоколу та транслював транзакцію у публічний мемпул Ethereum, де її мали б підхопити валідатори та включити у наступний блок.

Замість цього, MEV-будівельник, ідентифікований за адресою 0xa6c2, передрукував транзакцію з витоку, перенаправивши більшу частину коштів у власний сейф, перш ніж хакер зможе вивести їх офф-чейн.

Транзакція хакера зазнала невдачі. Кошти опинилися на двох адресах, пов’язаних з MEV-будівельником.

Негайний висновок — користувачі Makina уникнули повної втрати. Глибший сигнал — хто в кінцевому підсумку тримав гроші і що це означає для нової системи реагування на надзвичайні ситуації у крипто.

Найважливішим актором у цій історії є не зловмисник чи протокол, а ланцюг постачання блоків, який перехопив експлойт і тепер контролює, чи повернуть користувачам їхні кошти, за яких умов і наскільки швидко.

Боти та будівельники MEV стають останнім рубежем захисту у крипто, і це не за задумом, а через структурне положення. Це проблема, оскільки здатність до порятунку зосереджена в руках прибуткоорієнтованих посередників, які діють із невизначеною відповідальністю.

MEV як резервний механізм уже є шаблоном

Інцидент з Makina не є унікальним. Chainalysis задокументувала подібну динаміку під час експлойту Curve та Vyper 2023 року, зазначаючи, що білі хати та оператори MEV-ботів допомагали відновлювати кошти, що зменшувало зафіксовані збитки нижче за початкові оцінки.

Шаблон механічний: доки експлойти або спроби порятунку видно у публічних транзакційних каналах, досвідчені пошуковці та будівельники можуть конкурувати за перерозподіл транзакцій.

Іноді вони рятують кошти. Іноді — захоплюють їх. У будь-якому разі, вони виконують роль фактичного шару реагування у надзвичайних ситуаціях.

Коли транзакція експлойту потрапляє у публічний мемпул, пошуковці MEV слідкують за вигідними можливостями. Якщо хакер висмоктує кошти з протоколу і транслює транзакцію публічно, пошуковець може створити конкуренційну транзакцію, яка виконається першою, перенаправляючи кошти на іншу адресу.

Пошуковець об’єднує транзакцію і подає її до блокового будівельника, який включає її, якщо прибуток перевищує конкуренційні ставки. Якщо блок будівельника обирає валідатор, транзакція пошуковця виконується, а транзакція хакера зазнає невдачі.

Це вилучення прибутку з додатковим корисним побічним ефектом, а не чисте альтруїстичне діяння. Але це також найнадійніший механізм, який крипто розробило для перехоплення експлойтів у реальному часі, оскільки він працює на рівні порядку транзакцій, а не покладається на протокольні автоматичні механізми або управлінські рішення.

Чому залежність від будівельників MEV викликає занепокоєння

Проблема з порятунками на основі MEV полягає в тому, що вони концентрують здатність реагування у дуже посередницькому ланцюгу.

У Ethereum MEV-Boost домінує у виробництві блоків. Огляд Relay від Rated показує, що приблизно 93,5% останніх блоків маршрутизуються через MEV-Boost, тоді як приблизно 6% — через стандартне виробництво блоків.

У межах MEV-Boost частка ринку Relay ще більше зосереджена: Ultra Sound Money становить приблизно 29,84% трафіку Relay, а Titan — приблизно 24,24%, тобто дві найбільші реле разом обробляють понад 54% виробництва блоків.

Якщо більшість блоків проходить через MEV-Boost, а більшість трафіку MEV-Boost — через два реле, то рівень залежності шару порятунку структурно залежить від невеликої кількості посередників. Це швидко створює проблеми управління.

Якщо будівельник опиниться у володінні врятованих коштів, хто дозволяє зберігання? Хто встановлює винагороду? Що запобігає шантажу або вимагання викупу? Що, якщо будівельник офшорний, анонімний або працює у юрисдикції з слабким правовим захистом?

Приклад з Makina ілюструє цю проблему. Кошти перебувають у володінні будівельника, але немає публічного SLA, попередньо визначеної винагороди або чітких механізмів повернення коштів Makina або її користувачам.

Будівельник може добровільно повернути кошти, домовитися про винагороду, вимагати більшу плату, ніж у галузевих нормах, або відмовитися повертати їх зовсім.

Приватне маршрутування погіршує ситуацію

Наукова стаття 2025 року під назвою “Sandwiched and Silent” задокументувала поширене приватне маршрутування транзакцій і виявила, що багато жертв мігрують у приватні канали після того, як їх “запакували” MEV-боти.

Однак приватне маршрутування не усуває MEV, воно лише переносить його з публічних мемпулів у приватні канали порядку, контрольовані будівельниками та реле.

Для протоколів це означає, що порятунки у публічному мемпулі стають менш надійними, оскільки експлойтні транзакції дедалі більше маршрутизуються через приватні канали, доступні лише обмеженому колу будівельників.

Спроба цивілізувати хаос

Safe Harbor — це рамкова концепція, розроблена SEAL, яка прагне замінити модель “будівельник MEV як випадковий зберігач” на авторизованих реагувальників, чіткі SLA та обмежені стимули.

SEAL описує Safe Harbor як юридичну та технічну рамку, яка дозволяє протоколам попередньо авторизувати білі хати для втручання під час активних експлойтів.

Основне правило — що врятовані кошти мають бути надіслані на офіційні адреси відновлення протягом 72 годин, з попередньо визначеними, обов’язковими винагородами.

SEAL стверджує, що Safe Harbor був мотивований хакерською атакою Nomad, коли білі хати були готові допомогти, але були обмежені юридичною невизначеністю щодо того, чи можна повернення коштів кваліфікувати як несанкціонований доступ до комп’ютерних систем.

Safe Harbor усуває цю невизначеність, надаючи протоколам спосіб попередньо авторизувати втручання і встановити чіткі умови. SEAL стверджує, що Safe Harbor уже захищає понад $16 мільярдів доларів у провідних протоколах, включаючи деякі DEX, Pendle, окремі рішення рівня 2 і zkSync.

Платформа Immunefi, що займається винагородами за баги, вже реалізувала Safe Harbor із більш жорсткими умовами.

Immunefi описує Safe Harbor як рамкову концепцію, розроблену SEAL, яка перенаправляє кошти до сейфу, контрольованого протоколом, на платформі Immunefi. На сторінці програми Safe Harbor Immunefi зазначено: “Ви маєте 6 годин, щоб повернути кошти.”

Невиконання цього терміну є суттєвим порушенням. Це у 4 рази швидше за базовий 72-годинний термін SEAL.

Safe Harbor не усуває залежність від інфраструктури MEV. Замість цього він намагається її формалізувати.

Якщо будівельник передрукує експлойт і протокол прийме Safe Harbor, від нього очікується, що він визнає втручання як авторизоване і перенаправить кошти на призначену адресу протоколу у межах SLA.

Але це передбачає, що будівельники слідкують за реєстрами Safe Harbor, дотримуються умов і ставлять відповідність вище за прибуток.

Діапазон сценаріїв

Очікуваний рівень відновлення користувачів у разі експлойту можна змоделювати так: очікуване відновлення дорівнює ймовірності втручання, помноженій на один мінус відсоток винагороди, і помноженій на один мінус відсоток невдач або витоків.

Safe Harbor має на меті підвищити ймовірність втручання, зменшивши юридичну невизначеність і зафіксувавши відсоток винагороди заздалегідь.

У базовому сценарії впровадження Safe Harbor зростає протягом наступних 12 місяців. Більше протоколів додають умови Safe Harbor до своїх управлінських рамок, і більше білі хати реєструються як авторизовані реагувальники.

Ймовірність втручання зростає, оскільки реагувальники мають юридичну ясність і фіксовані умови винагороди. Рівень відновлення покращується, особливо для протоколів, що прийняли більш жорсткі SLA, наприклад, шести-годинне вікно Immunefi.

У бульбашковому сценарії інструмент порятунку стає професійним. Протоколи створюють щільні сейфи, скорочують SLA до однозначних годин і попередньо домовляються про графіки винагород із відомими командами біліх хайт.

Будівельники інтегрують реєстри Safe Harbor у свої алгоритми порядку транзакцій, автоматично перенаправляючи врятовані кошти на призначені адреси без ручного втручання.

У песимістичному сценарії залежність від будівельників ускладнюється. Приватне порядкування та концентрація реле роблять порятунки менш прозорими і більш олігополістичними. Протоколи, що не прийняли Safe Harbor, змушені вести переговори з будівельниками після інциденту без чітких важелів впливу або SLA.

Управління стає залежним від посередників, які тримають кошти і встановлюють умови односторонньо.