Глубокий анализ уязвимости: неудачный процесс выкупа, который может оставить залог заблокированным и временно вне его предполагаемого пути развертывания. В ходе нескольких раундов аудита с участием @aegis_im была выявлена проблема средней серьезности с мая 2025 года, которая подчеркнула именно это. Команда Aegis предприняла правильные шаги для ее решения, повторного рассмотрения и полного устранения. Настройка Процесс одобрения выкупа Aegis работал в два этапа. Залог был переведен в AegisMinting в качестве предварительного депозита. Менеджер средств затем вызывал approveRedeemRequest(), чтобы завершить выкуп. Звучит разумно. Но это создало опасный крайний случай. Если approveRedeemRequest() откатился из-за проверок проскальзывания, истечения срока или другого ограничения на одобрение, выкуп не удался, но залог, который уже был перемещен, не был возвращен. Он остался заблокированным внутри AegisMinting. Почему это имело значение Этот залог должен был продолжать движение через развертывание и управление рисками Aegis. При нормальной работе это могло включать конвертацию залога и его развертывание в дельта-нейтральную стратегию для снижения ценового риска. Когда средства застревали до одобрения, ничего из этого не происходило. Капитал, обеспечивающий, перестал зарабатывать доход, как предполагалось. Обеспечение оставалось незащищенным и подверженным колебаниям цен на залог, включая риск отклонения стейблкоина. Если это обеспечение теряло в стоимости, в то время как предложение YUSD оставалось неизменным, давление на отклонение увеличивалось. Неудачное одобрение выкупа могло оставить систему с риском, который она не должна была нести. Коренная причина Неатомарный дизайн. Система сначала переместила хранение, а затем проверила, может ли одобрение действительно завершиться. Как только залог оказался внутри AegisMinting, последующий откат в approveRedeemRequest() оставил протокол в промежуточном состоянии: выкуп не был одобрен, залог уже был перемещен, и не было принудительного механизма отката для отмены депозита. Депозит и одобрение были разделены, и сбой на втором этапе заблокировал стоимость с первого. Пример пути сбоя Запрос на выкуп инициируется. Залог переводится в AegisMinting. Перед одобрением заказ истекает или проскальзывание выходит за пределы. Менеджер средств вызывает approveRedeemRequest(). Он откатывается. Залог остается заблокированным, неразвернутым и незащищенным. Не требовалось экзотического поведения атакующего. Это могло произойти через обычный процесс одобрения. Исправление Самым чистым смягчением было бы сделать поток атомарным. Проверить выкуп, перевести залог и завершить одобрение в одном пути, чтобы средства перемещались только в случае успешного одобрения. Если структура из двух шагов должна оставаться, протоколу нужен четкий путь восстановления, такой как cancelRedeemRequest(), refundRedeemDeposit() или учет в стиле эскроу, чтобы незавершенные депозиты всегда могли быть восстановлены законной стороной. Почему это стоит изучить Это тот вид проблемы, который имеет значение в аудитах. Многоступенчатые финансовые системы не ломаются сразу. Они ломаются в частичных состояниях. Средства перемещаются, одна зависимость выходит из строя, и протокол остается с риском, который он никогда не должен был нести. Много сильных находок происходит именно из такого рода полузавершенного потока. Залог оказывается заблокированным. Учетные предположения перестают действовать. Обеспечение оказывается бездействующим, подверженным риску или вне пути, который оно должно было следовать. Чистый счастливый путь не защищает систему от ущерба, вызванного неполным.

Дружеское напоминание: если ваш протокол не использует аудит с помощью AI, вы ставите свою команду в серьезное невыгодное положение по сравнению с командами, которые уже это делают. Это не будущее изменение. Это уже происходит сейчас.

Мы рады приветствовать @Liquidity_land в качестве партнера по безопасности Sherlock. В рамках этого партнерства команды web3 в сети получают преимущества и скидки на услуги Sherlock AI, аудит, вознаграждения за обнаружение ошибок и полный пакет услуг по безопасности от Sherlock. Liquidity Land помогает протоколам привлекать TVL через структурированные программы ликвидности, разработанные для долгосрочного роста, связывая их с институциональным капиталом, китами и скоординированными LP. С нетерпением ждем возможности помочь большему количеству команд строить более крепкие проекты с первого дня.