Auditoría de seguridad del Garden HTLC Swapper: OtterSec
Técnico
.TL;DR, OtterSec revisó los contratos del HTLC swapper de Garden en las implementaciones de EVM y de Bitcoin script. Se plantearon dos hallazgos informational; uno, una semántica de expiración inconsistente en las distintas cadenas que se parcheó. El segundo señaló que los fondos bloqueados seguían siendo redimibles después de la expiración del contrato; el equipo preservó este comportamiento de forma intencionada.
Garden contrató a OtterSec para realizar una evaluación de seguridad externa del programa swapper; el contrato central que implementa la funcionalidad de swap atómico cross-chain de Garden. La auditoría cubrió tanto los contratos EVM como la implementación en Bitcoin script del Hash Time Lock Contract.
Los HTLCs son la primitiva criptográfica que hace funcionar la arquitectura de Garden. Cada swap es un HTLC discreto: los fondos se bloquean con una condición de hash y una ventana de tiempo. La contraparte puede reclamarlos produciendo la preimagen secreta correcta, o el iniciador los recupera después de la expiración. No hay contrato de bridge, ni liquidez agrupada, ni custodio. La corrección de la implementación del HTLC es el modelo de seguridad del protocolo, lo que convierte a esto en el punto adecuado para comenzar un programa de seguridad.
Alcance
La auditoría se llevó a cabo en agosto de 2023. El equipo de OtterSec; Nicholas R. Putra, Woosun Song y Robert Chen, evaluó el repositorio swapper.
Dos componentes estaban dentro del alcance:
- contracts/AtomicSwap.sol: la implementación en Solidity del lado de Ethereum, que cubre la iniciación de fondos, la redención basada en el secreto y la lógica de reembolso basada en la expiración
- bitcoin/AtomicSwap.ts: la implementación en Bitcoin script que usa OP_CHECKSEQUENCEVERIFY para salidas con timelock
La metodología de OtterSec se desarrolla en dos vías. La revisión de diseño examina la solidez económica, si se pueden extraer fondos o denegar el servicio con independencia de cualquier detalle de implementación específico de una cadena. La revisión de implementación cubre los aspectos específicos de la ejecución en cadena: reentrancy, controles de acceso, desbordamientos aritméticos, propiedad de cuentas y errores de redondeo. Ambas vías se aplicaron a las dos implementaciones de cadena.
Hallazgos
OS-CTL-SUG-00; Semántica de expiración inconsistente en las distintas cadenas
Las implementaciones de Ethereum y Bitcoin expresaban el parámetro expiry de forma diferente a nivel semántico. En AtomicSwap.sol, expiry se valida como un número de bloque absoluto:
require(expiry > block.number, "AtomicSwap: expiry cannot be lower than current block");Esto significa que expiry hace referencia a un bloque concreto. El contrato rechaza cualquier iniciación en la que ese bloque ya haya pasado.
En el Bitcoin script, expiry se gestiona mediante OP_CHECKSEQUENCEVERIFY. Este opcode no hace referencia a un bloque absoluto; mide el tiempo relativo transcurrido desde que se creó el UTXO. En el lado de Bitcoin, expiry es una duración, no un punto fijo en el tiempo.
Ambas implementaciones funcionan correctamente de forma aislada. El riesgo está en el desarrollo cross-chain: un desarrollador que trabaje en los dos lados del stack podría arrastrar suposiciones incorrectas sobre lo que significa expiry, y esa brecha semántica se amplía como riesgo de mantenibilidad y de corrección a medida que crece la base de código.
OS-CTL-SUG-01; La redención después de la expiración sigue siendo posible
En un diseño canónico de HTLC, la ventana de redención de la contraparte y la ventana de reembolso del iniciador son mutuamente excluyentes. Una vez que pasa la expiración, la contraparte ya no puede redimir usando la preimagen secreta; solo el iniciador puede recuperar los fondos. La implementación de Garden no imponía esta exclusividad: la función redeem seguía siendo invocable después de la expiración del contrato, tanto en el lado de Ethereum como en el de Bitcoin.
OtterSec produjo dos hallazgos, ambos clasificados como Informational; el nivel de severidad más bajo, que representa recomendaciones de buenas prácticas en lugar de vulnerabilidades explotables. Se identificaron cero problemas de severidad Critical, High, Medium o Low.
Acción
OS-CTL-SUG-00 se parcheó ambas implementaciones se alinearon para usar una semántica de expiración consistente en adelante. OS-CTL-SUG-01 no se remedió y la decisión es deliberada. La redención después de la expiración es una propiedad estructural; no impone un corte estricto en el contador.
Resumen
Dos hallazgos informational; uno parcheado, uno preservado deliberadamente con una justificación documentada. Ninguna vulnerabilidad de severidad critical, high, medium o low. Ninguna lógica explotable, ningún problema de control de acceso, ningún riesgo aritmético.
Desde esta revisión, Garden ha completado una evaluación de seguridad de todo el protocolo con Trail of Bits (abril de 2024) y una evaluación de la aplicación Move con Zellic (junio de 2025). Garden también realizó un bug bounty competitivo a través de Code4rena (diciembre de 2025) con $37,500 en recompensas repartidos entre 813 envíos, dirigido a la arquitectura HTLC en EVM, Solana, Sui y Starknet.
Last updated