This audit was performed by Carlos (Bloqarl) as an external contractor at Pashov Audit Group, prior to or alongside founding Zealynx Security. It is not a Zealynx engagement, but is included here as part of Carlos’s professional security record.
Hyperhyper Protocol Smart Contract Security Review
Time-boxed security review of the Hyperhyperfi/protocol repository — Hyperhyper's options-trading protocol built on a diamond-pattern liquidity pool with Black-Scholes pricing, Fenwick-tree liquidity accounting, and a treasury-driven payoff model. Conducted by Pashov Audit Group (unforgiven, merlinboii, Udsen, jesjupyter, Bloqarl, Oualid, Matin) over March 30 - April 12, 2025. Carlos (Bloqarl) participated as a contractor. Fifty-six issues were identified: three Critical (permanent lock from missing unlock mechanism for options; PLP transfer/balance updates not refreshing reward index; incorrect Fenwick-tree index reset after full withdrawal), six High covering option pricing, PUT liquidity, removeLiquidity accounting, locked-fund misuse, slippage control, and payOff underflow; fifteen Medium across pricing, validation, signature, and accounting paths; thirty-two Low covering precision loss, initializer guards, ERC-165 support, role assignments, EIP-712 hashing, oracle configuration, and many smaller correctness items. Fixes review was not fully completed at the time of report and is expected to continue through subsequent follow-up reviews.
Scope
7 filesFindings
click any row for the full write-upKey Findings
Critical (3)
- [C-01] Permanent lock due to missing unlock mechanism for options. Options purchased through the protocol could enter a state with no unlock path, permanently locking user assets in the treasury.
- [C-02] PLP transfer or balance updates do not update reward index. PLP token transfers and balance changes did not invoke the reward-index update, causing reward accounting to drift from actual holdings.
- [C-03] Incorrect index reset in Fenwick tree after full withdrawal. The Fenwick tree underlying liquidity accounting was not correctly reset after a full withdrawal, corrupting subsequent operations on the same tree node.
High (6)
- [H-01] Option premium calculation underprices options. Pricing math underpriced options against the Black-Scholes baseline, allowing buyers to take positions at below-market premiums.
- [H-02] Insufficient liquidity checks for PUT may cause exercise failures. PUT options could be sold without enough pool-side liquidity to honor exercise.
- [H-03] Inaccurate accounting in
removeLiquidity()overstating liquidity. Liquidity removal overstated the resulting available liquidity, allowing subsequent operations to act on more capacity than truly existed. - [H-04] Improper use of locked funds as liquidity in
PositionInteractionFacet. Funds locked for outstanding options could be reused as pool liquidity, double-counting capital. - [H-05] Vulnerability in
PositionInteractionFacetslippage control due to spot price. Slippage control relied on a manipulable spot price source, allowing positions to be opened or closed at adverse prices. - [H-06]
payOff()underflow inOperationalTreasurylocks assets permanently. An underflow in the payoff calculation reverted the entire transaction, permanently locking assets in specific edge cases.
Medium (15)
Hardcoded slippage tolerance (DoS / poor trading); block.timestamp use in DEX swap deadlines; fee calculation uses full instead of net amount for pool impact; missing price feed validation in the oracle contract; LP token transfer without lock data transfer; unrestricted LP burn enables price inflation to exploit deposits; rounding error in PUT option price reduces safety margin; weak signature validation allows multiple option mispricing vectors; strategy contracts ignore exercise window in premium calculation; LiquidityFacet Fenwick-tree attack through multiple deposits; LiquidityFacet unauthorized liquidity removal for other users; OperationalTreasury assumes 1:1 USD value for base token; connect() callable externally in AdminStrategy (DoS); reward index inflation through rounding-up can trap rewards; incorrect ERC-20 transfer in withdrawFee prevents fee withdrawal.
Low (32)
Precision loss in fee calculation, missing _disableInitializers(), missing IERC-165 support, mid-operation underlying token change, missing duplicate token validation in setTargetWeight, role assignment mismatch in PoolAdminFacet, lingering DEX swap token approvals, dynamic maxDepositPerUser staling Fenwick state, uncontrolled id in setPositionsManager, uninitialized maturityDate in Strategy.create(), unbounded protocol fee, irreversible oracle token configuration, missing protocol-fee check in removeToken(), strategy cannot be re-added after removal, payOff() blocked when paused, inefficient payout transfer check, missing _init initializer guard, contract wallets incompatible with EIP-1271, uint32 maturityDate limiting protocol lifespan, missing parent __UUPSUpgradeable_init, missing strike-price slippage, omission of _refreshVirtualPoolValue(), token mismatch in operationalTreasury, updateDexConfig() ignoring pair-specific DEX fees, inconsistent decimal handling in liquidity calc, end-of-day option buys with timestamp dependency, token removal blockable by minimal deposits, incorrect LiquidityFacet decimal conversion, incorrect EIP-712 hashing, option buyers choosing volatility to lower premium, high gas use from Uniswap V3 quoter, indexed keyword in events losing struct data.
Status
The Pashov Audit Group report notes that the fix review was not fully completed at the time of publication and is expected to continue through subsequent follow-up reviews. The audit findings stand as identified vulnerabilities; their final fix status will be verified in subsequent engagements.
For the full per-finding write-up (code, vulnerable paths, proof-of-concept, and recommendations), see the original Pashov Audit Group report PDF.
Team & approval
Disclaimer
This audit is not an endorsement and does not constitute investment advice. Zealynx reviewed the codebase at the commits listed in section 02 over the engagement window. Findings are limited to issues identified within that scope and do not preclude the existence of other vulnerabilities. Subsequent code changes are not covered by this report unless the engagement is explicitly extended.