Hyperlend Protocol Audit Summary

Hyperlend is a lending protocol deployed on the Hyperliquid chain. The protocol implements risk-segmented lending pools designed for different use cases. The protocol’s infrastructure includes cross-chain deposit endpoints for protocol pools, looping contracts that enable position management through flashloans, and helper contracts for asset listing functionality

Hyperlend engaged Ackee Blockchain Security to perform a security review of the Hyperlend protocol with a total time donation of 46 engineering days in a period between January 10 and February 7, 2025.

A second, fix review was then performed between February 17 and February 24, 2025.

A third review was then performed between March 12 and March 18.

METHODOLOGY

We began our review with a deep dive into the logic of the contracts. We supported our review with static analysis tools, including Wake, and manually guided fuzzing checking basic functionality of the code in-scope.

During the review, we paid special attention to:

• ensuring tokens cannot be stolen or unintentionally locked in the contracts;
• detecting possible reentrancies in the code;
• checking integration with third-party contracts is correct and secure;
• common issues such as data validation.

SCOPE

The audit was performed on the following repositories and commits:

• hyperlend-core commit 425624;
• hyperlend-isolated commit 37c678;
• looping-contracts (private repository) commit 0fdde7;
• core-config-engine commit 0339f1;
• cross-chain-lending-deposits (private repository) commit 43b101.

The fix review was performed on the following repositories and commits:

• hyperlend-core commit 625161;
• hyperlend-isolated commit 0b90ce;
• looping-contracts (private repository) commit cb6fac;
• core-config-engine commit 4ff785;
• cross-chain-lending-deposits (private repository) commit 38dc8a.

The third audit was performed on the hyperlend-core-new repository, commit 0c2b14. The scope included all changes made in the src directory compared to the original Aave v3.2 codebase.

FINDINGS

The classification of a security finding is determined by two ratings: impact and likelihood. This two-dimensional classification helps clarify the severity of individual issues. Issues which would be rated as medium severity, but which would be likely discovered only by the team, are typically decreased by the likelihood factor to the Warning or Informational severity ratings.

Our review resulted in 44 findings, ranging from Info to Critical severity. The most severe finding C1 posed a critical risk of all collateral tokens being stolen from the isolated pools of the protocol. The finding was reported despite being out-of-scope for the review, as the core issue was in incorrect usage of a new Chainlink-like price provider in the context of the original Fraxlend V3 codebase. The issue was undetectable by performing only differential review without the context of the original codebase.

Findings C1, M1, M2, M7, M10, L2 were discovered through manually-guided fuzzing using the Wake testing framework. Findings M5, M10, M11, M13, and I10 were discovered through Wake static analysis.

Critical severity

C1: No revert on stale Chainlink price

High severity

H1: Possible locked tokens

Medium severity

M1: Incorrect proposal ID emitted

M2: Missing support for bridging native tokens

M3: Arbitrary token transfer through unrestricted refund function

M4: Incorrect token balance check leading to failed position closures

M5: Divide before multiply in openPosition function

M6: Missing payable modifier

M7: minAmountOut calculation too restrictive

M8: Inconsistent token symbol formatting

M9: Missing token validation on bridge initiation

M10: SafeERC20 not used

M11: Native transfer revert out-of-gas

M12: WalletBalanceProvider native tokens lockup

M13: Missing Chainlink price feed validation

Low severity

L1: Missing swap deadline protection

L2: Try/catch may still revert

L3: Unsatisfiable condition on closing position with flashloans

L4: Incorrect error messages

L5: Missing receive function for native token handling

L6: Missing queued transaction verification in cancelTransaction

L7: Same transaction can be queued multiple times

L8: Native token recovery can be bypassed

Warning severity

W1: Missing check to catch underflow error

W2: Double listing proposal ID

W3: Case insensitive import

W4: Hardhat console imports

W5: Unused state variables in StrategyManager

W6: Missing zero address validation

W7: Lack of events

W8: Missing proposal existence validation

W9: Potential negative exponent in CHAINLINK_NORMALIZATION calculation

W10: Incorrect token balance used for debt value calculation

Informational severity

I1: Missing underscore in internal function name

I2: Incorrect variable naming due to typo

I3: Unused Ownable inheritance

I4: Inconsistent visibility for _reversePath function

I5: getUserAccountData function reverts when token price is zero

I6: getUserPairs returns an array with empty positions

I7: Unused swapPath parameter in SwapParams struct

I8: Unused function with potential data truncation risk

I9: Incorrect documentation

I10: Variables can be immutable

TRUST MODEL

Users must trust Hyperlend not to lock funds in the protocol or manipulate token prices. Stargate gateways must be trusted to correctly relay messages between chains during cross-chain deposits.

CONCLUSION

Ackee Blockchain Security recommends Hyperlend to:

• keep informed about the latest fixes made to the Aave and Fraxlend codebases; and
• maintain best security practices when listing new tokens, ensuring quality of price oracles, and monitoring health of the protocol pools.

Ackee Blockchain Security’s full Hyperlend audit report can be found here.