Auditoría competitiva de Garden Finance: Code4rena
Técnico
TL;DR, Code4rena realizó una auditoría competitiva de los contratos HTLC cross-chain de Garden en EVM, Solana, Starknet y Move en diciembre de 2025. 813 investigadores de seguridad independientes enviaron hallazgos. Se identificó una vulnerabilidad de severidad Medium, un retorno de approve() sin comprobar en UDA.sol; y se resolvió usando SafeERC20. No se encontraron problemas High ni Critical.
Garden realizó una auditoría de seguridad competitiva a través de Code4rena, que cubrió el alcance más amplio de cualquier revisión de seguridad de Garden hasta la fecha; 15 contratos inteligentes escritos en cuatro lenguajes y cuatro cadenas. A diferencia de un encargo tradicional a una firma, el formato de Code4rena abre la base de código a un amplio grupo de investigadores de seguridad independientes que envían hallazgos de forma competitiva, con recompensas pagadas según la severidad y la validez. Se recibieron 813 envíos durante un periodo de dos semanas, con $37,500 en recompensas totales.
La auditoría se centró específicamente en la arquitectura de swaps atómicos basada en HTLC de Garden en EVM, Solana, Sui y Starknet, el conjunto completo de cadenas compatibles con Garden en ese momento. La base de código bajo revisión comprendía 2 163 líneas en Cairo, Move, Rust y Solidity.
Alcance
La auditoría se desarrolló del 24 de noviembre al 8 de diciembre de 2025, evaluada sobre el repositorio C4 Garden Finance en el commit cf7c5b09b7156d6806cc1e68dd924c1b01a5236d y el informe se publicó el 12 de febrero de 2026. Quince contratos inteligentes estuvieron dentro del alcance en cuatro lenguajes y plataformas:
- Solidity / EVM: incluidos UDA.sol, NativeHTLC.sol, ArbNativeHTLC.sol y contratos de swap EVM relacionados
- Rust / Solana: los programas solana-native-swaps y solana-spl-swaps que implementan swaps HTLC de SOL nativo y tokens SPL
- Cairo / Starknet: htlc.cairo, que implementa la lógica HTLC en Starknet
- Move / Sui: módulos HTLC basados en Move
Los objetivos de la evaluación planteados por Garden cubrieron la corrección de las transiciones de estado, la integridad de las transferencias, la unicidad de las órdenes y la autenticidad de los reembolsos, en línea con las preguntas de seguridad aplicadas en la auditoría Move de Zellic, ahora extendidas a todas las cadenas compatibles simultáneamente.
Hallazgos
La auditoría produjo una única vulnerabilidad. Se identificaron cero problemas de severidad High.
M-01; Retorno de approve() sin comprobar causa pérdida permanente de fondos en UDA.sol | Medium
La función UniqueDepositAddress.initialize() llama a ERC20.approve() sin comprobar su valor de retorno:
HTLC(_addressHTLC).token().approve(_addressHTLC, amount);Los tokens ERC20 no estándar, incluidos USDT y BNB, devuelven false en aprobaciones fallidas en lugar de revertir. Como el valor de retorno se ignora, la ejecución continúa incluso cuando la aprobación falla. El resultado: el contrato se marca a sí mismo como initialized, el allowance del token permanece en cero, e initiateOnBehalf() se ejecuta pero el HTLC no puede transferir tokens. Los fondos depositados quedan bloqueados permanentemente sin vía de recuperación, ya que initialized impide la reinicialización.
El contrato ya importa SafeERC20 y lo usa en las funciones recover() — la corrección consistió en aplicarlo también de forma consistente a la llamada approve().
Este hallazgo fue identificado y enviado de forma independiente por diez investigadores distintos.
Falta de validación redeemer != refundee permite órdenes de la misma parte y autorreembolsos instantáneos | Low
La instrucción initiate en ambas implementaciones HTLC de Solana, solana-native-swaps y solana-spl-swaps, no exige que el redeemer y el refundee sean direcciones diferentes. Cuando ambos se establecen en la misma dirección, instant_refund puede llamarse de inmediato sin revelar el secreto ni esperar a que expire el timelock, ya que el consentimiento del redeemer es el único requisito para el reembolso instantáneo y la misma dirección controla ambos roles. Esto rompe el invariante fundamental de HTLC: la contraparte canjea con el secreto, y solo el iniciador puede reembolsar tras la expiración.
Errores ortográficos e identificadores mal escritos en todo el proyecto | Informational
Se identificaron errores ortográficos en las bases de código de EVM, Cairo y Starknet. Lo más significativo desde el punto de vista de la integración: los identificadores de error personalizados NativeHTLC__IncorrectFundsRecieved y ArbNativeHTLC__IncorrectFundsRecieved en los contratos Solidity contienen una escritura incorrecta de "Received." Como los selectores de error personalizados se derivan de keccak256(ErrorSignature), renombrarlos cambia el selector onchain, cualquier herramienta externa o decodificador que haga referencia al selector antiguo se romperá al actualizar. Se encontraron erratas adicionales en nombres de variables de Cairo (intiate en lugar de initiate) y en el conjunto de pruebas de Starknet (INTIATE_TYPE en lugar de INITIATE_TYPE).
Acción
El hallazgo Medium en UDA.sol se resolvió reemplazando la llamada approve() sin comprobar por safeApprove() de la librería SafeERC20 ya importada en el contrato, alineando la función initialize() con las funciones recover() que ya usaban SafeERC20 correctamente.
El hallazgo Low en los programas de Solana se abordó añadiendo una comprobación require!(redeemer != refundee) en ambas funciones initiate de solana-native-swaps y solana-spl-swaps.
Las erratas en los identificadores se corrigieron en las bases de código de EVM, Cairo y Starknet, los nombres de error se actualizaron para usar la escritura correcta "Received", los nombres de variables de Cairo se corrigieron a initiate, y el conjunto de pruebas de Starknet se actualizó a INITIATE_TYPE en su totalidad.
Resumen
813 investigadores independientes. 15 contratos en cuatro lenguajes y cuatro cadenas. Un hallazgo Medium, cero problemas High o Critical. El Medium se resolvió usando una librería ya presente en la base de código. Los hallazgos Low e Informational también se abordaron.
La auditoría de Code4rena fue la cuarta y más amplia revisión de seguridad del programa de Garden, tras las evaluaciones de OtterSec (agosto de 2023), Trail of Bits (abril de 2024) y Zellic (junio de 2025).
Last updated