Garden Move HTLC Security Assessment: Zellic
Technical
TL;DR, Zellic reviewed Garden's Move based HTLC contract on Sui, focusing on state transition correctness, transfer integrity, order uniqueness, and early refund authenticity. Two findings were identified, one Medium and one Informational, and both were resolved in code.
Intro
Garden engaged Zellic to conduct a security assessment of the Move based HTLC implementation deployed on Sui. The review was conducted by Sunwoo Hwang and Varun Verma in May, 2025, with the report delivered in June, 2025.
The assessment covered sources/main.move in the htlc-sui repository; the single module implementing Garden's atomic swap logic on Sui using the Move language. Zellic's review examined the contract both manually and with automated tooling, covering coding mistakes, business logic errors, integration risks, and code maturity.
Zellic's overall conclusion was that the core swap logic is sound: balances move only under the correct state transitions, and coin flows are hardcoded to initiator or redeemer addresses with no alternative recipient paths.
Scope
The assessment covered:
- sources/main.move: the Move module implementing HTLC-based atomic swaps on Sui, including order initiation, redemption, standard refund, and instant refund with Ed25519 signature verification
Zellic's assessment goals were framed as four specific security questions: whether funds move only under correct state transitions; whether transfer integrity is enforced with all coin flows hardcoded to initiator or redeemer addresses; whether order uniqueness is enforced to prevent duplicate or replayed orders; and whether early refunds require a valid Ed25519 signature from the rightful redeemer.
Findings
Zellic identified two findings. One Medium severity, one Informational. No Critical, High, or Low severity issues were identified.
Finding 3.1; Duplicate-order denial of service via front-running deterministic order_id | Medium
The order_id is computed as sha256(secret_hash || initiator || redeemer || timelock). All four inputs are visible in a pending transaction's calldata to any mempool listener. Additionally, the initiate_on_behalf function allows any address to supply those same four values without proving ownership of the initiator address.
An attacker can copy the four fields from a victim's pending swap transaction and submit initiate_on_behalf with an identical field set and amount = 1. If their transaction confirms first, the registry stores a dust order under that order_id, causing the victim's subsequent transaction to abort with EDuplicateOrder.
The practical attack surface is during high-volatility windows: an attacker monitoring the mempool for arbitrage executing HTLCs can block a competitor's swap at negligible cost, a 1-unit dust deposit, and capture the arbitrage opportunity themselves. Likelihood and impact are both rated Medium.
Finding 3.2; Unbounded timelock allows accidental permanent lock | Informational
The contract correctly enforces expiry as initiated_at + timelock < now, but timelock itself has no maximum value. A user could accidentally pass an extremely large number such as u256::MAX, and create an order whose funds are permanently locked with no practical path to refund. This is a user experience and safety risk rather than an exploitable vulnerability; there is no adversarial angle since the user would be locking their own funds.
Action
Both findings were acknowledged by Garden and resolved in code.
- Finding 3.1 was fixed in commit e85e06c9 by introducing an unpredictable salt, a fresh UID or nonce into the order_id preimage, making the identifier non-deterministic and front-running the derivation infeasible.
- Finding 3.2 was fixed in commit 4b9c871f by applying a maximum bound on timelock in safe_params, capping it at a sensible upper limit to prevent accidental permanent locks.
Summary
Two findings: one Medium, one Informational both resolved in code. No Critical, High, or Low severity issues. Zellic's closing assessment confirmed that the core swap logic is clean and that the contract's foundational security properties, correct state transitions, transfer integrity, order uniqueness and authenticated early refunds, were verified as sound.
Garden treats security as an ongoing initiative and runs open, competitive bug bounties, such as the recent Code4rena audit, which offered $37,500 in rewards across 813 submissions, targeting the HTLC architecture across Bitcoin, EVM, Solana, Sui, and Starknet. Information on all audits can be found on https://garden.finance/security.
Last updated