Результаты проверкиВсего проблем: 12 (10 решено)Критические: 0 (0 решено) · Высокие: 0 (0 решено) · Средние: 1 (1 решено) · Низкие: 4 (4 решено)

Примечания и дополнительная информацияПолучено 7 примечаний (5 решено)

Проблемы, о которых сообщил клиент0 сообщенных проблем (0 решено)

Область применения

OpenZeppelin провел аудит различий репозитория across-protocol/contracts-v5, охватывающий пять пул-реквестов:

PR #202, от базового снимка eda88c2 до целевого снимка 0416af4
PR #203, от базового снимка eda88c2 до целевого снимка 939c648
PR #207, от базового снимка eda88c2 до целевого снимка c48ac33
PR #210, от базового снимка e34da79 до целевого снимка 68ea4cb
PR #212, от базового снимка 72522fa до целевого снимка 8151d40

В область применения вошли следующие измененные или добавленные файлы:

OpenZeppelin также провел аудит различий репозитория across-protocol/contracts, охватывающий два пул-реквеста:

PR #1529, от базового снимка 8aa3521 до целевого снимка 3d71731
PR #1530, от базового снимка 19e346a до целевого снимка 6e7a949

В область применения вошли следующие измененные или добавленные файлы:

Файлы тестов не входили в область применения данного обзора. В некоторых случаях их изучение было необходимо для понимания или проверки поведения кода, входящего в область применения, и замечания, возникшие в ходе этой работы, были зафиксированы там, где они были признаны полезными. Их не следует воспринимать как всесторонний обзор наборов тестов.

Обзор системы

Этот раздел охватывает семь пул-реквестов, входящих в область применения данной работы и охватывающих два репозитория: пять из них расширяют определенную часть вертикали доставки counterfactual или общий движок диспетчеризации команд, на котором она работает, в across-protocol/contracts-v5, а два других расширяют поверхность бестопливных депозитов SpokePoolPeriphery и библиотеку моста HyperCoreLib в across-protocol/contracts.

PR #202 (Изменение ограничения комиссии CCTP)

CounterfactualCCTPBridgeExecutor, один из исполнителей источников для каждого моста в вертикали counterfactual, заменяет единое пропорциональное ограничение комиссии за быстрый перевод Circle на два независимо настраиваемых аддитивных компонента, отражающих собственную структуру комиссий Circle: фиксированную сумму службы пересылки в единицах сжигаемых токенов и пропорциональный компонент в базисных пунктах от сожженной суммы. Любой из компонентов может быть оставлен неустановленным маршрутом; если оба компонента не установлены, любая ненулевая комиссия отклоняется в цепочке, поскольку нулевая комиссия вообще не считывает ограничение. Два получателя маяка (beacon getters), определяющие эти ограничения, cctpMaxFeeFlatGetter и cctpMaxFeeBpsGetter, являются селекторами, разрешаемыми по отношению к контракту конфигурации для конкретной цепочки во время выполнения, а не значениями, зафиксированными непосредственно в маршруте, что позволяет протоколу перенаправлять их или саму реализацию исполнителя путем обновления маяка без изменения уже зафиксированных пользовательских корневых элементов.

PR #203 (Лист вывода HyperCore)

CounterfactualHyperCoreWithdrawer представляет собой лист маршрута, устраняющий пробел, специфичный для HyperEVM, вне потока префинансирования с маршрутизацией через шлюз, который используется остальной частью системы counterfactual. HyperCore, отдельный реестр расчетов, поддерживаемый Hyperliquid наряду с HyperEVM, отслеживает собственный баланс для того же адреса, и средства, поступающие туда, не видны при обычном обнаружении депозитов HyperEVM. Лист выполняет действие HyperCore, перенося указанную вызывающим абонентом сумму определенного токена из исходного аккаунта, указанного вызывающим абонентом (спотового баланса прокси, его основного счета бессрочных контрактов или биржи бессрочных контрактов, развернутой создателем), на системный адрес HyperCore этого токена. Затем HyperCore асинхронно зачисляет эквивалентный баланс обратно на тот же адрес в HyperEVM, где обычные листья маршрута прокси могут забрать его как регулярный депозит. Лист не выполняет взаимодействия со шлюзом и не считывает баланс в цепочке; он действует исключительно через предукомпиляции HyperCore и системный контракт CoreWriter. Авторизация ограничена фиксированной парой адресов с использованием той же схемы параметров, что и в существующем листе вывода, не зависящем от шлюза, так что одна фиксированная пара охватывает оба пути восстановления в дереве прокси. Вызов не сопровождается подписью, поскольку единственным возможным пунктом назначения листа является собственный баланс вызывающего абонента в HyperEVM.

PR #207 (Одноразовый выпуск counterfactual и Paxos Transit)

Этот пул-реквест расширяет систему доставки counterfactual примитивом одноразовой доставки и интеграцией с исходной цепочкой для моста Paxos Transit, который его использует. Если целевой мост не может прикрепить сообщение в цепочке к переводу, сам адрес доставки должен кодировать, к какому заказу относится перевод; это изменение определяет данный адрес детерминированным образом на основе условий доставки, так что отправленные туда средства могут быть востребованы только на этих условиях.

CounterfactualStepRelease представляет собой лист Merkle, выполняемый через delegatecall внутри прокси counterfactual для каждого заказа. При вызове он пересылает весь баланс зафиксированного актива прокси (как только этот баланс превышает зафиксированный минимум) единственному зафиксированному получателю и только при вызове единственным зафиксированным лицом, осуществляющим выпуск. Токен, минимальная сумма, получатель и лицо, осуществляющее выпуск, являются частью преобразующего образа CREATE2 (preimage), который определяет собственный адрес прокси, поэтому изменение любого из этих условий приводит к другому адресу без финансирования, а не к перенаправлению существующей доставки. CounterfactualReleaseAdapter является триггером в цепочке для этого листа: вызываемый в середине выполнения как вызов адаптера в целевой цепочке, он воссоздает ожидаемый лист из идентификатора шага самого выполнения в реальном времени и условий доставки, зафиксированных для этого выполнения, развертывает прокси, если он еще не существует, и отправляет выпуск. Он называет себя единственным авторизованным лицом, осуществляющим выпуск для этого листа, поэтому выпуск может быть инициирован только через этот конкретный контракт.

CounterfactualPaxosBridgeExecutor является исполнителем counterfactual исходной цепочки для заказов, маршрутизируемых через Paxos Transit, внешний сервис обмена и моста, доступ к которому осуществляется через его контракт TransitStation. Поскольку Transit не передает целевой свидетель в качестве данных сообщения, исполнитель вычисляет адрес целевой доставки в цепочке до отправки заказа, используя то же детерминированное выведение, которое целевая сторона позже будет использовать для инициирования выпуска, и требует, чтобы подписанный извне заказ Transit называл этот адрес своим получателем. Если целевая цепочка не разделяет схему выведения адресов исходной цепочки (например, источник EVM в паре с целью Tron или наоборот), выведение делегируется одному из двух новых контрактов-предсказателей, EvmFactoryProxyPredictor и TronFactoryProxyPredictor, которые локально воспроизводят собственную логику фабрики цепочки-аналога. Исполнитель также обеспечивает соблюдение минимальной чистой доставленной суммы, выраженной в каноническом номинале с 18 знаками после запятой, общем для цепочек, чьи токены различаются по количеству знаков после запятой, до отправки заказа.

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

ПР #210 (Упакованная сумма исполнителя и изменение TRANSFER)

Исполнитель — это диспетчер команд, который выполняет ленту команд конкретного пути после того, как Gateway направляет в него финансирование. Лента представляет собой массив байтов с типами команд в паре с сопутствующим массивом зафиксированных входных данных; несколько вспомогательных команд (APPROVE, TRANSFER, WRAP_ETH, UNWRAP_WETH) и значение нативного вызова в семействе CALL содержат поле суммы, которое упаковано, а не является обычным целым числом, поэтому одно и то же поле может выражать фиксированное значение или значение, производное от баланса Исполнителя на момент выполнения.

Упакованное поле декодируется единым внутренним вспомогательным модулем, общим для всех этих мест вызова. Он считывает младшие 240 бит как сырую сумму, а старшие 16 бит — как селектор режима. Селектор со значением ноль возвращает сырую сумму без изменений. Сырая сумма, равная сигнальному значению из всех единиц, переключает селектор в режим чтения в базисных пунктах, определяя эту долю от текущего баланса Исполнителя в соответствующем токене. Этот пулл-реквест добавляет третий режим, выбираемый специальным ненулевым значением селектора, отличным от диапазона базисных пунктов: сырая сумма считывается как минимальный порог, и поле принимает значение текущего баланса Исполнителя сверх этого порога или нулевое значение, если порог не превышен. Это позволяет пути выражать пересылку всего, что превышает резерв, без предварительного знания точного баланса, точно так же, как режим базисных пунктов уже позволяет пути выражать пропорциональную сумму без знания абсолютного баланса.

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

ПР #212 (атомарное развертывание прокси и миграция корневого узла)

Система контрфактических депозитов позволяет пользователю пополнять детерминированный адрес прокси до того, как этот прокси будет развернут в блокчейне, а затем высвобождать накопленный им баланс с помощью диспетчера на основе дерева Меркла. Каждый прокси представляет собой BeaconProxy с возможностью обновления маяка, на котором запущен CounterfactualDeposit, чей зафиксированный activeRoot авторизует фиксированный набор листьев маршрута. Лист вызывается путем доказательства его включения в этот корневой узел и выполнения delegatecall к названному контракту реализации в контексте собственного хранилища и адреса прокси, поэтому код листа выполняется с балансами и идентификатором прокси. На пути выполнения источника V5 рэлейер вызывает Gateway напрямую с построенным через API путем, указывающим на специализированный закрытый исходный исполнитель; этот исполнитель просит прокси восстановить текущий контекст выполнения и высвободить средства в него через диспетчер прокси, который доказывает лист маршрута по отношению к зафиксированному activeRoot прокси перед выполнением delegatecall к запрошенной реализации.

Этот пулл-реквест расширяет шаг высвобождения (_prefund в CounterfactualSourceExecutorBase), чтобы он также обрабатывал развертывание прокси и, опционально, миграцию его activeRoot атомарно с высвобождением средств в рамках одной транзакции. Ранее прокси, который никогда не развертывался, вообще не мог быть использован в этом процессе: ни одна доступная точка входа одновременно не развертывала прокси и не удовлетворяла требованию диспетчера о том, чтобы вызывающим объектом был работающий в данный момент и вызываемый в текущий момент исполнитель Gateway. Расширение заставляет самого исполнителя вызывать детерминированную фабрику CounterfactualDepositFactory для развертывания прокси, когда у него еще нет кода, а затем напрямую вызывать диспетчер прокси, поэтому вызывающий объект, который видит диспетчер, всегда является исполнителем, а не посредником. Миграция корневого узла, если она запрашивается, объединяется в тот же вызов за счет использования комбинированной точки входа диспетчера вместо его простой точки входа высвобождения.

ПР #1529 (Относительные временные метки SpokePoolPeriphery)

SpokePoolPeriphery расширяет процесс депозита Across подписанными безналоговыми точками входа (без уплаты газа). Депозитор авторизует депозит или обмен с немедленно следующим за ним депозитом вне блокчейна, создавая подпись EIP-712 для параметров депозита вместе с отдельной подписанной авторизацией на извлечение входного токена с использованием ERC-2612 permit, Permit2 или EIP-3009 receiveWithAuthorization. Независимый отправитель впоследствии выполняет транзакцию, используя обе подписи для извлечения средств у подписавшего лица и пересылки депозита в SpokePool.

Поскольку подпись данных депозита может быть создана задолго до того, как отправитель выполнит ее, quoteTimestamp и fillDeadline (поля, которые задают снимок ценообразования депозита и окно его заполнения в SpokePool) могут выражаться относительно времени выполнения, а не в виде фиксированных абсолютных значений. Любое значение на уровне или ниже однолетнего порогового значения трактуется как относительное и соотносится с block.timestamp в момент выполнения транзакции: quoteTimestamp вычисляется путем вычитания значения, поэтому он всегда указывает блок, в который попадает депозит, в качестве снимка ценообразования, а fillDeadline — путем его добавления, благодаря чему депозит сохраняет полное окно заполнения независимо от задержки отправки. Значения выше порогового значения передаются без изменений в качестве абсолютных временных меток. Это разрешение применяется один раз, непосредственно перед вызовом в SpokePool, и единообразно для каждой точки входа депозита, а также обмена с депозитом.

Подписанная полезная нагрузка, использующая относительные временные метки, больше не истекает сама по себе так, как ранее истекал бы абсолютный, уже прошедший fillDeadline, поскольку разрешенные значения всегда пересчитываются относительно момента фактической отправки полезной нагрузки. Точки входа, извлекающие средства через permit ERC-2612, учитывают это напрямую: подпись данных депозита также фиксирует крайний срок, который проверяется на соответствие текущему времени до начала депозита. Это необходимо, поскольку permit вызывается внутри блока try/catch, поэтому существующий лимит токенов подписавшего лица все равно может профинансировать списание даже после того, как истечет срок действия самой его подписи permit.

ПР #1530 (Общие примитивы HyperCore)

HyperCoreLib — это безсостоятельная внутренняя библиотека, с которой связываются контракты интеграции с Hyperliquid для перемещения активов и нативной ценности между HyperEVM (совместимым с EVM слоем выполнения Hyperliquid) и HyperCore (отдельным слоем книги ордеров и расчетов Hyperliquid вне EVM).

Этот пул-реквест расширяет HyperCoreLib, добавляя значения и вспомогательные функции, описывающие нативный HYPE и идентифицирующие две поддерживаемые сети, добавляя примитив для бриджинга нативного HYPE из HyperEVM на собственный спотовый баланс HyperCore вызывающей стороны, а также заменяя резолвер системных адресов библиотеки тем, который дополнительно распознает нативный HYPE и отклоняет индексы, которые нельзя забриджить. Три существующих места вызова, разрешавшие системный адрес, перенаправлены на замену, поэтому новое отклонение также регулирует уже существовавшие в библиотеке пути ERC-20 бриджинга и ликвидности бриджа. Это примитивы, которые CounterfactualHyperCoreWithdrawer (лист вывода, добавленный в упомянутом выше PR #203) определил для себя; их консолидация здесь позволяет этому листу удалить свои локальные копии, а изменение делается в этом репозитории, так как contracts-v5 использует библиотеку как git-подмодуль.

То, как токен попадает в HyperCore, закодировано в новом резолвере. Обычный ERC-20 отправляется на адрес для каждого токена, определяемый детерминистически из индекса HyperCore токена, и простой перевод на этот адрес запускает межслоевое зачисление. Нативный HYPE не имеет собственного связанного контракта EVM, поэтому он использует единый фиксированный системный адрес вместо производного. В случае с производным адресом библиотека теперь также проверяет, что индекс соответствует токену, действительно связанному между двумя слоями, прежде чем выполнять перевод, поскольку отправка средств на адрес, который целевой слой не может интерпретировать, оставит их невосстановимыми.

Определенные идентификаторы Hyperliquid различаются между мейннетом HyperEVM и его тестовой сетью (включая индекс нативного HYPE Core), поэтому добавленные здесь вспомогательные функции разрешают эти значения из block.chainid, а не фиксируют их на едином значении.

Модель безопасности и допущения доверия

PR #202 (изменение лимита комиссии CCTP)

Бэкенд / полномочия на котировки: подписывает зафиксированные данные о лимите комиссии и котировках; экзекутор независимо не проверяет, остается ли лимит комиссии согласованным с минимальным порогом безопасности маршрута, поэтому этому доверяют, а не принудительно контролируют ончейн.
Владелец маяка (Beacon owner): может перенаправлять геттеры лимита комиссии и разрешенный экзекутор путем обновления маяка; должен упорядочивать обновления так, чтобы ни один зафиксированный, но не выполненный маршрут не остался декодирующимся с несовместимым кодированием экзекутора.
Еще не развернуто в продакшене, поэтому в настоящее время ни один маршрут не подвержен указанному выше риску совместимости обновлений.

PR #203 (лист вывода HyperCore)

Администратор / Пользователь: любой из зафиксированных адресов может инициировать восстановление для любого токена, суммы или источника в любое время; может восстанавливать средства только на собственный адрес прокси в HyperEVM, без перенаправления в другое место.
Корректность восстановления зависит от собственного учета HyperCore и конфигурации бриджа токена; лист проверяет только то, что индекс связан, а не то, что связь полностью обеспечена.
Результат является асинхронным и неверифицируемым ончейн: сбой на стороне HyperCore отбрасывается молча, без отката или ончейн-сигнала.
Применимо только к прокси, чей активный корень уже включает этот лист; старым прокси сначала требуется миграция корня, авторизованная администратором.

PR #207 (одноразовый контрфактический выпуск и Paxos Transit)

Конфигурация внецепочечного маршрута: фиксирует идентификаторы целевых сетей, адреса адаптера выпуска / листа и логику деривации адресов; проверяется ончейн лишь частично (только согласование локального и внешнего адресов, а не полная согласованность идентификаторов).
Полномочия по подписанию котировок: подписывают экономические условия каждого ордера (порог безопасности бриджа, комиссию); им доверяют не разрешать условия вне того, что пользователь фактически профинансировал.
Релейер / отправитель: предоставляет неаутентифицированные данные деривации; может вызвать только неудачную доставку, но не перенаправить средства, поскольку целевой адрес зафиксирован условиями доставки, зашитыми в собственный адрес CREATE2 прокси.
Paxos Transit: внешний сервис бриджа; его собственный подписант ограничен независимо полученным целевым адресом экзекутора и проверкой минимальной доставки, поэтому он не может перенаправить средства, даже будучи скомпрометированным.
Два специфичных для сетей предиктора адресов жестко кодируют константы фабрики / маяка / кода создания цепочки-контракта без верификации ончейн; устаревшее значение навсегда блокирует средства на адресе, на который реальная фабрика никогда не сможет развернуться.

PR #210 (пакетное изменение суммы экзекутора и TRANSFER)

Автор пути: полностью контролирует режим и нижний предел упакованной суммы с помощью зафиксированных ленточных данных (tape data); сопряжение контрольного маркера базисных пунктов с новым режимом остатка молча разрешается в ноль вместо отката.
Получатель в режиме остатка: получает весь текущий баланс экзекутора выше нижнего предела, включая оставшиеся средства от несвязанных предыдущих выполнений на этом общем для всей сети контракте.
Новая защита от нулевой суммы в TRANSFER работает молча (без события), что может нарушить работу пути, который полагался на сам перевод нулевой стоимости в качестве сигнала.

PR #212 (атомарное развертывание прокси и миграция корня)

Релейер / отправитель: предоставляет неаутентифицированные параметры развертывания/миграции; не может перенаправить ни то, ни другое, поскольку и целевой адрес прокси, и цель миграции проверяются по независимо зафиксированным значениям.
Развертывающая фабрика: авторизована только по адресу, на котором завершается ее развертывание, а не по идентичности, поэтому вредоносная или сломанная фабрика может вызвать откат, но никогда — неверное направление средств.
Страж миграции корня (Root-migration sentinel): отправка текущего собственного корня прокси в качестве цели миграции (с намерением выполнить no-op) вместо этого повторно применяет его; если к моменту выполнения он устарел, это молча возвращает прокси к более старому корню.
Развертывание не требует разрешений и доступно для вызова извне; межсетевой паритет адресов зависит от одинакового развертывания фабрики/маяка в каждой сети — допущения, сделанного вне этого кода.

PR #1529 (относительные таймстампы SpokePoolPeriphery)

Депозитор: доверяет периферии правильно разрешать относительные quoteTimestamp / fillDeadline во время выполнения и ограничивать для используемой точки входа срок погашения подписанного полезного блока данных.
Отправитель: любой адрес может выполнить подписанный полезный блок данных от имени депозитора; при относительных таймстампах выбранное отправителем время выполнения определяет разрешенную ставку LP-комиссии и окно выполнения в пределах допустимого окна полезного блока данных.
Точки входа permit ERC-2612 напрямую принудительно соблюдают явный дедлайн, привязанный к подписи. Точки входа Permit2 / EIP-3009 вместо этого полагаются на собственные поля deadline / validBefore этих механизмов, которые были рассчитаны на ограничение извлечения токенов, а не на устаревание котировок/заполнений.

PR #1530 (общие примитивы HyperCore)

HyperCore: операции чтения доверяют прекомпилам в отражении истинного состояния; операции записи доверяют действиям в очереди CoreWriter в том, что они будут применены в указанном виде. Записи асинхронны, поэтому проверка баланса может быть устаревшей в рамках одного и того же блока.
Потребляющие контракты: должны предоставлять правильный индекс токена HyperCore и разницу в десятичных знаках; неверный индекс может направить средства на несвязанный связанный токен или на фиксированный системный адрес HYPE.
CoreDepositWallet от Circle: бриджинг USDC доверяет этому захардкоженному адресу оставаться подлинным и корректно работающим развертыванием Circle, без запасного варианта на случай сбоя этого допущения.
Несколько адресов прекомпиляции и системных адресов захардкожены в виде констант для каждой сети; безусловное использование константы, предназначенной только для мейннета или тестнета, не отслеживается ни одной ончейн-проверкой.

Средняя степень серьезности

В реализации маяка (Beacon) пропущен геттер фиксированного ограничения комиссии CCTP

CounterfactualCCTPBridgeExecutor ограничивает подписанное котировкой значение maxFeeCctp с помощью двух независимо настраиваемых геттеров маяка, которые повторяют структуру комиссии Circle: фиксированного компонента в единицах сжигаемых токенов и пропорционального компонента в базисных пунктах от сжигаемой суммы. В _maxFeeCctpCap каждый геттер разрешается независимо, когда его селектор отличен от нуля, bytes4(0) обнуляет этот компонент, а когда оба не заданы, выполнение аварийно завершается с ошибкой RouteNotConfigured.

Продакшн-маяк не реализует геттер фиксированной комиссии. CounterfactualChainConfigV5, неизменяемые геттеры в CounterfactualBeaconV5 и ICounterfactualBeaconV5 предоставляют только usdcCctpMaxFeeBps; поле или геттер фиксированной комиссии (например, usdcCctpMaxFeeFlat) нигде не существуют в развернутой конфигурации. BeaconLib.resolveUint выдает ошибку RouteNotConfigured всякий раз, когда staticcall к селектору маяка завершается неудачно, что происходит для любого селектора, не реализуемого маяком. В результате маршрут, фиксирующий ненулевой cctpMaxFeeMaxFlatGetter, как описано в проекте и документации по интеграции бэкенда, откатывается перед сжиганием CCTP, если maxFeeCctp положительное. В настоящее время с продакшн-маяком работают только маршруты, использующие исключительно базисные пункты (bps). Путь с ограничением фиксированной комиссии задействуется в наборе тестов исключительно через MockCounterfactualBeacon, который реализует геттер фиксированной комиссии, поэтому этот пробел не проявляется при тестировании продакшн-маяка.

Рассмотрите возможность добавления независимо настраиваемого поля usdcCctpMaxFeeFlat в CounterfactualChainConfigV5 вместе с соответствующим неизменяемым значением и геттером в CounterfactualBeaconV5, а также его объявлением в ICounterfactualBeaconV5, повторяя существующую схему usdcCctpMaxFeeBps.

Обновление: Устранено в пулл-реквесте #229. Команда заявила:

«Исправлено в пулл-реквесте ниже»

Геттер фиксированной комиссии теперь присутствует на продакшн-маяке в том же виде, что и геттер bps, поэтому staticcall, который ранее приводил к откату, теперь выполняется успешно, и маршруты CCTP с фиксированным ограничением работают с реальным маяком.

Низкая степень серьезности

Небезопасное кодирование ABI

Использование abi.encodeWithSignature или abi.encodeWithSelector для генерации calldata для низкоуровневого вызова является довольно распространенной практикой. Однако первый вариант не защищен от опечаток, а второй — от ошибок типов. В результате оба этих метода подвержены ошибкам и должны считаться небезопасными.

Использование abi.encodeWithSelector внутри ForeignProxyLib.sol небезопасно.

Рекомендуется заменить все вхождения небезопасных кодировок ABI на abi.encodeCall, который проверяет, соответствуют ли переданные значения типам, ожидаемым вызываемой функцией, а также предотвращает ошибки, вызванные опечатками.

Обновление: Устранено в пулл-реквесте #222. Команда заявила:

«Исправлено в пулл-реквесте ниже»

Теперь используется encodecall.

Захардкоженный адрес USDC CoreDepositWallet нарушает работу моста в тестнете HyperEVM

Рекомендуется разрешать USDC_CORE_DEPOSIT_WALLET_ADDRESS с помощью специфичного для цепочки хелпера, повторяющего существующий паттерн hypeCoreIndex, возвращая 0x6B9E773128f453f5c2C60935Ee2DE2CBc5390A24 для HYPEREVM_CHAIN_ID, 0x0B80659a4076E9E93C7DbE0f10675A16a3e5C206 для HYPEREVM_TESTNET_CHAIN_ID и выдавая ошибку для любой другой цепочки.

Обновление: Устранено в pull request #1539. Команда заявила: