HypurrFi Pooled

HypurrFi runs pooled lending markets where users post collateral, borrow against it, and can loop the position to increase yield. Its only deployment is on Hyperliquid L1, a chain the registry has rejected, so client money cannot reach anything it offers, no matter how well the markets are run. The settlement chain fails vetting before we examine the protocol itself. It held $5.8M across 14 pools at the August 14, 2026 survey. The verdict changes if the protocol deploys on an approved chain or the Hyperliquid L1 verdict changes.

Review triggers: events that reopen the verdict
• Deploys meaningful liquidity on a chain the registry approves
• The Hyperliquid L1 verdict changes

Watched nightly: a warning on its venues or files, or a cited document that changes, reopens the memo. The first confirmation is due 2026-11-15.

The research file

Applicability to the surveyed record

HypurrFi documents an Aave-style pooled lending contract where suppliers receive interest-bearing hyTokens, borrowers post reserve collateral, and utilization, loan-to-value, liquidation thresholds, caps, and reserve settings govern positions. Users can borrow and resupply in a loop, but the shared rejected-chain rule decides the case before we review the protocol’s quality.

Current observation and perimeter

The DefiLlama protocol API read on 2026-08-15 classified HypurrFi Pooled as Lending, reported only Hyperliquid L1, and showed approximately $5.72M TVL with about $2.44M borrowed. Primary smart-contract documentation names the deployment as HyperEVM and says HypurrFi Governance owns its PoolAddressesProvider, which places it within the rejected settlement boundary.

Control and exit applicability

Governance-controlled roles can set reserve collateral, oracle sources, caps, fees, activation, freezing, and pauses. Suppliers withdraw through the same HyperEVM pool and can take only the reserve liquidity available. Borrowers and looped positions depend on oracle health factors and liquidation. No protocol action, secondary hyToken transfer, or repayment path avoids settlement on Hyperliquid L1.

Why the class rule decides

The shared v1 rejected-chain file decides the case because every pooled-market contract, oracle update, collateral transfer, liquidation, and withdrawal still settles on Hyperliquid L1. Reopen only if the chain receives an approved verdict or HypurrFi deploys meaningful, separately auditable liquidity on an approved chain. Then review governance and roles, reserves and oracles, interest and liquidation parameters, audits and incidents, market liquidity, loop exposure, stressed withdrawals, and named lending alternatives.

Class rule

The rejected chain class is outside the approved structures, so every protocol in it is not approved until the rule changes. The rule is about the structure, not an adverse finding about this protocol, and it is not a client instruction. The events that would reopen it are listed with the memo.

Sources

The claims above trace to these. Where a number could not be independently verified, the thesis says so.

• HypurrFi — pooled market contract · primary · accessed 2026-08-15
  Supports: pooled lending, hyTokens, collateral, liquidation, reserve configuration, withdrawal liquidity
• HypurrFi — access control manager · primary · accessed 2026-08-15
  Supports: HyperEVM, governance ownership, admin roles, oracle control, reserve listing
• HypurrFi — pool configurator · primary · accessed 2026-08-15
  Supports: supply caps, risk admin, pool admin, reserve controls, fees
• DefiLlama — HypurrFi Pooled survey record · secondary · accessed 2026-08-15
  Supports: current TVL, borrowed amount, Hyperliquid L1 perimeter, Lending category

Inherited controls

The research above describes the protocol layer. Every position also inherits the asset it holds and the chain it settles on. The layer with the most administrative power sets the position’s effective control; that describes control, not quality or suitability.