Garden HTLC Swapper Security Audit: OtterSec
Technical
TL;DR, OtterSec reviewed Garden's HTLC swapper contracts across EVM and Bitcoin script implementations. Two informational findings were raised; one, inconsistent expiry semantics across chains that was patched. Second, noted that locked funds remained redeemable after contract expiry; team intentionally preserved this behaviour on the Ethereum side to maintain parity with Bitcoin's unalterable script.
Garden engaged OtterSec to conduct an external security assessment of the swapper program; the core contract implementing Garden's cross-chain atomic swap functionality. The audit covered both the EVM contracts and Bitcoin script implementation of the Hash Time Lock Contract.
HTLCs are the cryptographic primitive that makes Garden's architecture work. Every swap is a discrete HTLC: funds are locked with a hash condition and a time window. The counterparty can claim them by producing the correct secret preimage, or the initiator reclaims them after expiry. There is no bridge contract, no pooled liquidity, no custodian. The correctness of the HTLC implementation is the protocol's security model, which makes this the right place to start a security programme.
Scope
The audit was conducted in August, 2023. The OtterSec team; Nicholas R. Putra, Woosun Song, and Robert Chen, assessed the swapper repository.
Two components were in scope:
- contracts/AtomicSwap.sol: the Ethereum side Solidity implementation, covering fund initiation, secret-based redemption, and expiry-based refund logic
- bitcoin/AtomicSwap.ts: the Bitcoin script implementation using OP_CHECKSEQUENCEVERIFY for time-locked outputs
OtterSec's methodology runs across two tracks. Design review examines economic soundness, whether funds can be extracted or service denied independent of any chain-specific implementation detail. Implementation review covers chain-execution specifics: reentrancy, access control, arithmetic overflows, account ownership, and rounding errors. Both tracks were applied across both chain implementations.
Findings
OS-CTL-SUG-00; Inconsistent expiry semantics across chains
The Ethereum and Bitcoin implementations expressed the expiry parameter differently at a semantic level. In AtomicSwap.sol, expiry is validated as an absolute block number:
require(expiry > block.number, "AtomicSwap: expiry cannot be lower than current block");This means expiry refers to a specific point in chain history. The contract rejects any initiation where that block has already passed.
In the Bitcoin script, expiry is handled via OP_CHECKSEQUENCEVERIFY. This opcode doesn't reference an absolute block; it measures relative time elapsed since the UTXO was created. Expiry on the Bitcoin side is a duration, not a fixed point in time.
Both implementations function correctly in isolation. The risk is in cross-chain development: a developer working across both sides of the stack could carry incorrect assumptions about what expiry means, and that semantic gap widens as a maintainability and correctness risk as the codebase grows.
OS-CTL-SUG-01; Post-expiry redemption remains possible
In a canonical HTLC design, the counterparty's redemption window and the initiator's refund window are mutually exclusive. Once expiry passes, the counterparty can no longer redeem using the secret preimage; only the initiator can reclaim funds. Garden's implementation did not enforce this exclusivity: the redeem function remained callable after contract expiry on both the Ethereum and Bitcoin sides.
OtterSec produced two findings, both classified as Informational; the lowest severity tier, representing best-practice recommendations rather than exploitable vulnerabilities. Zero Critical, High, Medium, or Low severity issues were identified.
Action
OS-CTL-SUG-00 was patched both implementations were aligned to use consistent expiry semantics going forward. OS-CTL-SUG-01 was not remediated on the Ethereum side, and the decision is deliberate. Bitcoin scripts are immutable once deployed. Post-expiry redemption is a structural property of the Bitcoin HTLC, not a bug: OP_CHECKSEQUENCEVERIFY only enforces that the minimum time has elapsed before the initiator can refund, it does not enforce a hard cutoff on the counterparty's ability to redeem.
Patching Ethereum to block post-expiry redemptions would introduce a behavioural asymmetry between chains, where equivalent swaps resolve differently depending on which side the redemption lands. Garden determined that asymmetry to be a greater risk than the behaviour OtterSec flagged, and documented the decision explicitly in the audit report.
Summary
Two informational findings; one patched, one deliberately preserved with documented rationale. No critical, high, medium, or low severity vulnerabilities. No exploitable logic, no access control issues, no arithmetic risks.
Since this review, Garden has completed a protocol-wide security assessment with Trail of Bits (April 2024) and a Move application assessment with Zellic (June 2025). Garden also ran a competitive bug bounty through Code4rena (December 2025) with $37,500 in rewards across 813 submissions, targeting the HTLC architecture across Bitcoin, EVM, Solana, Sui, and Starknet.
Last updated