Конкурсный аудит Garden Finance: Code4rena
Технические
TL;DR, в декабре 2025 года Code4rena провела конкурсный аудит кросс-чейн HTLC-контрактов Garden на EVM, Solana, Starknet и Move. 813 независимых исследователей безопасности прислали свои находки. Была выявлена одна уязвимость уровня Medium — непроверенное возвращаемое значение approve() в UDA.sol; она устранена с помощью SafeERC20. Проблем уровня High или Critical обнаружено не было.
Garden провела конкурсный аудит безопасности через Code4rena, охвативший самую широкую область среди всех проверок безопасности Garden на сегодняшний день; 15 смарт-контрактов, написанных на четырёх языках и в четырёх сетях. В отличие от традиционного контракта с аудиторской фирмой, формат Code4rena открывает кодовую базу большому пулу независимых исследователей безопасности, которые присылают находки на конкурсной основе, а вознаграждения выплачиваются в зависимости от уровня серьёзности и обоснованности. За две недели поступило 813 заявок при общей сумме вознаграждений $37,500.
Аудит был специально нацелен на архитектуру атомарных свопов Garden на основе HTLC в EVM, Solana, Sui и Starknet — полном наборе сетей, поддерживаемых Garden на тот момент. Проверяемая кодовая база насчитывала 2 163 строки на Cairo, Move, Rust и Solidity.
Область аудита
Аудит проходил с 24 ноября по 8 декабря 2025 года и проводился по репозиторию C4 Garden Finance на коммите cf7c5b09b7156d6806cc1e68dd924c1b01a5236d, а отчёт был опубликован 12 февраля 2026 года. В область аудита вошли пятнадцать смарт-контрактов на четырёх языках и платформах:
- Solidity / EVM: включая UDA.sol, NativeHTLC.sol, ArbNativeHTLC.sol и связанные с ними своп-контракты EVM
- Rust / Solana: программы solana-native-swaps и solana-spl-swaps, реализующие HTLC-свопы нативного SOL и токенов SPL
- Cairo / Starknet: htlc.cairo, реализующий логику HTLC в Starknet
- Move / Sui: HTLC-модули на основе Move
Цели оценки, сформулированные Garden, охватывали корректность переходов состояний, целостность переводов, уникальность ордеров и подлинность возвратов средств — в соответствии с вопросами безопасности, применёнными в аудите Move от Zellic, теперь распространёнными одновременно на все поддерживаемые сети.
Находки
Аудит выявил одну уникальную уязвимость. Проблем уровня High выявлено не было.
M-01; Непроверенное возвращаемое значение approve() приводит к безвозвратной потере средств в UDA.sol | Medium
Функция UniqueDepositAddress.initialize() вызывает ERC20.approve(), не проверяя возвращаемое значение:
HTLC(_addressHTLC).token().approve(_addressHTLC, amount);Нестандартные ERC20-токены, включая USDT и BNB, при неудачном одобрении возвращают false, а не откатывают транзакцию. Поскольку возвращаемое значение игнорируется, выполнение продолжается даже при неудачном одобрении. В результате контракт помечает себя как initialized, allowance токена остаётся нулевым, а initiateOnBehalf() выполняется, но HTLC не может перевести токены. Внесённые средства оказываются заблокированными навсегда, без возможности восстановления, поскольку initialized не даёт провести повторную инициализацию.
Контракт уже импортирует SafeERC20 и использует его в функциях recover() — исправление состояло в том, чтобы так же последовательно применить его и к вызову approve().
Эту находку независимо друг от друга обнаружили и прислали десять разных исследователей.
Отсутствие проверки redeemer != refundee допускает ордера с одной стороной и мгновенные самовозвраты | Low
Инструкция initiate в обеих реализациях HTLC на Solana — solana-native-swaps и solana-spl-swaps — не требует, чтобы redeemer и refundee были разными адресами. Когда оба указаны как один и тот же адрес, instant_refund можно вызвать сразу же, не раскрывая секрет и не дожидаясь истечения таймлока, поскольку согласие redeemer — единственное условие для мгновенного возврата, а один и тот же адрес контролирует обе роли. Это нарушает фундаментальный инвариант HTLC: контрагент получает средства по секрету, и только инициатор может вернуть их после истечения срока.
Орфографические ошибки и опечатки в идентификаторах по всему проекту | Informational
Орфографические ошибки были выявлены в кодовых базах EVM, Cairo и Starknet. Самое значимое с точки зрения интеграции: идентификаторы пользовательских ошибок NativeHTLC__IncorrectFundsRecieved и ArbNativeHTLC__IncorrectFundsRecieved в контрактах Solidity содержат опечатку в слове "Received." Поскольку селекторы пользовательских ошибок выводятся из keccak256(ErrorSignature), переименование меняет ончейн-селектор, и любые внешние инструменты или декодеры, ссылающиеся на старый селектор, перестанут работать после обновления. Дополнительные опечатки были найдены в именах переменных Cairo (intiate вместо initiate) и по всему набору тестов Starknet (INTIATE_TYPE вместо INITIATE_TYPE).
Действия
Находка уровня Medium в UDA.sol была устранена заменой непроверенного вызова approve() на safeApprove() из библиотеки SafeERC20, уже импортированной в контракт, что привело функцию initialize() в соответствие с функциями recover(), которые уже корректно использовали SafeERC20.
Находка уровня Low в программах Solana была устранена добавлением проверки require!(redeemer != refundee) в обе функции initiate в solana-native-swaps и solana-spl-swaps.
Опечатки в идентификаторах были исправлены в кодовых базах EVM, Cairo и Starknet: имена ошибок обновлены на корректное написание "Received", имена переменных Cairo исправлены на initiate, а набор тестов Starknet везде обновлён до INITIATE_TYPE.
Итоги
813 независимых исследователей. 15 контрактов на четырёх языках и в четырёх сетях. Одна находка уровня Medium, ноль проблем уровня High или Critical. Medium была устранена с помощью библиотеки, уже присутствующей в кодовой базе. Находки уровней Low и Informational также были устранены.
Аудит Code4rena стал четвёртой и самой широкой проверкой безопасности в программе Garden — после оценок от OtterSec (август 2023 года), Trail of Bits (апрель 2024 года) и Zellic (июнь 2025 года).
Last updated