Еженедельный обзор инцидентов безопасности Web3 | 16–22 марта 2026 г.

За прошедшую неделю (16.03.2026 – 22.03.2026) компания BlockSec зафиксировала и проанализировала семь инцидентов со взломами, суммарный предполагаемый ущерб от которых составил ~82,7 млн долларов США. В таблице ниже представлены краткие сведения об этих инцидентах, а в следующих подразделах приведен подробный анализ каждого случая.

*Инцидент с Venus не был включен в отчет на прошлой неделе и добавлен здесь для полноты картины.

1. Инцидент Venus

Краткое резюме

15 марта 2026 года рынок THE (Thena) протокола Venus в сети BNB Chain подвергся атаке через донат в сочетании с манипуляцией рынком, что привело к возникновению «плохого долга» на сумму около 2,15 млн долларов. Лимит предложения рынка THE применялся только к пути минтинга, в то время как прямые донаты токенов в пул по-прежнему увеличивали показатель cash и завышали exchangeRate (обменный курс). Затем злоумышленник использовал эту завышенную стоимость обеспечения для заимствования ликвидных активов и приобретения дополнительных THE, одновременно искусственно завышая рыночную цену токена THE. В конечном итоге после принудительной ликвидации позиции протокол остался с «плохим долгом».

Предыстория

Venus — это протокол кредитования, основанный на форке Compound V2. На рынке THE пользователи вносят THE и получают токены vTHE. exchangeRate определяет, какому количеству базовых активов рынка соответствует каждый vTHE; основная формула выглядит так:

exchangeRate = (cash + borrows - reserves) / totalSupply

Здесь cash — это баланс базового актива на рынке, borrows — общая сумма непогашенного долга, reserves — резервы, принадлежащие протоколу, а totalSupply — общее предложение vTHE. На рынке THE также установлен лимит предложения, предназначенный для ограничения общего объема обеспечения.

Анализ уязвимости

Этот инцидент связан с двумя взаимодополняющими векторами атаки на контракт рынка vTHE (0x86e0...739f).

Атака через донат

Протокол определяет cash напрямую из баланса токенов контракта, что делает его уязвимым для атак через донат. Любая прямая передача THE в контракт vTHE увеличивает cash, а следовательно, и exchangeRate. Злоумышленник использовал это, чтобы завысить exchangeRate примерно в 3,81 раза, увеличив стоимость обеспечения своей существующей позиции vTHE.

Манипуляция рынком

Токен THE обладал низкой ончейн-ликвидностью, что делало его спотовую цену уязвимой для манипуляций через относительно небольшое давление покупателей. Оракул протокола спроектирован так, чтобы отклонять цены, которые слишком сильно отклоняются от эталонных значений; он корректно отклонял экстремальные цены в течение примерно 37 минут во время атаки. Однако устойчивое давление покупателей в конечном итоге подтолкнуло цену THE примерно до 0,51 доллара, что почти вдвое превышало пред-атаковую цену, и оракул в конечном итоге принял это значение.

Эти два вектора усиливали друг друга. Завышенный exchangeRate после атаки через донат увеличил стоимость обеспечения каждой единицы vTHE, а манипулируемая цена токена THE еще больше повысила лимит заимствования. Вместе они позволили злоумышленнику накопить заимствования на сумму около 14,9 млн долларов под позицию, которая в 3,67 раза превышала лимит предложения.

Анализ атаки

Следующий анализ основан на примере транзакции атаки 0xce6e3e...1f5fb0e.

• Шаг 1: Кошелек, связанный со злоумышленником, получил 7 447 ETH через 77 транзакций, связанных с TornadoCash, в течение примерно девяти месяцев. Эти ETH были внесены в Aave, и было взято около 9,92 млн долларов в стейблкоинах для создания позиции vTHE объемом около 12,2 млн THE (примерно 84% от лимита предложения 14,5 млн THE).

• Шаг 2: В первой транзакции атаки шесть адресов перевели около 36 млн THE напрямую в контракт рынка vTHE. Контракт атаки также занял 1,58 млн USDC, внес их обратно, затем занял около 4,6 млн THE и перевел их напрямую в vTHE. Это увеличило exchangeRate примерно в 3,81 раза.

• Шаг 3: В последующих транзакциях злоумышленник заимствовал ликвидные активы, включая CAKE, BNB, BTCB и USDC. Злоумышленник продолжал покупать THE на заемные активы и донатить больше THE в vTHE, создавая цикл, который увеличивал как заемную мощность позиции, так и рыночную цену токена THE.

• Шаг 4: Цена токена THE выросла примерно с 0,2 доллара, причем источник цены Binance кратковременно приближался к 4 долларам. Оракул протокола отклонял экстремальные цены в течение примерно 37 минут, прежде чем в конечном итоге принял цену около 0,51 доллара.

• Шаг 5: К 20:42 UTC+8 позиция злоумышленника достигла около 53,2 млн THE, что примерно в 3,67 раза превышает лимит предложения, с общим объемом заимствований около 14,9 млн долларов.

• Шаг 6: Затем позиция попала под крупные ликвидации. Около 42 млн THE обеспечения были ликвидированы в ходе 8 048 транзакций ликвидации с 254 адресов ликвидаторов. Поскольку продажи продолжались, цена THE упала примерно до 0,22 доллара. Поступления от ликвидации не смогли покрыть весь долг, оставив Venus с чистым «плохим долгом» около 2,15 млн долларов.

Заключение

Инцидент не выявил новых уязвимостей. Он наглядно продемонстрировал, как хорошо известный вектор атаки, выполненный методично, может перегрузить стек рисков протокола, если каждый уровень предполагает, что остальные сработают корректно. Сигналы опасности были видны в ончейне в течение нескольких месяцев, однако разрыв между обнаружением и вмешательством так и не был устранен. Основной урок для других протоколов кредитования — необходимость устранения этого разрыва за счет внедрения риск-параметров, чувствительных к ликвидности, автоматических предохранителей (circuit breakers) и мониторинга на уровне позиций.

Подробный анализ доступен в нашей статье [1].

Ссылки

• [1] https://blocksec.com/blog/venus-thena-donation-attack

2. Инцидент dTRINITY

Краткое резюме

17 марта 2026 года протокол dTRINITY, являющийся форком Aave V3 на Ethereum, подвергся эксплойту через рынок dLEND, что привело к убыткам на сумму около 257,3 тысяч долларов. Первопричиной стала уязвимость «пустого рынка», присущая форкам Aave V3. Когда резерв хранит околонулевую ликвидность, многократное начисление премий за флэш-займы доводит liquidityIndex до экстремальных значений. После искажения учета резервов злоумышленник использовал потерю точности при внесении и выводе средств, чтобы завысить стоимость обеспечения, занять dUSD и вернуть внесенный cbBTC с чистой прибылью.

Предыстория

dTRINITY включает в себя стейблкоин dUSD и dLEND — рынок кредитования, созданный на базе Aave V3. В основном контракте L2Pool (0xfda3...e19e84) каждый актив имеет свой собственный резерв, а учет резервов основан на масштабированных балансах и liquidityIndex (индексе ликвидности). Текущий баланс пользователя вычисляется как масштабированный баланс, умноженный на нормализованный доход резерва.

Премии за флэш-займы добавляются к учету резервов через cumulateToLiquidityIndex(), где:

nextLiquidityIndex = ((amount / totalLiquidity) + 1) * reserve.liquidityIndex

Когда totalLiquidity становится экстремально малым, каждое начисление премии может подталкивать liquidityIndex вверх с аномально высокой скоростью.

Анализ уязвимости

Ключевым условием для атаки был почти пустой резерв на рынке dLEND-cbBTC (0x504d...3acc). Как только резерв был сжат до одной масштабированной доли, премии за флэш-займы перестали распределяться по значимой базе предложения. Поэтому повторяющиеся флэш-займы вызвали чрезвычайно быстрый рост liquidityIndex.

После того как liquidityIndex был завышен, конвертация из базового актива в масштабированный вошла в режим экстремального округления. В этом состоянии небольшой депозит мог создать одну дополнительную долю, в то время как гораздо более крупный вывод средств мог сжечь только одну долю. Эта асимметрия позволила злоумышленнику завысить обеспечение aCbBTC и занять реальные dUSD из другого резерва, поскольку проверки состояния (health checks) выполнялись на уровне Pool, и искаженный резерв cbBTC напрямую влиял на возможность межрыночного заимствования.

Анализ атаки

Эксплойт состоял из двух транзакций: 0x8d33d6...40ae7139 и 0xbec4c8...4fc33260.

Транзакция 1: Манипуляция liquidityIndex

• Шаг 1: Заимствование cbBTC у Morpho Blue.

• Шаг 2: Внесение cbBTC в dLEND-cbBTC для минтинга 100 масштабируемых долей.

• Шаг 3: Вывод 99 долей, чтобы осталась только 1 доля, сжимая резерв dLEND-cbBTC до состояния почти пустого масштабируемого предложения.

• Шаг 4: Прямой перевод 80 000 000 единиц cbBTC (т.е. 0,8 cbBTC) на aToken dLEND-cbBTC.

• Шаг 5: Выполнение 150 вызовов Pool.flashLoan() для накопления премии в учете резервов, что подняло liquidityIndex до 6 226 621 999 999 999 999 999 999 999 979 728 276.

• Шаг 6: Запуск повторяющихся циклов внесения и вывода средств для извлечения остаточных денежных средств резерва.

• Шаг 7: Возврат флэш-займа.

Транзакция 2: реализация прибыли

• Шаг 1: Снова заимствование cbBTC у Morpho Blue.

• Шаг 2: Внесение ~7,72 cbBTC в уже скомпрометированный резерв для создания завышенной позиции обеспечения aCbBTC.

• Шаг 3: Использование завышенного обеспечения для заимствования 257 328 dUSD с рынка dLEND-dUSD.

• Шаг 4: Продолжение извлечения cbBTC через повторяющиеся циклы внесения/вывода.

• Шаг 5: Возврат флэш-займа Morpho и перевод заемных dUSD на EOA-адрес злоумышленника.

Заключение

Этот инцидент является примером атаки через пустой рынок, которая хорошо задокументирована для форков Aave V3. Данный паттерн появлялся в нескольких протоколах, и методы защиты давно известны. Установление минимального порога предложения при инициализации резерва предотвращает вход резерва в состояние, где рост индекса становится неконтролируемым. Разработчикам форков Aave V3 следует рассматривать начальную загрузку резервов как критическую операцию и обеспечивать блокировку значимой ликвидности при развертывании, а не полагаться на органический приток депозитов для стабилизации индекса.

3. Инцидент Fun.xyz

Краткое резюме

17 марта 2026 года протокол инфраструктуры расчетов Fun.xyz в сети Polygon был взломан на сумму ~85,7 тыс. долларов. Первопричиной стало то, что устаревший контракт CheckoutPool открывал доступ к критической функции bridge() без контроля доступа и без привязки данных вызова (calldata) моста к получателю. Эта уязвимость позволила злоумышленнику перенаправить исполнение на доверенный путь расчетов и перевести средства на подконтрольный ему смарт-аккаунт.

Предыстория

CheckoutPool — ключевой контракт расчетов в инфраструктуре Fun.xyz. В нормальном режиме пользователь создает расчет через deposit(), а доверенный оператор продвигает его через пути расчетов, такие как bridge() и execute(). Для операций моста bridge() выполняет внешний вызов, основываясь на переданных вызывающим лицом параметрах bridgeParams.target и bridgeParams.callData.

Анализ уязвимости

Первопричиной является то, что устаревший контракт CheckoutPool (0x1304...2ec01a) открывал доступ к чувствительному пути маршрутизации через функцию bridge() без надлежащего контроля доступа, одновременно не проверяя предоставленные извне calldata моста на соответствие предполагаемому получателю. В частности:

• Устаревшая реализация не требовала onlyOperator для bridge(), позволяя любому внешнему вызывающему лицу вызывать функцию после создания расчета через deposit().

• bridge() передавал предоставленные вызывающим лицом bridgeParams в _bridgeToRecipient(), который выполнял внешний вызов, не проверяя получателя на соответствие расчетной записи.

Дополнительное операционное условие сделало эксплойт возможным: устаревший CheckoutPool по-прежнему сохранял привилегии оператора в CheckoutPaymaster на момент атаки. Это позволило сконструированному вызову bridge() достичь CheckoutPaymaster.activateAndCall(), который затем запустил более новый путь CheckoutPool.execute(), переводя средства на адрес под контролем злоумышленника.

Анализ атаки

Анализ основан на транзакции атаки 0x957bcf...1f4f5a.

• Шаг 1: Создание смарт-аккаунта ERC-4337 0xb648 и назначение его отправителем и пеймастером в UserOperation.

• Шаг 2: Вызов deposit() как в устаревшем, так и в новом CheckoutPool, создание записи о расчете в новом CheckoutPool на сумму 85 730 USDC.

• Шаг 3: Вызов bridge() в устаревшем CheckoutPool с вредоносными bridgeParams: установка bridgeParams.target на CheckoutPaymaster и кодирование bridgeParams.callData как вызова activateAndCall(), содержащего внешнюю UserOperation в качестве внутренней нагрузки.

• Шаг 4: Выход на execute() в новом CheckoutPool (0x1929...0215), который переводит 85 730 USDC на 0xb648 — адрес, указанный как ops[0].sender во внешней UserOperation.

• Шаг 5: Вход в EntryPoint.handleOps(): поскольку 0xb648 служит и отправителем, и пеймастером, и валидация аккаунта, и валидация пеймастера остаются под контролем злоумышленника, что позволяет ему получить прибыль в 85 730 USDC.

Заключение

Инцидент был вызван отсутствием контроля доступа в устаревшем контракте CheckoutPool и привязки данных вызова к получателю, что привело к убыткам около 85,7 тыс. долларов. Для предотвращения подобных ситуаций протоколам следует обеспечить строгий контроль доступа к чувствительным потокам расчетов, гарантировать соответствие переданных извне данных получателям, определенным протоколом, и удалять устаревшие контракты из доверенных отношений после развертывания исправленных версий.

4. Инцидент Keom

Краткое резюме

18 марта 2026 года протокол кредитования Keom (форк Compound V2) в сети Polygon zkEVM был взломан на сумму около 35 тыс. долларов. Первопричиной стала ошибочная логика учета в redeemFresh(), вызываемой внутри redeemUnderlying(). Функция ограничивала сокращение долей до фактического баланса пользователя, но не пересчитывала соответствующим образом сумму выводимых активов. Это несоответствие позволило злоумышленнику вывести гораздо больше активов, чем позволяла его доля.

Предыстория

Keom — это форк Compound V2. Пользователи вносят ETH в рынок и получают kETH. При выводе средств протокол конвертирует kETH обратно в ETH по текущему курсу. Существуют две точки входа для вывода: redeem() для вывода по количеству долей и redeemUnderlying() для вывода желаемой суммы базового актива.

Анализ уязвимости

Ошибка находится в redeemFresh() рынка kETH (0x4c6e...0403), вызываемой redeemUnderlying(). Контролируемый пользователем redeemAmountIn сначала присваивается redeemAmount, а затем используется для вычисления redeemTokens по текущему обменному курсу. Если redeemTokens превышает баланс пользователя, функция ограничивает его до accountTokens[redeemer]. Однако redeemAmount не пересчитывается после этого ограничения и остается равным исходному redeemAmountIn. Это позволяет пользователю вывести полную сумму redeemAmount базовых активов, сжигая при этом лишь часть соответствующих долей.

Как показано ниже, redeemFresh() также проводит проверку состояния через redeemAllowed(). В архитектуре Compound V2, redeemAllowed() проверяет markets[cToken].accountMembership[redeemer] и вызывает проверку ликвидности только тогда, когда аккаунт вошел в этот рынок; в противном случае проверка пропускается полностью. Поскольку redeemAmountIn контролируется злоумышленником и может быть установлен произвольно большим, проверка ликвидности не сработала бы, если бы kETH по-прежнему учитывался как обеспечение. Это означает, что сама по себе ошибка учета не поддается эксплойту без предварительного обхода проверки здоровья.

Анализ атаки

Анализ основан на транзакции 0x4ccde7...03d9dfd8.

• Шаг 1: Вызов mint() с всего 0,001 ETH, получение минимального баланса kETH.

• Шаг 2: Вызов exitMarket() для сброса участия аккаунта в рынке kETH, чтобы redeemAllowed() полностью пропустил проверку ликвидности (как описано выше).

• Шаг 3: Вызов redeemUnderlying() для вывода всего баланса ETH рынка (~38,6 ETH), используя ошибку учета для истощения запасов ETH рынка.

Заключение

Инцидент был вызван ошибкой учета, при которой не происходил перерасчет redeemAmount после ограничения redeemTokens до фактического баланса, что привело к убыткам в размере около 35 тыс. долларов. Логика вывода средств должна пересчитывать все зависимые значения после любого ограничения, чтобы сохранить инвариант долей к базовому активу. Разработчикам форков Compound V2 следует внимательно изучить этот путь, так как аналогичные уязвимости могут существовать и в других производных продуктах.

5. Инцидент ShiMama

Краткое резюме

18 марта 2026 года протокол дефляционных токенов ShiMama в сети BNB Chain был взломан на сумму около 35 тыс. долларов. Первопричиной стало отсутствие контроля доступа к функции executePairBurn(), что позволило любому пользователю запускать принудительный вывод и сжигание резервов торговой пары, что привело к манипулированию ценой.

Предыстория

Протокол ShiMama включает в себя ончейн-механизм дефляции, предназначенный для изъятия токенов из пары AMM и их сжигания. Этот механизм реализован в контрактах ShiMama Protocol и ShiMama Token. Функция executePairBurn() в ShiMama Protocol вычисляет сумму изъятия на основе параметра referenceIn:

pullAmt = referenceIn * pairBurnBpOnSell / 10_000

Затем она вызывает forcePullFromPair() контракта ShiMama Token с последующим pair.sync() и сжиганием изъятых токенов.

Анализ уязвимости

Первопричина — отсутствие контроля доступа к executePairBurn() в контракте ShiMamaProtocol (0x5049...0b49a). Функция доступна извне без ограничений, поэтому любой пользователь может инициировать привилегированное движение резервов и синхронизацию пары. referenceIn также контролируется вызывающим лицом и никак не привязан к реальной сумме продажи. В ShiMamaToken.forcePullFromPair() протокол может напрямую перемещать балансы из пары Pancake без каких-либо ограничений, что делает возможным произвольное удаление резервов плюс немедленную синхронизацию и манипуляцию спотовой ценой.

Анализ атаки

Анализ основан на транзакции 0x13959b...3c20e001.

• Шаг 1: Заимствование WBNB через флэш-займ Moolah.

• Шаг 2: Перевод 30,78e18 ShiMama, полученных в более ранней транзакции, в контракт атаки. Поскольку прямые покупки ShiMama на Pancake были отключены, злоумышленник получил ShiMama, внося и выводя ликвидность в ShiMama Protocol до начала атаки.

• Шаг 3: Вызов executePairBurn() для изъятия 1 311 349 143,96 токенов ShiMama из пары Pancake и их сжигания, что эффективно завысило цену ShiMama.

• Шаг 4: Злоумышленник обменял 30,78e18 ShiMama на 52,98e18 WBNB на PancakeSwap по завышенной цене.

• Шаг 5: Возврат флэш-займа, оставив 52,98 WBNB в качестве чистой прибыли.

Заключение

Этот инцидент был вызван отсутствием контроля доступа к executePairBurn(), что открыло несанкционированный путь изменения резервов пула. Любая функция, изменяющая резервы, экономически чувствительна и должна быть строго защищена разрешениями. Входящие параметры, контролируемые пользователем, должны быть жестко привязаны к значениям, производным от протокола, для предотвращения возможности усиления изъятия резервов.

6. Инцидент BlindBox

Краткое резюме

19 марта 2026 года протокол ставок GameFi BlindBox в сети BNB Chain был взломан на сумму около 99 тыс. долларов. Первопричиной стала слабая случайность, позволившая злоумышленнику предсказать результат и достичь 100% коэффициента выигрыша. Кроме того, getTwapPrice() полагалась на спотовую цену, которой можно манипулировать, а не на реальную средневзвешенную по времени цену, что позволило злоумышленнику заранее надуть цену пула и делать ставки, превышающие установленные протоколом лимиты.

Предыстория

BlindBox позволяет пользователям делать ставки, переводя токены ATM на «мертвый» адрес. Протокол определяет результат на основе четности более позднего хэша блока. В случае выигрыша BlindBox выплачивает 1,95x от исходной суммы ATM из депозита «мертвого» адреса. Протокол использует getTwapPrice() для ограничения размера каждой ставки.

Анализ уязвимости

Контракт BlindBox (0x1F83...734c59) содержит две уязвимости:

1. Слабая случайность: Когда время расчета превышает 256 блоков, blockhash(bet.blockNum + 2) возвращает ноль. Затем протокол переходит к резервному варианту — случайности, производной от block.prevrandao, betId и block.timestamp. Поскольку эти входные данные можно имитировать офчейн перед отправкой транзакции, злоумышленник мог вызывать settle() только в том случае, если вычисленный результат был выгодным, достигая детерминированного выигрыша.

2. Манипулируемый лимит цены: Протокол использует getTwapPrice() для ограничения размера ставки. Однако эта функция не реализует истинную средневзвешенную по времени цену (TWAP); вместо этого она читает спотовую цену в пуле ATM/USDT. Это позволяет злоумышленникам обходить лимит путем манипулирования ценой пула перед совершением ставки.

Анализ атаки

Следующие шаги иллюстрируют паттерн атаки. Шаги 2 и 3 сформировали парную последовательность (например, betId=5 284), и злоумышленник повторил эту пару многократно для накопления прибыли.

• Шаг 1: Манипуляция пулом ATM/USDT, завышение спотовой цены ATM, чтобы getTwapPrice() разрешил больший размер ставки на следующем шаге.

• Шаг 2: Размещение крупной ставки путем перевода суммы ATM с надутым допуском на «мертвый» адрес (например, 0x4be049...3af12c).

• Шаг 3: Ожидание прохождения более 256 блоков, чтобы blockhash вернул ноль и активировался резервный путь. Затем злоумышленник имитировал результаты офчейн и вызывал settle() только в тот блоке, где вычисленный результат был выгодным (например, 0x68eedc...718ce8).

Заключение

Инцидент был вызван предсказуемой случайностью в сочетании с манипулируемой ценой в качестве входных данных TWAP, что привело к убыткам в размере около 99 тыс. долларов. Для снижения рисков протоколу следует удалить любой путь расчета, который становится предсказуемым после истечения окна blockhash, и заменить getTwapPrice() на источник цен, устойчивый к краткосрочным рыночным манипуляциям.

7. Инцидент Resolv

Краткое резюме

22 марта 2026 года протокол стейблкоинов Resolv в сети Ethereum столкнулся с компрометацией инфраструктурного ключа, что позволило несанкционированно выполнить логику завершения свопов. В ходе инцидента злоумышленник использовал привилегированную функцию для минтинга более 80 млн ничем не обеспеченных USR. Последствия вышли за рамки прямого минтинга, так как возникшая депег-ситуация (отвязка от курса доллара) с USR вызвала более широкое заражение в протоколах кредитования, где активы Resolv использовались в качестве обеспечения.

Предыстория

Resolv — это протокол стейблкоинов, в котором выпуск USR зависит от завершенных свопов, обеспеченных залогом. Его конвейер завершения свопа completeSwap() -> mint() -> transfer() напрямую влияет на циркулирующее предложение USR, поэтому зависит как от целостности авторизации, так и от целостности обеспечения. В обычном режиме completeSwap() в контракте Resolv (0xa27a...5861) может быть вызван только привилегированным инфраструктурным ключом (называемым SERVICE_ROLE в коде) после проверки соответствующего депозита обеспечения.

Анализ уязвимости

Инцидент произошел из-за компрометации привилегированного ключа, который вызвал доверенную логику расчетов и привел к пути минтинга USR без эквивалентного притока обеспечения. Как только злоумышленник получил контроль над привилегированными полномочиями подписи, путь completeSwap() не обеспечил никаких ончейн-предусловий для минтинга; проверка обеспечения полностью зависела от внесетевой (офчейн) авторизации. Это превратило компрометацию плоскости управления непосредственно в сбой целостности предложения.

Анализ атаки

• Шаг 1: До совершения эксплойта злоумышленник отправил запрос на своп в транзакции 0x590b5c...de732c89, подготавливая необходимое состояние для последующего завершения вредоносного свопа.

• Шаг 2: Используя скомпрометированный привилегированный ключ, злоумышленник вызвал completeSwap() для минтинга более 80 000 000 USR в трех транзакциях: 0xfe37f2...dc33743, 0x41b6b9...db1f18f и 0x7f9143...53a931d.

Заключение

Этот инцидент подчеркивает, что безопасность стейблкоинов зависит от жестких ончейн-предусловий минтинга, а не только от роли доверенного оператора. Важно отметить, что последствия инцидента вышли далеко за рамки 80 млн долларов несанкционированного минтинга USR. Поскольку активы Resolv широко использовались в качестве обеспечения в нескольких протоколах кредитования, потеря привязки к курсу вызвала более широкое заражение. Как сообщил Chaos Labs, ончейн-кураторы, использующие автоматизированные стратегии распределения капитала в погоне за доходностью, не имели средств риск-контроля в реальном времени и продолжали направлять свежий капитал на уже скомпрометированные рынки. То, что началось как локальный эксплойт, быстро переросло в событие заражения между протоколами, оставив кредиторов с миллионными «плохими долгами».

О BlockSec

BlockSec — поставщик комплексных решений для безопасности блокчейнов и крипто-комплаенса. Мы создаем продукты и услуги, которые помогают клиентам проводить аудит кода (включая смарт-контракты, блокчейны и кошельки), перехватывать атаки в режиме реального времени, анализировать инциденты, отслеживать незаконные средства и выполнять обязательства AML/CFT на протяжении всего жизненного цикла протоколов и платформ.

BlockSec опубликовала множество статей по безопасности блокчейнов на престижных конференциях, сообщила о нескольких атаках «нулевого дня» на приложения DeFi, заблокировала многочисленные попытки взлома, спасая более 20 миллионов долларов, и обеспечила сохранность миллиардов криптовалютных активов.

• Официальный сайт: https://blocksec.com/

• Официальный Twitter: https://twitter.com/BlockSecTeam

• 🔗 Аудиторские услуги BlockSec : Отправить запрос

• 🔗 Приложение Phalcon Security: Записаться на демонстрацию

• 🔗 Phalcon Compliance