Section 0: The Dark Forest of DeFi

DeFi has emerged as a pivotal innovation within crypto, with borrow-lend protocols and CDP stablecoins forming core components of on-chain financial infrastructure. We’ve seen that DeFi provides for more efficient software rails for finance, resulting in decreased costs, faster settlement, increased access, and more. However, these protocols face ongoing challenges related to security, particularly as adversarial actors develop new techniques to exploit vulnerabilities and siphon user assets.

In this article, we will explain some common smart contract vulnerabilities that are top of mind for the Felix team, including reentrancy, oracle manipulation, and private key leaks. Furthermore, we’ll provide a breakdown of our internal security process, highlighting all areas from formal contract reviews to ongoing monitoring Felix will boast on day one as we launch on HyperEVM. This article assumes that the reader is already somewhat familiar with DeFi money markets and CDP protocols.

Section 1: The Unmet Need for DeFi Protocol Security

DeFi is a “dark forest” - it can be a dangerous place for those who are uneducated and unprepared - both for users and project teams. The chart below from Hacken confirms that borrow/lend protocols are among the most targeted in crypto security breaches, with significant financial losses. In fact, these money market and CDP protocols account for a staggering $377 million in financial losses.

Despite the prevalence of such exploits, the current benchmark for protocol security continues to prove inadequate. Per Hacken, only 10% of the contracts that were exploited had undergone any form of audit, and even then, only half of these audits had full coverage of the deployed blockchain code, demonstrating the limitations of audits as a security measure.

Section 2: Common Exploits with CDP / Money Market Systems

Now that we have further emphasized the impending need for DeFi borrow/lend architecture that puts security first, we will explore the common exploit types in DeFi lending protocols that Felix is building to protect against.

Oracle price manipulation attacks:

A large number of exploits in lending protocols are associated with manipulation of collateral prices quoted by various oracles. Lending protocols use oracles to quote prices needed while assessing position solvency within the protocol. These oracles are often used as a vulnerability by attackers to exploit the protocol. The general concept of borrowing on lending protocols involves the concept of an LTV (Loan to Value). Whenever a user borrows, that user’s position has an LTV ratio. More often than not, user positions have to be over-collateralized, meaning that this value has to always be less than the maximum LTV allowed; if the LTV exceeds the maximum LTV allowed, a liquidation occurs. An attacker tries to exploit the protocol in one of two ways: either by artificially increasing the maximum permissible LTV so that the attacker can borrow more with the same collateral, thus fooling the protocol into believing that the collateral deposited is of higher value than it actually is, or by artificially decreasing the LTV of the attacker’s loan so they can still borrow more as the protocol is made to believe that the attacker’s LTV is still lower than the maximum permissible LTV (e.g. Cream Finance).

Attacks involving Flash Loans:

Flash loan attacks involve attackers borrowing large sums of money for a single block and wreaking havoc on protocol balances, as many protocols do not effectively account for very high amounts of liquidity. Ultimately, this results in misquotes, which enables exploit opportunities (e.g. Sonne Finance).

Attacks involving TWAP Oracles:

TWAP oracles, short for Time-Weighted Average Price oracles, are a type of oracle that calculates the average price of an asset over a specified period. Unlike instantaneous price oracles, which provide the current spot price, TWAP oracles mitigate price manipulation and volatility by averaging the price over time, often reducing the impact of sudden, short-term fluctuations. The price from a TWAP cannot be manipulated in one transaction or block. But being atomic is not a requirement for an attacker. TWAP is just a formula using on-chain sources, and it is a question of time and cost to attack TWAP (e.g. Inverse Finance).

Attacks involving Admin Controls:

Protocols often require privileged accounts—or “admin keys”—to perform upgrades, adjust parameters, or manage governance functions. If these privileges are compromised, an attacker may siphon user funds or redirect protocol flows to malicious contracts under the guise of legitimate updates (e.g. Radiant Capital). Hence, robust admin control measures are critical to safeguard users and the protocol itself.

Section 3: The Felix Philosophy and Approach to Security

Security, as demonstrated above, is a multifaceted problem. Now that we have examined a handful of the security vectors Felix is built to protect against, we will explore exactly how Felix is building the most robust borrowing suite on Hyperliquid.

The overarching philosophy Felix abides by is that security is not a one-time audit and forget. It is a constant, active process that requires perpetual monitoring and iteration. To do this continually at a high level week-in-week-out, we believe that security must be front and center to our entire product development process and cultural DNA. DeFi teams need to have the adequate personnel, the right leadership to instill security as a core value, and the right daily process to continually review and improve security processes.

What do protocol teams get wrong? Broadly speaking, they lose discipline and stop following stringent guidelines, engaging in the following behaviors:

• Changing the protocol code and not re-auditing the changes

• Using programming standards that haven’t been battle tested yet

• Improperly hosting private keys for admin controls

• Succumbing to phishing attacks on work devices

Next, let’s dive into how Felix’s pre-launch security focus is being implemented across the protocol and its contributor set.

Section 4: Pre-development

We believe that the foundation of a secure DeFi protocol begins before the first line of code is written. This approach has influenced both our team composition and our engineering decisions. For example, rather than following the common practice of building first and considering security later, we've assembled a team that includes smart contract auditors from the start to enforce sound practices in the development process, many of whom come from Three Sigma.

While many teams opt to build entirely new protocols from scratch, we recognized that this approach often introduces unnecessary security risks. We ultimately determined that the most effective path to creating a secure protocol would be to collaborate with the established Liquity team to bring their v2 protocol to Hyperliquid via an approved business license, implementing targeted modifications to address our specific use cases.

This decision offers certain key security advantages. First, we're building upon a codebase that has undergone four comprehensive security audits and relies heavily on the battle-tested smart contract logic of Liquity v1. Indeed, the Liquity team has accumulated expertise and experience in maintaining a 9-figure, and at once 10-figure, protocol. Secondly, this approach enables us to iterate on proven security measures while focusing on our specific modifications needed for the Hyperliquid ecosystem.

Section 5: Pre-launch security design

We break down our pre-launch security prep into four primary buckets: internal reviews, invariant testing, security audits, and admin opsec.

Internal Reviews

Felix implements a dual-team review structure to ensure comprehensive security coverage. We have those that focus on core protocol implementation, and others that focus on security reviews. This separation of concerns prevents single points of failure and ensures fresh perspectives on potential vulnerabilities.

Invariant Testing

Felix employs a comprehensive testing strategy that combines traditional unit testing with invariant testing approaches. Our unit tests verify specific functionalities, while our invariant tests using Foundry ensure that critical protocol properties remain true across all possible states.

Invariant testing is a powerful security technique that continuously verifies that certain properties of the protocol cannot be violated, no matter what sequence of actions are taken. For Felix, key invariants include:

• The total collateral in the system must always be greater than or equal to the sum of individual trove collateral

• No position can ever have an invalid state (e.g., negative collateral)

• The stability pool balance must always equal total depositor claims

• Redemptions must maintain system-wide collateral ratios

We leverage Foundry's powerful invariant testing capabilities to automatically generate thousands of random sequences of protocol interactions, checking that these properties hold true in every case.

Tier 1 External Security Reviews

The cornerstone of Felix's pre-launch security strategy lies in our comprehensive approach to third-party security reviews. We benefit from both Liquidity’s extensively audited V2 codebase as well as our own additional security measures specific to Felix's modifications.

The Liquity V2 codebase, which serves as Felix's base architecture, has undergone rigorous security validation through multiple independent channels. Four security firms have conducted thorough reviews of Liquity architecture:

• ChainSecurity has conducted a comprehensive smart contract audit

• Coinspect has provided an independent security assessment

• Dedaub has performed in-depth vulnerability analysis

• Recon has conducted additional security validation

While building upon Liquity's secure foundation, Felix has implemented four modifications to the V2 codebase:

• Implementation of mint caps to provide granular control over system leverage

• Addition of administrative trove parameter adjustment capabilities, primarily for mint cap management

• Integration of protocol-wide pause functionality for mitigating long-tail risk scenarios

• Implementation of new price feeds utilizing Hyperliquid’s Native Oracle as well as utilizing Pyth/Redstone as a fallback oracle

These modifications are currently undergoing dedicated security reviews by Dedaub and Coinspect, with audit reports that will be public in the Felix Docs. This additional layer of scrutiny ensures that our modifications maintain the same high security standards as the base protocol.

Admin Security

As mentioned previously, admin security has become a new area of protocol security attacks. While admin controls are necessary for protocol maintenance and upgrades, they also present risk vectors if compromised. To address this, Felix implements a multi-layered approach.

While we are still iterating on our design, we currently envision a two-fold admin control structure, each tailored to different operational needs:

• For emergency and critical actions, Felix employs a 5-of-9 multisig structure. This configuration provides exceptional security against compromise, as it would require either the collusion of five separate key holders or the compromise of five distinct keys to execute unauthorized actions. This structure is specifically designed to maintain security while still allowing for emergency response capabilities if some key holders become unavailable.

• For regular business operations and non-emergency protocol management, Felix implements a 3-of-9 multisig structure. This arrangement strikes a balance between maintaining strong security and enabling efficient protocol operations, allowing for necessary adjustments and updates without imposing excessive operational friction.

To ensure the integrity of these multisig systems, Felix has implemented strict operational requirements for all participants. These are the requirements at the moment:

• Hardware wallet requirements: All multisig participants must utilize physical hardware wallets for key storage and transaction signing, providing an additional layer of security against remote attacks.

• Transaction verification protocols: Participants are required to perform manual verification of all data payloads before signing, including comprehensive transaction simulation using Tenderly.

• Emergency response systems: Emergency multisig signers are integrated into a dedicated PagerDuty system, ensuring rapid notification and response capabilities for time-sensitive security events.

These measures are further strengthened by having key security personnel, including security researchers from Immunefi, to participate in both multisig structures, ensuring consistent security oversight across all protocol operations.

Section 6: Post-launch security design

Once Felix protocol has launched, top-tier risk and security monitoring will be implemented on Day 1 in order to ensure the consistency of the Felix security standard. More on this below.

Monitoring

Internally, we are leveraging Hypernative’s proactive monitoring technology on top of our own in-house monitoring. The Hypernative monitoring platform aims to detect exploits before they happen. It works by monitoring ~40 blockchains in real time, analyzing all transaction data (logs, traces). Hypernative classifies exploits using proprietary ML, analyzes the target, and issues an alert to pause the protocol and can even frontrun transactions in case of private key exploits. Hypernative actively monitors the state of the protocol, so if a hack is in its early stages, it can detect these dangerous behaviors before the damaging, “big” transactions are executed. Notably, they have detected exploits with Olympus DAO and Kinetic (not Kinetiq).

Furthermore, we are developing our own bots to monitor for liquidations and redemptions after each transaction. This means we can rely on a two-part infrastructure to ensure the economic integrity of Felix.

Bug Bounty

In addition to ongoing monitoring, Liquity maintains an expensive bug bounty program hosted on Hats Finance, which continues to accept submissions for both Liquity V1 and V2 codebases. This perpetual bug bounty ensures that potential vulnerabilities can be identified and addressed even after deployment.  The Felix team is exploring an additional bug bounty program along with the existing Liquity bug bounty program as well.

Section 7: Conclusion

Security on Felix is the number one focus of all Felix contributors. The reason for this: if it is not the number one focus, Felix will be a sure target given the demand for the protocol. With tactical, malicious organizations like Lazarus Group in North Korea and others constantly hunting for a vulnerable protocol, Felix security must be an iron wall against intrusion and a haven of protection for all Felix protocol users.