Saucerswap Perpetuals

Introduction#

Saucerswap Labs engaged Halborn to perform a smart contract security assessment of the Saucerswap Perpetuals from October 7th, 2026 to October 16th, 2026. The assessment focused on Hedera compatibility of the GMX Synthetics fork, covering all Solidity contracts in the contracts/ tree, and also covered the Saucerswap farm contracts (MasterChef, its interface and the RewardStream library). The Scope section lists the reviewed files, commits, exclusions, and assessment limits.

Saucerswap Perpetuals is a fork of GMX Synthetics, a decentralized perpetuals trading protocol, adapted for the Hedera network. It is deployed on hederaTestnet, with hederaMainnet deployment planned. The fork adapts GMX's trading, liquidation, automatic deleveraging, fee collection, oracle, relay and vault contracts to Hedera's account model, the Hedera Token Service and Hedera's EVM execution environment.

Assessment Summary#

Halborn was allocated 8 business days for this engagement and assigned 1 full-time security engineer to conduct a comprehensive review of the source code within scope. The engineer is an expert in blockchain and smart contract security, with advanced skills in penetration testing and smart contract exploitation, as well as extensive knowledge of multiple blockchain protocols. The objectives of this assessment were to:

• Identify deviations between Hedera's EVM execution environment and EVM-standard assumptions in the GMX Synthetics base contracts that affect correctness or security.

• Assess HTS token association, receipt, and transfer paths across all custodian contracts, including vault, market token, and fee collection contracts.

• Review keeper-transaction isolation for account-controlled callbacks, native-token refunds, and relay calls under Hedera's execution constraints.

• Verify that oracle and relay behavior is consistent with Hedera's block timestamps, address model and supported signature types.

• Check contract behavior under the deployed hederaTestnet configuration and the settings planned for hederaMainnet.

• Review reward accounting, HTS token handling and access control in the farm contracts.

In summary, Halborn identified several areas for improvement to reduce the likelihood and impact of security risks, which were addressed by the Saucerswap Labs team. The primary recommendations were:

• Remove HederaTokenService from the MasterChef inheritance list, so its unrestricted transferFrom, transferFromNFT and redirectForToken functions are no longer exposed, and replace the inherited mintToken with a private helper.

• Remove account-controlled callbacks and native-token refunds from forced liquidation and ADL keeper transactions; invoke optional user callbacks in separate transactions and pay all refunds as WHBAR to a validated receiver address.

• For local forced liquidation and ADL orders, set shouldUnwrapNativeToken to false and pay positive outputs as WHBAR; where native delivery is retained, place it in a separately called helper so the WHBAR fallback remains reachable in the calling frame.

• For local GM, GLV and native or WHBAR payout receivers, resolve a numeric account through the Hedera Account Service getEvmAddressAlias function and reject a numeric form that has a distinct preferred alias, at creation and at credit execution.

• In Oracle::_setPrices, move the NonEmptyTokensWithPrices guard before the early return for an empty list, so a nested relay call with empty oracle parameters reverts rather than clearing prices set by an outer keeper action.

• In HTSInteractable, add an add-only function that calls IHRC719(token).associate() for each listed HTS token on every custodian contract, and on chain IDs 295 and 296 make enableAutoAssociation revert or remove it; confirm the hederaMainnet deployer has maxAutoAssociations = -1.

• In ConfigUtils::validateRange, add a bound for chain IDs 295 and 296 so combined callback and auto-cancel gas caps cannot exceed Hedera's 15 million gas transaction limit; use a separate, smaller callback gas limit for liquidation and ADL.

Test Approach and Methodology#

Halborn used manual source review and targeted research of Hedera primary sources. Manual review examined all Solidity contracts in the contracts/ tree, using the upstream GMX Synthetics fork diff (base commit f1c0125) as change context; deploy and configuration scripts were read as context only. The assessment included:

• Research of Hedera primary sources including HIPs, Hedera Smart Contract Service and Hedera Token Service release notes, and JSON-RPC relay specifications.

• Read-only queries to hederaTestnet and hederaMainnet using mirror node REST and eth_call; no transactions were sent to live networks.

• Proof-of-concept execution on a local Hedera consensus node v0.77.5 for the two High findings, with results independently reviewed.

• Compiler version known-issue check and comparison against a historical vulnerability database.

• For the farm contracts: a full manual review, static analysis with Slither, Aderyn and Semgrep, and a local-node proof of concept for the Critical finding.

• Manual test cases recorded for every check as Pass or Fail.

Generic GMX protocol logic was reviewed only where its behavior changes on Hedera.

Risk Methodology#

Scope#