Felix feUSD (FEUSD)

Felix feUSD: How the Hyperliquid-Native Stablecoin System Works

Felix feUSD is an overcollateralized stablecoin created through collateralized debt positions on HyperEVM. Its design combines user-selected borrowing rates, permissionless redemptions, Stability Pool liquidations, external price feeds, and administrator-controlled risk parameters.

A collateral-backed dollar for the Felix ecosystem

feUSD is Felix’s native overcollateralized stablecoin. Users deposit eligible crypto assets into collateralized debt positions, called Troves, and mint feUSD against them. The token can then circulate to other wallets or be used across compatible applications, while the borrower remains responsible for repaying the debt plus accrued interest before withdrawing collateral. Felix’s documentation describes the system as non-custodial at the transaction level: assets are held by smart contracts rather than by the platform interface.

The project identifies the feUSD contract on HyperEVM as 0x02c6a2fa58cc01a18b8d9e00ea48d65e4df26c70. The documented collateral configuration has included WHYPE and UBTC, while Felix’s broader terms describe eligibility as parameter-dependent and subject to change. That means feUSD’s backing is not a static reserve basket: its composition depends on which collateral branches are active, their debt, their Stability Pool balances, and the risk settings applied to each branch.

Troves, interest rates, and redemptions

The core design is based on Liquity V2 but includes Felix-specific changes. A borrower chooses a fixed annual interest rate when opening a Trove, then borrows feUSD while keeping the position above the applicable minimum collateral ratio. The protocol orders Troves by their selected rates. When feUSD trades below its intended dollar value, a holder can redeem feUSD for approximately one dollar’s worth of collateral, less the applicable redemption fee. Redemptions begin with positions carrying the lowest interest rates, giving borrowers an incentive to price their debt with the risk of redemption in mind.

This mechanism is a protocol-enforced conversion route, not a promise that feUSD will always trade at one dollar on external markets. Its effectiveness depends on available collateral, functioning price feeds, sufficient transaction liquidity, and a redemption fee low enough for arbitrageurs to use the route. The code documentation also describes redemption routing across collateral branches according to relative uncovered debt, although temporary Stability Pool deposits may influence that routing and are listed as a known design risk.

The Stability Pool absorbs liquidations

When a Trove falls below its branch-specific liquidation threshold, anyone can call the liquidation function. The Stability Pool is intended to absorb the liquidated debt: feUSD deposited there is burned or offset against the borrower’s liability, while depositors receive a proportional share of the seized collateral. If the Stability Pool does not contain enough feUSD, the remaining debt and collateral can be redistributed among active Troves in the same branch. This makes Stability Pool depth a practical dependency for both solvency and liquidation efficiency.

Stability Pool accounting uses a product-sum method designed to track deposits, liquidation gains, and feUSD interest without updating every depositor after each event. Borrower interest is directed partly toward Stability Pool rewards, according to the project’s implementation documentation. Depositors therefore accept a different risk profile from ordinary stablecoin holders: their feUSD balance can be reduced during liquidations, and the collateral they receive may be volatile or difficult to sell during stressed markets.

Oracles and branch-level shutdowns

Collateral valuation is a central dependency. The Felix code documentation describes Chainlink-based price feeds and branch-level checks for reverted, zero, or stale oracle responses. If a feed fails verification, the relevant branch can be disabled, preventing new Troves and adjustments while still allowing selected actions such as closing positions, liquidations, and Stability Pool withdrawals. This is a circuit-breaker design rather than a guarantee against inaccurate prices before a failure is detected.

The repository also documents risks around oracle-update frontrunning, stale prices, thin collateral markets, and upward price manipulation that could allow excessive feUSD issuance. The practical exposure is therefore broader than the smart-contract code: it includes the quality and availability of collateral markets, Chainlink feed behavior, bridged-asset infrastructure, and the speed at which liquidators and redeemers can respond.

Control, upgrades, and the token’s actual role

feUSD itself is described in Felix’s terms as a settlement and liquidity token rather than a governance token. The documented system uses permissionless liquidation and redemption calls, but important operational control remains concentrated in administrator contracts. Felix’s repository describes an AdminController, proxy administration, mutable critical parameters, and an administrator-triggered shutdown function. The same materials describe timelocked parameter changes, while the audit page states that deployed contracts retain upgradability until administrator privileges are removed.

Felix lists audits and formal verification work for the Liquity V2 foundation, and separately says Felix-specific changes include mint caps, administrator-enabled Trove parameter adjustments, and protocol pausing. Those references are evidence that review work has been performed; they are not evidence that the deployed system is free of defects or has accumulated a long operating history. Newcomers should distinguish the audited upstream design from Felix’s deployed configuration and subsequent code changes.

Who feUSD is designed for

The main intended users are borrowers seeking dollar-denominated liquidity without selling collateral, Stability Pool depositors willing to absorb liquidation risk, and traders or applications that need a Hyperliquid-native settlement asset. Borrowers must monitor collateral ratios and interest-rate positioning; Stability Pool users must accept exposure to liquidation collateral; and external users depend on exchange liquidity and functioning redemption infrastructure. The system is therefore more specialized than a cash-equivalent stablecoin backed by custodial fiat reserves.

Key takeaways

• feUSD is minted against collateralized debt positions rather than issued against a conventional custodial cash reserve.
• Borrowers select fixed interest rates, and lower-rate positions are prioritized when users redeem feUSD for collateral.
• The Stability Pool absorbs liquidated debt but can expose depositors to losses in feUSD and volatile collateral.
• Chainlink price feeds, bridge infrastructure, collateral liquidity, and liquidator participation are material system dependencies.
• The token is described as a settlement and liquidity asset, not as a governance token.
• Felix-specific administrator and upgrade controls remain important to the system’s risk profile.

Risks and open questions

• Peg protection depends on profitable redemptions, external liquidity, available collateral, and functioning oracle infrastructure; none guarantees a continuous one-dollar market price.
• A collateral-market shock or bridge failure could impair backing, trigger liquidations, or make received collateral difficult to sell.
• Oracle staleness, update frontrunning, or price manipulation could affect borrowing, redemption, and liquidation outcomes before a shutdown is triggered.
• The repository documents proxy administration, mutable parameters, and administrator shutdown capability; the extent and timing of any future removal of these controls should be verified on-chain.
• Felix’s own documentation says the system has limited time in production and should not yet be treated as battle-tested.
• The deployed configuration may differ from the upstream Liquity V2 design and from earlier audit scope, especially where Felix added mint caps, pausing, or administrator-controlled changes.