Seven days, six security researchers, five scoped Solidity files, and a leveraged position flow connected to a protocol with more than $328M in public TVL during the review window. This is what the engagement actually covered and what the report documented.
When Code Supports Hundreds of Millions in DeFi TVL
A smart contract does not become more complicated simply because a protocol grows from $10 million to hundreds of millions in total value locked. The consequences of getting one assumption wrong do.
HyperLend’s public DeFiLlama series recorded approximately $328.4 million in protocol TVL on April 4, 2026 and $362.4 million on April 10, the seven-day window documented in the Kann Audits report. The latest data point available when this case study was prepared was approximately $548.9 million on August 28, 2026. Those figures describe HyperLend’s broader protocol TVL. They are not a claim that every dollar passed through the five contracts in our scope.
That distinction matters. Kann Audits reviewed HyperLend’s leveraged-lending strategy infrastructure: strategy-manager creation and ownership, position opening and closing, flashloan-driven looping, and two swap adapters. We did not audit every HyperLend core-pool, oracle, liquidation, or governance contract in this engagement.
The security question was therefore precise: could the scoped contracts be made to account for assets, debt, native refunds, ownership, or swap output differently from the workflow the developers intended?
“Does the code work? is a functional question. How can this system be made to behave in a way the developers never intended? is the security question.”
The Protocol and the Leveraged-Lending Flow
HyperLend’s official documentation describes it as a high-performance lending protocol on Hyperliquid built for capital efficiency, real-time leverage, dynamic rates, and deep liquidity access. Its broader architecture centers on lending pools where users supply assets, borrow against collateral, and manage health-factor and liquidation risk.
The reviewed repository focused on HyperLoop-style leveraged positions. HyperLend documents HyperLoop as an atomic flow: borrow a debt asset with a flashloan, swap it into a yield asset, supply that yield asset as collateral, borrow the debt asset against the new collateral, and repay the flashloan in the same transaction.
This creates a dense integration boundary. One user action crosses an isolated strategy manager, a looping coordinator, a lending pool, debt and yield tokens, a flashloan, and a swap adapter. A mismatch between global debt and position debt, native and wrapped assets, or current and historical ownership can break the transaction even if every component appears reasonable in isolation.
Why This DeFi Security Audit Mattered
Leveraged lending compresses several economically sensitive actions into one atomic sequence. The contract must calculate the correct flashloan amount, swap the intended balance, supply the right collateral, borrow the exact debt, satisfy minimum output, and leave no unrelated value assigned to the current user.
Opening is only half the security model. Closing a full position has to separate debt attributable to that position from unrelated debt the user may hold in the same asset. Refund paths must be payable. Ownership transfers must remain consistent with registries used by interfaces and integrations. Temporary swap instructions must live for exactly the intended execution lifetime.
At protocol scale, small boundary errors can affect user exits, move residual balances, create stale ownership records, or make integrations report a state that no longer matches contract authority. That is why the audit treated accounting and component interaction as security-critical infrastructure rather than implementation detail.
Understanding the Scoped Attack Surface
The report fixed the reviewed code at commit 4f5deaf and listed five Solidity files: StrategyManagerFactory.sol, StrategyManager.sol, Looping.sol, GluexAdapter.sol, and LiquidSwapAdapter.sol. Those files define the boundaries below.
Position Lifecycle
- Strategy-manager creation
- Position ownership
- Open and close sequencing
- Cleanup after execution
Asset Movement
- Flashloan repayment
- Debt and yield token balances
- Native-to-WHYPE wrapping
- Swap minimum output
Integration Boundaries
- Lending-pool balances
- GlueX calldata
- LiquidSwap paths
- EIP-1153 transient storage
How Six Security Researchers Approached the Review
The published report names six researchers and documents a manual review from April 4 through April 10. Researchers first reviewed the in-scope code independently, then used collaborative sessions to compare findings and explore additional attack vectors. The report also says the team triaged output generated by the Kann AI Labs auditing tool; that output was an additional signal, not a substitute for human validation.
The methodology included line-by-line inspection, architecture and trust-boundary analysis, access-control verification, state-transition review, comparison with established implementations, and checks against common and uncommon smart contract attack vectors.
For this scope, the most important invariants were operational: a swap must transfer only output attributable to that swap; closing one position must not accidentally include unrelated debt; native cleanup logic must be reachable by the assets it expects; and a manager registry should not silently diverge from current ownership.
| Perspective | Primary question | Security implication |
|---|---|---|
| Developer | Does the position open and close on the expected path? | Confirms intended functionality |
| Security researcher | Which balances, callers, and states can differ from the expected path? | Finds broken assumptions |
| Attacker | Can that difference transfer value, block an exit, or create repeatable advantage? | Turns a mismatch into impact |
What the Published HyperLend Report Found
The report documented five findings: one Low-severity issue and four Informational issues. It reported no Critical, High, or Medium findings. One Informational item was Resolved; the Low finding and the other three Informational findings were Acknowledged.
Finding counts do not measure the total safety of a protocol, and severity should not be inflated for marketing. The useful evidence is the behavior each finding documents, the status recorded by the report, and the exact scope to which the assessment applies.
| ID | Finding | Severity | Status |
|---|---|---|---|
| L-01 | Entire native balance included in swap output | Low | Acknowledged |
| I-01 | Redundant block-number check for transient storage | Informational | Resolved |
| I-02 | Full close includes unrelated same-asset debt | Informational | Acknowledged |
| I-03 | Manager cannot receive native refunds | Informational | Acknowledged |
| I-04 | Factory registry becomes stale after ownership transfer | Informational | Acknowledged |
The Finding With the Clearest Asset-Flow Consequence
L-01 concerned the swap adapters’ handling of native token balances when the desired output was WHYPE. The adapter wrapped address(this).balance, then used its total WHYPE balance when checking minimum output and transferring proceeds to the recipient.
The Problem
address(this).balance is the complete native balance held by the adapter, not necessarily the amount returned by the current swap. If native tokens were already present before execution, the adapter would wrap those unrelated funds alongside the new swap proceeds.
uint256 beforeBalance = address(this).balance;
executeSwap();
// Vulnerable pattern: wraps every native token held by the adapter
if (address(this).balance > 0) {
WHYPE.deposit{value: address(this).balance}();
}
IERC20(address(WHYPE)).safeTransfer(to, WHYPE.balanceOf(address(this)));Why It Mattered
The violated invariant was attribution: the current swap recipient should receive only output produced for that swap. Pre-existing adapter funds belong to a different accounting context and should not increase the current user's amountOut.
Potential Execution Path
The published report rated this issue Low and described users receiving more output than intended. It did not label the issue Critical, High, or Medium, and its status is Acknowledged. This case study preserves that assessment rather than presenting it as a prevented major exploit.
The General Fix Pattern
Snapshot balances before the external swap, calculate the native or token delta produced by the operation, wrap only that delta, and transfer only the attributable output. Protocols should also define how accidental balances are recovered without assigning them to whichever user executes next.
Before deploying similar logic, verify
- Is swap output calculated from a before-and-after delta?
- Can pre-existing or force-sent native value enter the current user's output?
- Does amountOutMin validate attributable output rather than total contract balance?
- Is there an explicit and authorized residual-balance recovery path?
Position Isolation and Native Refund Boundaries
Two Informational findings demonstrated why leveraged strategies must preserve boundaries across a user's broader account and external refund behavior.
Closing One Position With Unrelated Same-Asset Debt
When withdrawAmount was set to the maximum uint256 value, the close path read the user's global variable-debt token balance for the debt asset. If the same user had another borrow denominated in that asset, repaymentAmount could exceed the flashloan amount allocated to this strategy. The later pool repayment would then revert for insufficient balance.
The security lesson is scope isolation: a strategy that owns one position must not infer its liability from an account-wide balance unless it intentionally closes every position represented by that balance.
Cleanup Logic for Native Refunds
StrategyManager contained a branch to send native balances to its owner, implying that native-value cleanup was part of the design. The contract did not implement receive() or a payable fallback, so standard native refunds or direct native transfers would revert before that cleanup branch could help.
Integration logic has to be reviewed in both directions: not only what the strategy sends, but also what an external router, adapter, or refund path may send back.
Developer Checklist
Before deploying similar logic, verify
- Does each isolated position track only debt attributable to that position?
- Can a user hold unrelated debt in the same asset through another strategy?
- Can every expected native refund reach a payable receiver?
- Are failure, refund, and cleanup paths tested against real integration behavior?
State Lifetime and Ownership Consistency
The remaining two Informational findings concerned assumptions about how long state remains valid and which component is authoritative for ownership.
Transient Storage Already Enforced Transaction Lifetime
Both swap adapters stored block.number in EIP-1153 transient storage and checked it during swap execution. The intended property was same-transaction use. EIP-1153 already clears transient storage at the end of every transaction, including between transactions in the same block, so the block-number check added complexity without strengthening the property. The report marks this item Resolved.
Factory Registry Could Diverge From Current Ownership
StrategyManagerFactory indexed managers by the address that created them, while manager ownership remained transferable. After a transfer, the factory still associated the manager with its original creator and did not expose the new owner through that registry.
The general lesson is to define one source of truth. If ownership can move, every registry presented as an ownership index must update atomically, derive current ownership from the manager, or clearly document that it represents creation history rather than present authority.
Security Is More Than Producing a Findings Count
A credible case study has to preserve the report's actual remediation record. In this engagement, I-01 was marked Resolved. L-01, I-02, I-03, and I-04 were marked Acknowledged. The audited and final commit listed in the report are both 4f5deaf, so the document does not present a separate final remediation commit for those acknowledged items.
Acknowledged does not mean Fixed. It records that the issue is known within the published assessment. Readers should consult the complete report and current repository before drawing conclusions about later implementation changes.
The value of the audit was the evidence: a fixed scope, six named researchers, explicit findings, technical explanations, and public statuses. That gives developers and stakeholders a concrete record rather than an unsupported claim that the system is secure.
Why Hundreds of Millions in TVL Changes the Security Model
TVL is not proof of code quality, and it does not mean the entire amount is exposed to one contract or finding. It does change attacker incentives. A condition with narrow prerequisites may become worth researching when successful execution could affect a highly liquid system.
During the documented review window, HyperLend's public TVL rose from approximately $328.4 million to $362.4 million. The full public series shows a historical peak of approximately $673.6 million on September 12, 2025 and about $548.9 million in the latest August 2026 data available for this article. None of those figures supports describing HyperLend itself as a $1B+ TVL protocol.
At this scale, researchers consider transaction ordering, flash liquidity, multiple accounts, balance contamination, rounding, failed external calls, and the way one position interacts with account-wide debt. The scoped HyperLoop flow already uses flashloans by design, so atomic composition is part of normal operation rather than an exotic attacker capability.
TVL source: DeFiLlama HyperLend daily series retrieved August 29, 2026. Audit window: April 4–10, 2026. TVL describes the broader protocol, while Kann Audits reviewed five leveraged-lending and adapter files at commit 4f5deaf.
What Hyperliquid Ecosystem Builders Can Learn
As lending, vault, trading, collateral, liquidity, bridge, and structured-product infrastructure develops around Hyperliquid, security review cannot stop at checking individual Solidity functions. The economically important behavior often sits between the strategy, pool, oracle, swap venue, account model, and settlement path.
HyperLend's official architecture describes core pools, isolated pools, e-mode, flash loans, and risk from volatile collateral and failed liquidations. This engagement covered only the looping and strategy layer, but the same system-level discipline applies across the ecosystem: define what each component owns, which external state it trusts, and what must remain true across an atomic transaction.
- Define protocol and position-level invariants before deployment.
- Treat balance attribution, debt isolation, and cleanup paths as security-critical accounting.
- Model external integrations in success, refund, revert, and partial-completion states.
- Test account-wide state when a feature claims to isolate one strategy or position.
- Document acknowledged issues and re-evaluate them as integrations or capital exposure change.
- Use independent review before significant capital depends on a new execution path.
Challenge the Assumptions Before They Become Incidents
At hundreds of millions of dollars in TVL, security is no longer simply about avoiding coding mistakes. Every balance, callback, ownership record, and integration assumption becomes economically meaningful.
Our role as security researchers is to challenge those assumptions before an attacker has the incentive to do it first. That means being precise about what was reviewed, honest about what was found, and explicit about which issues were resolved or acknowledged.
The HyperLend engagement did not produce a dramatic Critical finding or a defensible claim that Kann Audits prevented a billion-dollar hack. It produced something more useful: a public technical record of a defined leveraged-lending scope, the behaviors researchers identified, and the status documented for each one.
Primary references