Felix Protocol

Introduction

Felix is a suite of on-chain borrowing and lending products running on Hyperliquid L1. Its core mission is to let users unlock liquidity or earn yield with low friction and clear, risk-adjusted mechanics. Two primitives anchor the system: a Liquity V2-style CDP market that mints the USD-pegged stable-coin feUSD, and variable-rate Vanilla lending pools.

Key protocol roles mirror these designs:

• Borrowers / Minters (CDP): Deposit HYPE, UBTC, or LSTs to open positions and mint feUSD. They choose their interest rate and target LTV to match their risk appetite.
• Stability-Pool Depositors: Stake feUSD to absorb liquidations, earning streaming borrower interest, a share of up-front fees, and event-driven liquidation gains.
• Vanilla Lenders / Borrowers: Supply or borrow asset-native tokens (e.g., HYPE, HUSD, USDC) at a floating APY with P2P matching on top of the underlying pool.

feUSD is always redeemable for $1 worth of collateral, giving arbitrageurs a hard-backed peg mechanism.

Scope of the Engagement

Three Sigma executed one focused audit on Felix’s price-feed module between 23 July 2025 – 25 July 2025.

The review covered 198 non-comment, non-blank lines of Solidity across LST/underlying price feeds:

• src/PriceFeeds/KHYPEPriceFeed.sol , 119 nSLOC
• src/PriceFeeds/WSTHYPEPriceFeed.sol , 79 nSLOC

Auditors: 2

Effort: 1.2 person-weeks

The primary objectives were to:

• validate price-composition logic for kHYPE/wstHYPE → HYPE → USD across canonical and market paths;
• check deviation-thresholds and redemption-path guards that mitigate oracle frontrunning;
• remove hidden dependencies on third-asset pegs (e.g., USDC/USD) and normalise decimals correctly;
• harden depeg handling and failure-mode fallbacks.

Challenges in Securing Over-Collateralised Stable-Coin Protocols

Oracle & Pricing Pitfalls

Stable-coin and lending systems live and die by safe collateral valuation.

• Hidden peg dependencies: Building HYPE/USD from HYPE/USDC implicitly assumes USDC/USD = 1.0. A USDC depeg skews all USD valuations that depend on HYPE/USD (cf. 3S-Felix-M01).
• Multi-hop conversions: Composed feeds (HYPE/USDC × USDC/USD; LST/underlying × underlying/USD) must normalise to 18 decimals to avoid $1-looks-like-$0.01 errors.
• Dual-price blending: Canonical vs. market quotes need clear tie-break rules (min for borrows, max for redemptions within deviation bands) to resist manipulation.

Decimal & Wrapper Mismatches

Supporting assets with non-18 decimals (e.g., 6-dec USDC) requires careful scaling:

• Truncation dust & rounding: Poor scaling in composed arithmetic silently burns value or flips branch conditions around deviation thresholds.
• Allowance / path mixups: Approvals and data-flow must target the actual wrapper/collateral token used in redemptions and zaps; otherwise leverage and redemption flows can revert.

Flash-Loan & Liquidation Edge Cases

While this engagement focused on price feeds, redemption economics and liquidation triggers are downstream of pricing:

• Over-broad deviation bands: If thresholds exceed oracle update rules, “use-max on redemption” can apply too often, harming peg fairness (cf. 3S-Felix-M02).
• LST market frictions: Assets such as kHYPE feature withdrawal queues (e.g., 7-day unstakes), which can widen market-vs-canonical gaps and raise frontrunning risk during volatile periods (see Informational note).

Results and Findings

Notable Medium-Severity Issues

Inaccurate HYPE/USD due to implicit USDC-peg dependency

Description: KHYPEPriceFeed and WSTHYPEPriceFeed derive USD prices from a Redstone HYPE/USDC feed but do not multiply by USDC/USD, assuming USDC ≡ $1. In a USDC depeg, all HYPE- and LST-USD valuations drift, impacting redemptions and liquidation safety margins.

Resolution: The price path now explicitly composes HYPE/USDC × USDC/USD before combining with LST ratios (e.g., kHYPE↔HYPE, stHYPE↔wstHYPE). This removes the hidden peg assumption and restores accurate USD accounting under stress. Status: Addressed in #398ca73. (3S-Felix-M01)

Incorrect deviation thresholds in KHYPE & WSTHYPE feeds

Description: Deviation constants were set above the referenced oracles’ actual update thresholds (e.g., using 2% or 1% where 0.5% applies). This made “use-max on redemptions within the band” trigger too broadly, giving worse redemption prices during legitimate market spreads.

Resolution: Align all deviation thresholds to 0.5% to match oracle behavior, so frontrunning mitigation applies only when intended. Status: Addressed in #398ca73. (3S-Felix-M02)

Notable Risks

LST market structure heightens oracle-frontrunning surface for kHYPE

kHYPE’s withdrawal queue (e.g., 7-day unstakes) can delay arbitrage, allowing market prices to drift below canonical value during stress. When spreads exceed the oracle’s deviation band, redemption logic falls back to the safer “min(canonical, market),” which may still be gamed around update edges in fast markets. There is no protocol-only fix; the risk is structural to the asset. Recommended actions: communicate user-facing risk, monitor spreads, and consider dynamic redemption guards for extreme, sustained gaps. (3S-Felix-N01)

In conclusion

The engagement removed a hidden peg assumption in the USD price path and right-sized deviation thresholds to the oracle’s real behavior. Together, these fixes: stabilise redemption pricing across market regimes, prevent systemic valuation drift during a USDC depeg, and reduce unnecessary use-max outcomes that could disadvantage feUSD redemptions. With the remediations in #398ca73, Felix’s LST and HYPE pricing is more robust, peg-defense logic is sharper, and downstream liquidation/redemption flows inherit cleaner inputs.

Three Sigma’s Value

Our review went beyond line-by-line correctness to stress the failure modes that matter: composed-oracle arithmetic, deviation-band economics, and LST market frictions. We delivered precise, low-touch code changes that harden Felix’s pricing surface without sacrificing capital efficiency. The result is a clearer redemption policy, safer valuations under peg stress, and a remediation record the community can verify.

We specialize in Liquity v2-fork audits. If your project builds on the Liquity V2 codebase, or adapts it to a new network, let us harden it before launch. Contact us to discuss securing your fork and giving your users total peace of mind.