Looping Collective
About
Looping Collective is a DeFi yield protocol that transforms fragmented yield opportunities across HyperEVM into unified, tokenized assets. Its flagship product, loopedHYPE (LHYPE), is an automated looping vault that lets users deposit HYPE or stHYPE and receive LHYPE—a Liquid Looping Token that accrues staking rewards plus additional yield from a recursive staking strategy, all while remaining composable across the HyperEVM ecosystem.
Where Does Yield Come From?
LHYPE earns its yield through a strategy called AutoLoop — an automated process that repeatedly stakes, borrows, and re-stakes the same HYPE to multiply returns.
Here is how it works. When you deposit HYPE (or its staked version, stHYPE), the protocol takes the underlying HYPE and stakes it with a liquid staking service to get stHYPE. It then supplies that stHYPE into a lending market as collateral, borrows HYPE against it, stakes that borrowed HYPE again, and repeats the loop. Depending on current rates, this cycle runs 3 to 15 times.
The net yield comes from the difference (spread) between two things: the staking rewards earned on each loop and the interest costs of borrowing. Native HYPE network staking rewards also contribute. A Risk Curator adjusts the loop intensity daily to keep risk and reward in balance, and the system automatically reduces leverage if the loan-to-value ratio gets too high.
On top of staking yield, LHYPE automatically collects airdrops (called LoopDrops) from partner protocols involved in the strategy — such as staking, lending, and trading platforms. 100% of those airdrops are passed on to LHYPE holders, shared proportionally based on their LOOP points.
Fees: LHYPE charges a 10% performance fee on any yield it generates. From that fee, 10% is used to buy back $LOOP tokens on the open market as part of a Loyalty Rewards program. If you withdraw LHYPE to stHYPE, there is a small 0.04% withdrawal fee to discourage unnecessary arbitrage.
Finally, the protocol's $LOOP token uses a vesting system tied to TVL milestones — meaning new tokens are unlocked only as the protocol's total deposited value grows, linking dilution to real growth.
Persons
Dashan McCain
Lead Backend Engineer @paxoslabs
LinkedIn
Audits
| Audit / Date | Findings | Verdict |
|---|---|---|
0xmacro01-04-2024 - 05-04-2024 |
| No critical or high-severity vulnerabilities were found, and all medium-severity issues were addressed before the report was finalized, indicating a solid security posture for the BoringVault contracts, though residual trust assumptions around strategist roles and MEV exposure remain as documented design decisions. |
0xMacro22-04-2024 |
| The audit found no exploitable vulnerabilities, with only a single acknowledged Informational note about unverified third-party contracts; the scope-limited review does not introduce material risk to the protocol's security posture. |
Pashov Audit Group10-07-2024 - 13-07-2024 |
| The audit identified one critical-path issue (High severity) that was resolved before deployment, while the remaining Medium and Low findings were acknowledged but not fixed, leaving residual design risks in cross-chain bridge operations and asset handling. |
Pashov Audit Group29-07-2025 - 30-07-2025 |
| The audit found only three low-severity issues, all of which the team resolved; no critical, high, or medium vulnerabilities were identified, indicating that the reviewed contracts (HLPAccount, HLPController, CoreWriterDecoderAndSanitizer, WHLPDecoderAndSanitizer) have a strong security posture for their intended vault-management functionality. |
Pashov Audit Group14-12-2024 - 16-12-2024 |
| The three medium-severity findings highlight meaningful risks in the Hyperlane bridge integration (permanent message loss under pause, atomic deposit-bridge failures, and bypassed custom hooks), though all were either resolved or acknowledged by the Ion team; the five low-severity items represent minor edge cases and configuration concerns that do not materially threaten the protocol's core safety. |
Pashov Audit Group22-11-2025 - 26-11-2025 |
| The audit found no critical or high-severity issues, and the sole medium-risk finding (fee config in signature-based orders) was resolved, making the contracts reasonably safe for deployment. The 12 low-severity findings include acknowledged design limitations that teams should monitor in production but do not block launch. |
Pashov Audit Group04-03-2026 - 05-03-2026 |
| The audit identified one critical-path DoS attack (H-01) and a meaningful slippage bypass (M-01), both resolved, but the residual low-severity items (e.g., frozen-user deposits, supply-cap granularity) imply that governance and operational controls remain important for safety. |
Pashov Audit Group03-02-2026 - 05-02-2026 |
| The audit found no critical or high-severity vulnerabilities; all eight findings are low-severity, with two remediated and six acknowledged. The withdraw-queue codebase is low-risk, though the acknowledged items (notably double fee taxation and immediate fee changes) represent minor residual design concerns. |
Spearbit01-04-2024 - 12-04-2024 |
| The audit found no Critical or High-severity issues, and the eight Medium-risk findings were either fixed or acknowledged with compensating trust assumptions, indicating that the protocol can be deployed with reasonable safety given the intended multi-sig strategist setup and operational guardrails. |
Zenith14-11-2025 - 18-11-2025 |
| All critical and high-severity issues were verified as resolved, and the remaining medium-to-informational findings were either fixed or explicitly accepted as out-of-scope design decisions; the audit indicates that the in-scope contracts were sufficiently hardened before deployment. |
Zenith22-01-2026 - 27-01-2026 |
| The audit found no critical or high-risk issues; the two medium-severity findings were acknowledged by Paxos Labs as acceptable design trade-offs, and all informational and most low-severity findings were resolved, indicating a generally secure codebase with well-understood residual risks around queue processing and admin trust assumptions. |
ChainSecurity31-03-2025 - 08-05-2025 |
| One critical and four medium-severity issues were identified and fully resolved during the engagement, resulting in a codebase with a good level of security. However, the system's safety depends heavily on trusted off-chain actors (owner, fundsHolder multisig, and oracle curators), which is by design but represents a centralization risk. |
Omniscia24-08-2025 - 10-09-2025 |
| After three iterative revision cycles, all findings were fully consumed with no outstanding remediative actions, confirming the protocol is cleared for deployment with the three medium-severity items either remediated or acceptably acknowledged. |
Legal
Legal form
AG (Aktiengesellschaft — stock corporation)
Registration jurisdiction
Germany
Status and notes
Operating entity is Looping Collective AG, disclosed in the Terms of Service and Privacy Policy at app.loopingcollective.org/terms and app.loopingcollective.org/privacy respectively. Contact email: [email protected]. Terms state governing law is Germany; Privacy Policy states data is transferred to and processed in Germany. The main site footer shows "© 2026 Looping Collective" without legal form. A separate imprint page was not found. The GitBook documentation footer previously displayed "© 2025 Looping Association", which differs from the AG entity named in the legal documents.