Asset Risk Assessment: xETH & fETH
A dive into f(x) Protocol's dual-token model for adaptive ETH volatility exposure
Useful Links
Website: https://fx.aladdin.club/
Documentation: Docs | AladdinDAO Github | Whitepaper | Audits
Contracts: fETH | xETH | Deployment Addresses
Governance: Snapshot
Curve: fETH/crvUSD pool | xETH/ETH pool | fETH/FraxBP pool
Dashboard: DeFiLlama
Relation to Curve
f(x) is an ETH derivative protocol on Ethereum that uses a dual-token model to split volatility properties between the low volatility Fractional ETH (fETH) and the high volatility Leveraged ETH (xETH). fETH is set to follow a beta of 0.1 (i.e. its price would only change 10% compared to a change in ETH price). The other component, xETH, acts as a leveraged long ETH derivative that inherits the remaining volatility. The Net Asset Value (NAV) of fETH and xETH is equal to the total value of ETH deposited into the system.
AladdinDAO created two Curve pools paired with each protocol token (an fETH/crvUSD pool and an xETH/ETH pool) and proposed a liquidity gauge for each pool on Curve forums on August 21, 2023. Both gauges (vote 412, vote 413) were approved by the DAO shortly thereafter. A subsequent fETH/FraxBP pool was deployed and this pool was also approved for a gauge in vote 438.
The key motivations for adding gauges to these pools, according to the proposal, were:
Increase DEX liquidity and visibility for f(x) solutions
Validate fETH-stable pool parameters with deeper liquidity to ensure smooth deployment of further fETH-stable pools
An additional yield opportunity for fETH and xETH holders through LP farming
Potential governance benefits for CRV and CVX tokens through f(x) Protocol’s participation in bribe markets
Provide a boost in the use of decentralised stablecoins
F(x) Protocol
Overview
The f(x) Protocol, developed by Aladdin DAO, has the primary goal to offer a volatility-controlled asset for users with a lower risk appetite and a preference for hard money properties not susceptible to the eroding effects of inflation. It seeks to create a product that mitigates centralization risks and optimizes for capital efficiency.
In contrast to traditional stablecoins pegged to a fixed value of a reference asset, f(x) presents the concept of a “floating stablecoin”, called Fractional ETH (fETH). Rather than maintaining a peg to a secondary asset (e.g. USD), fETH’s value fluctuates as a fraction of ETH price volatility, ensuring improved stability across diverse market conditions while maintaining directional exposure to the underlying ETH.
To uphold stability, f(x) introduces a dual-token model that pairs fETH with Leveraged ETH (xETH), functioning as a leveraged long position on ETH without additional costs. This mechanism absorbs the majority of ETH price volatility and allows users to speculate on ETH price movements.
Users have the capability to directly mint and redeem fETH using stETH, eliminating the necessity for a USD reference. The treasury holds all reserves in the form of yield-bearing stETH. The protocol operates through Curve liquidity pools for fETH/crvUSD, fETH/FraxBP, and xETH/ETH with liquidity incentives paid in native FXN tokens.
FXN tokens are used for both governance and fee collection within the protocol. Those with vote-locked FXN (veFXN) earn a portion of the f(x) platform profits. veFXN enables participation in governance, with the amount of governance power dependent on the quantity and duration of the lock, as in veCRV tokenomics. The dual token utility promotes governance involvement and long-term engagement with the f(x) Protocol. Such incentives enhance sustainability and decentralization, aligning with Aladdin DAO’s overarching project philosophy.
f(x) Protocol Mechanics
The f(x) protocol allows users to deposit a variety of tokens, including ETH, stETH, USDC, or USDT, for creating low or high-volatility tokens (β tokens). By providing stETH, users can mint either fETH (with β set at 0.1) or xETH, with the amount received contingent on the price of ETH and the current value of each token. Users can also redeem their fETH or xETH for an equivalent value in stETH from the reserve at any time.
The f(x) Invariant:
The value of fETH and xETH tokens is dynamically tied to the price of ETH, ensuring that the combined value of all fETH and xETH tokens equals the total value of the ETH reserve. This relationship is expressed mathematically as:
Source: f(x) Docs
The quantity of ETH Collateral × ETH Price in USD = (Total Supply of fETH × NAV of fETH) + (Total Supply of xETH × NAV of xETH), where the net asset value (NAV) is the current mint/redemption value of fETH or xETH determined by the protocol.
The protocol algorithmically preserves the stability of fETH by adjusting its redemption value in response to ETH price changes, reflecting 10% (for β=0.1) of ETH’s return in the fETH price. Simultaneously, it adjusts the NAV of xETH by a greater magnitude than the ETH return to maintain the f(x) invariant. This strategy allows xETH to offer leveraged ETH returns without incurring funding costs, while fETH maintains low volatility.
Collateralization Ratio
To ensure the proper functioning and stability of fETH’s value within the f(x) system, a sufficient supply of xETH is crucial. Conceptually, the entire f(x) system operates as a large collateralized debt position (CDP), with the total ETH in reserve serving as collateral and the fETH supply representing the borrowed amount. The xETH supply represents the variance between the provided collateral and the total borrowed amount.
The health of the system is evaluated akin to a conventional CDP, utilizing a collateralization ratio (CR), also called a health factor. In simple terms, the system necessitates a CR exceeding 100% to maintain its adaptive volatility property. For the f(x) system, this ratio is computed as the treasury TVL divided by the Net Asset Value (NAV) of fETH.
Source: Whitepaper, pg. 6
Minting and redeeming fETH/xETH tokens influence this collateralization ratio. A drop in the system’s collateralization ratio to 100% implies a zero NAV for xETH. Although fETH remains available for minting and redemption, its β value rises to 1, forfeiting its low volatility property.
xETH and fETH Dynamics
The effective leverage of the xETH token fluctuates over time, based on changes in the relative supplies of xETH and fETH as a result of minting and redemption. An increase in xETH relative to fETH decreases the effective leverage for xETH, distributing volatility absorbed from fETH across more tokens. The effective leverage is inversely related to the system CR, which is equal to the value of ETH in the system / the value of outstanding fETH (i.e. as the proportion of fETH in the system increases, xETH leverage increases).
Shown below is the overall treasury TVL over time and the relative balance between fETH and xETH minted by users:
Observe in the query below that the effective xETH leverage has oscillated in response to system CR between 1.93x and 3.27x, currently at 2.1x as of November 8:
The ability to mint fETH is primarily determined by the availability of xETH, which must be in sufficient supply to absorb the volatility of all outstanding fETH. Even a small amount of xETH can support a large supply of fETH due to potential changes in xETH leverage, although the effective leverage of xETH may increase substantially in such a scenario. Minting fETH does not impact its price, and it can be done with low fees, limited only by the available xETH supply. In other words, the availability of fETH is dependent on the demand for ETH leverage.
The query below shows the max mintable quantity of fETH before triggering stability mode (under 130% CR) as the total value in the system and the relative proportion of fETH:xETH changes over time. On November 7, the max mintable fETH before triggering stability mode was 6,248,563 with a 3,706,630 total supply, or 2.68x the current fETH supply.
Likewise, the query below shows the max redeemable quantity of xETH before triggering stability mode as the total value in the system and the relative proportion of fETH:xETH changes over time. On November 7, the max redeemable xETH before triggering stability mode was 2,071,322 of a 3,300,025 supply or 62.76% of the xETH supply.
CR Protection Mechanisms
Should the CR approach a point jeopardizing β = 0.1, f(x) implements protective measures. If a sufficiently large quantiy of fETH is minted and/or a sufficiently large quantity of xETH is redeemed to drop the system CR below 130% (the parameter defined in the stabilityRatio of the Market contract), Stability Mode will initiate.
The activation of these protective measures is contingent on the probability of a significant one-day drop in ETH’s price, set by the team to be equivalent to a 25% drop in a single day (a 0.10% probability). The team settled on a 25% drop scenario to design the system such that it can tolerate even a maximum historical drop in ETH price. This trigger corresponds to a CR of 130%, indicating that if the protocol’s CR falls below 130%, protective mechanisms must be activated.
When the system CR drops below 130% i.e. xETH leverage of ~3.946 (this can be verified from the image below), the system can withstand an ETH price drop of 25% in a single day. Note the exponential expansion of xETH effective leverage as the CR approaches 100%:
Stability Mode
To restore the CR of the system, it is essential to decrease outstanding fETH or to increase the outstanding xETH supply. Failure to achieve this adjustment would result in a highly leveraged system that, in the extreme case, would negate fETH’s low volatility property.
Stability mode, activated after breaching a 130% CR, causes the following changes to the protocol with the intention of increasing xETH and decreasing fETH:
Minting fETH is disabled.
Redemption fees for fETH are waived.
Minting fees for xETH are waived.
Redemption fees for xETH are increased.
Rebalance Pool
To actively reinforce the CR, the protocol employs a dynamic strategy of redeeming fETH tokens from a dedicated pool, aptly named the Rebalance Pool. This is a modified version of Liquity’s Stability Pool.
The Rebalance Pool allows fETH holders to deposit their tokens. In return, they earn a share of the staking yield generated by the reserve’s stETH. Moreover, the protocol can amplify rewards in this pool by issuing its native governance token as a liquidity incentive.
If the system CR drops below 130%, the pool’s fETH holdings are exchanged for stETH and burned, improving the system CR. Users may experience their fETH holdings decrease and stETH holding increase while deposited in the Rebalance Pool.
Ensuring robust liquidity in this pool is vital, as it guarantees the protocol sufficient management of the fETH supply and serves to fortify the system’s CR. To prevent rapid withdrawals at critical times, the contract includes an unlockDuration, a delay on withdrawals from the contract, which is currently set to 24 hours.
Reserve Pool
In scenarios of persistent or severe downward pressure on the CR that depletes the Rebalance Pool’s fETH supply, the protocol activates a stabilization mechanism funded by the Reserve Pool. xETH minting incentives are activated that deploys stETH reserves in the pool as incentives for users to mint xETH.
The Reserve Pool is funded from a portion of the protocol revenue. 25% of mint/redeem fees are directed to this pool while the other 75% are distributed to veFXN holders.
FXN Raise
As a last line of defense, in case no other backstop mechanism adequately supports the system CR, the protocol is able to issue FXN governance tokens that can be used to raise ETH for recapitalization. The process would be managed by the team multisig, using ETH raised to mint xETH tokens and/or acquire and redeem fETH tokens to restore a healthy CR ratio.
Future CR Protection
The f(x) system is still in beta and there are additional protection mechanisms being developed. Here is a summary of current mechanisms and planned future mechanisms:
Existing risk management mechanisms
Rebalance pool earns LSD yield and redeems into stETH when CR <130%
xETH mint incentives when CR <130%
Future risk management mechanisms
Rebalance pool A earns LSD yield and redeems fETH into stETH when CR <130%
Rebalance pool B earns LSD yield and redeems fETH into xETH when CR <130%
xETH mint incentives when CR <130%
fETH redeem incentives when CR <130%
Fees and Revenue
Below is an overview of the protocol fee and revenue model:
The protocol Treasury contract holds protocol reserves as yield-bearing stETH. The protocol retains all staking yield from its reserves as protocol revenue. The stabilityPoolRatio specifies how much is directed as a reward incentive to users that deposit fETH in the Rebalance Pool vs how much is directed to the team platform (set as PlatformFeeSplitter). The value is currently set at 99% to the Rebalance Pool. There is also a 1% harvester reward.
The f(x) protocol also applies a fee when minting or redeeming fETH/xETH tokens. The specific fees depend on whether the system is operating under normal conditions or in Stability Mode (when the system CR is below 130%). These fees accrue to the PlatformFeeSplitter contract.
Fees accrued to the PlatformFeeSplitter are redistributed in a 75:25 ratio between veFXN tokenholders and the treasury (set to the ReservePool contract) as can be seen when querying rewards. The ReservePool maintains a backstop fund used to protect the protocol CR if it drops to unsafe levels.
The protocol is currently in beta and has not officially begun revenue distribution. There is a stETH to wstETH converter contract in progress. After deployment, revenue distribution is intended to begin.
Smart Contract Architecture
The f(x) system is composed of a number of specialized contracts that perform specific functions within the system. The core system contracts are upgradeable proxies with helper contract addresses stored within them which can be updated by the contract owner.
Across the system, the Aladdin DAO 6-of-9 multisig has ownership privileges. An overview of access controls for each contract is described below, but generally, the owner controls critical functionality including upgrading contracts and setting system parameters.
In addition to the contract owner, some contracts include additional privileged roles. The Market contract has an EMERGENCY_DAO_ROLE (set to the same multisig as the owner) that can pause the system mints/redeems. The RebalancePool has a liquidator role previously assigned to an EOA address but recently reassigned to a permissionless liquidation contract. The PlatformFeeSplitter contract has a staker role set to an EOA address.
The significant contracts are described below, but Aladdin DAO also outlines all mainnet deployment addresses on their GitHub.
Market
Contract: Etherscan
The Market contract is an upgradeable proxy. It is a critical part of the f(x) system that users interact with for minting and redeeming fETH and xETH. The contract stores fee and incentive parameters that are configurable by the contract admin. It has logic to change parameters in case of Stability Mode, allows pausing of mint/redeem operations, and has a liquidation mechanism that gives incentives for redeeming fETH in case of Stability Mode.
The DEFAULT_ADMIN_ROLE controls most critical access controls, including contract upgrades, parameter settings, and updating other system addresses stored in the contract. There is also an EMERGENCY_DAO_ROLE that can pause all mint/redeems and toggle pause fToken mint/xToken redeem during Stability Mode.
stETHTreasury
Contract: Etherscan
stETHTreasury is an upgradeable proxy. It holds the stETH received from user deposits. Staking rewards can be permissionlessly claimed by calling harvest, with a configurable ratio of the harvest rewards sent to the protocol owner, the RebalancePool, and the harvester.
The contract owner can change the harvest ratio, update system contracts stored in the contract, and change other parameters such as the max stETH deposited into the contract.
FxEthTwapOracle
Contract: Etherscan
The stETHTreasury contract specifies the FxEthTwapOracle as a price oracle that it uses to initialize price and in case of protocol settlement. It sources price data from the Chainlink ETH/USD and stETH/USD feeds and from the Curve stETH/ETH-ng pool EMA oracle. Chainlink prices are quoted as 30m TWAP.
The contract will quote the price of the Curve EMA multiplied by the Chainlink ETH/USD feed and bounded by certain criteria. The price is only valid if the Chainlink feeds are within 1% deviation and the Curve EMA returns between .99 and 1.01. Furthermore, the safePrice cannot be less than the minimum of either Chainlink feed or greater than the maximum of either Chainlink feed.
In case stETH is quoted as depegged over 1% from ETH, the system will do the following to protect f(x) Protocol from stETH depeg risk:
f(x) mint transactions are disabled
fETH redeem transactions will be done based on max (Chainlink ETH/USD, Chainlink stETH/USD, Curve stETH/USD)
xETH redeem transactions will be done based on min (Chainlink ETH/USD, Chainlink stETH/USD, Curve stETH/USD)
RebalancePool
Contract: Etherscan
RebalancePool is an upgradeable proxy. fETH holders can deposit into the pool to earn a share of protocol fees (currently 99% of stETHTreasury yield and possibly FXN inflation in the future). There is a configurable unlockDuration (set at 1 day) whereby the user calls unlock to begin cooldown and withdrawUnlocked to withdraw.
In the events where the system CR is below the liquidatableCollateralRatio, an equivalent amount of fETH in the RebalancePool is burned and redeemed in exchange for stETH from the Treasury, thereby offsetting the debt incurred by the liquidated treasury. The proportion of a stability depositor’s current deposit in relation to the total fETH in the pool determines the share of collateral they receive through the liquidation process.
There is a contract owner that can set parameters like the liquidatableCollateralRatio and unlockDuration. It can also add/remove/update rewards tokens and set a liquidator address. The liquidator is a privileged role that can call liquidate. The address was previously set to a team-controlled EOA as part of a beta rollout, although recently was reassigned to a permissionless RebalanceWithBonusToken contract.
PlatformFeeSplitter
Contract: Etherscan
The PlatformFeeSplitter collects protocol mint/redeem fees and facilitates the distribution of rewards among various stakeholders. It allows for the allocation of tokens to addresses specified as ecosystem, staker, treasury, and veFXN lockers with ratios configured by the contract owner. These addresses are set to the team multisig, an EOA address, the ReservePool contract, and veFXN respectively. Rewards are set to distribute 25% to the reserve pool and 75% to veFXN lockers. The staker role reserves the ability to incentivize gauges in the future and is set to 0% currently.
The contract owner can update addresses for fee recipients, add/remove reward tokens, and change the ratio of fee distribution. The staker can call claim to distribute fees from the contract and is set to an EOA address.
ReservePool
Contract: Etherscan
This contract stores a portion of the protocol’s fee income (set at 25% of mint/redeem fees). When the protocol’s CR falls below the stability threshold (set at 130%), the keeper triggers an incentive mechanism, allowing users to receive additional rewards when minting xETH (set at 5%). The primary purpose of the contract is to facilitate the bonus distribution process.
Contract administrators have control over the bonus ratios and can withdraw the remaining assets from the contract.
fETH
Contract: Etherscan
The fETH token contract is a core component of the f(x) system. fETH NAV is managed in the contract, and they can be minted or burned by the Treasury contract. The NAV of fETH is set and updated via the Treasury contract.
xETH
Contract: Etherscan
The xETH contract is a core component of the f(x) system. The Treasury contract manages xETH minting and NAV calculation. The leveraged tokens can be minted and burned by the Treasury contract, as part of a mechanism for managing leverage exposure to the underlying asset.
fxGateway
Contract: Etherscan
The FxGateway contract serves as a versatile gateway for users to mint and redeem system tokens. Although the treasury holds only stETH, users can deposit a number of tokens that zap into the target token. Users can mint/redeem fTokens and xTokens and perform token swaps. It includes safeguards to control interactions with target contracts and handles token transfers and refunds.
Future Contract Releases
The f(x) team has conveyed plans to implement additional contracts after conducting a 4th audit report. Points 1, 2, and 6 below were advised by Convex as part of its support for the f(x) protocol:
New gauge structure that supports veFXN boosting proxy (delegate and share)
Double gauge farming (LPs can simultaneously earn rewards from Curve and FXN gauge)
RebalancePoolBsupporting fETH to be redeemed to xETH when CR <130%Vesting contract for wrapped FXN that earns rewards while vesting
fETH redemption incentives when CR <130%
stETH converts to wstETH for revenue distribution
Once the stETH to wstETH revenue converter contract has been deployed and revenue distribution initiated, all revenue, including LSD yields, will be streamed to the PlatformFeeSplitter contract.
Risk Vectors
Smart Contract Risk
Smart contract risks are a constant threat to every DeFi project, although audits and bounty programs can reduce the risk of user funds losses from smart contract exploits.
Audits
f(x) Protocol has undergone 3 audits to date (as of October 2023) and a 4th audit is planned for additional contracts with functionality to help reinforce the system Collateral Ratio and to improve rewards and revenue distribution.
Below are a few points (with contingency plan) in the audits that are still relevant and are labeled as ‘discussed’:
Issues concerning incentivization mechanism to restore system CR
4.3.3 Discuss the additional stETH token incentive logic when users mint xETH tokens.
Source: Audit - SECBIT_f(x)_Protocol_Update_Report_v1.1
To address the issue pointed out in the audit, the team needs to control a parameter bonusRatio and set it to ‘0’ to prevent users from receiving unintentional bonus rewards while minting xETH.
The team is developing a stability mechanism that involves incentivizing fETH redemption. This new stability mechanism is planned for audit at the time of writing this report.
The system can currently incentivize xETH minting when CR <130% and the Rebalance Pool has capital in it. After the next upgrade, the system will only incentivize xETH minting when CR <130% and Rebalance Pool capital is exhausted. bonusRatio is the incentives % paid for xETH minting.
4.3.4 Potential flash loan attack to siphon system rewards.
Source: Audit - SECBIT_f(x)_Protocol_Report_v1.0
There can be an attack vector where someone mints fETH to draw the system CR lower than 130% which will trigger the incentives for minting xETH. An attacker would then mint xETH by depositing stETH or ETH, availing the incentives and pushing the CR to 130%. Now he would burn/redeem the fETH to get stETH and push the system CR over 130%. They would then redeem the xETH to retain profits equal to the extra mint incentives. These steps can be repeated recursively to siphon the incentives.
The above attack is only possible when the incentives are greater than the fees incurred from minting and redemption fees for fETH and xETH. At 8% redemption fees for xETH and a 5% incentive rate, the attack is no longer economical.
4.3.5 Potential flash loan attacks to seize the system’s liquidation rewards.
Source: Audit - SECBIT_f(x)_Protocol_Report_v1.0
This was a former implementation that was revised. The team has dropped the idea of incentivizing the liquidations and set the liquidation rewards to 0. This can be noticed in the latest audit in section 4.3.6 The liquidate() function may potentially fail.
The risk management mechanisms in production at this time when stability mode is on:
1 Disable fETH minting
2 Fee adjustment for fETH/xETH mint/redeem
3 fETH can be liquidated for treasury stETH from the Rebalance pool
4 Minting incentives for xETH (Incentives comes from revenue reserve i.e. 25% of the protocol mint/redeem fees).
Issue concerning the withdrawal from RebalancePool
With the current RebalancePool design, a user can deposit fETH, entitling them to a share of stETH yield. The user can initiate their exit from the pool at any time, but there is a mandatory timelock before they can withdraw their fETH capital. The current unlock duration is set to 1 day, meaning you need to wait for 1 day before you can withdraw your fETH from the Rebalance Pool. This parameter was recently changed from 14 days to 1 day.
The audit found unexpected contract behavior in case a user initiates multiple withdrawal requests:
In the current implementation, users cannot initiate multiple principal withdrawal requests simultaneously. When a user initiates a principal withdrawal request, the funds are locked for an unlock duration period. If the user initiates a new principal withdrawal request before the lock period has expired, the unlock duration will be recalculated. Consequently, the unlocking of the first deposit will be delayed, eventually coinciding with the unlocking of the second deposit. In the worst-case scenario, if a user initiates multiple requests to unlock funds during the lockout period, the fund unlocking will be continually delayed, resulting in a significant delay.
Source: Audit - SECBIT_f(x)_Protocol_RebalancePool_Report_v1.2
Bug Bounty Program
Aladdin DAO has an active bug bounty program that encompasses all smart contracts related to its constituent products, including f(x). Details about the program are available in the protocol docs, which offers a maximum bounty of $500,000 for responsible disclosure of bugs identified as critical.
Legal Risk
The ownership structure and legal entities associated with the f(x) Protocol are not explicitly detailed on fx.aladdin.club. There is discussion about setting up a legal structure for Aladdin DAO, which may be related, on their forum. Another source mentions Aladdin DAO as an example of a Service DAO alongside others like MetaFactory and Yam DAO. However, it doesn’t provide detailed information on the DAO legal structure (if any).
The protocol is not confined to the regulatory framework of any single country as it functions in a decentralized manner. There are no established ties to a specific jurisdiction where the DAO or associated entities are situated. The legal classification of tokens has neither been proactively pursued by the team nor challenged by regulatory authorities.
The frontend lacks a comprehensive set of Terms of Use/Terms and Conditions, which are crucial to delineate user eligibility, access rights, restrictions, and to expressly outline the respective rights and responsibilities of the parties. We observed no adherence to the common practice of integrating disclaimers and limitation of liability clauses in such terms to minimize the potential risk exposure for the platform operator. Legal risks may arise from inadequate protection of retail holders (e.g. risk warnings, information about the token and underlying technology, etc.). A user who incurs losses might argue that they were not aware of the potential risks due to the platform’s omission, increasing the platform’s liability.
There is no public information or documentation regarding enforcement actions against fx.aladdin.club, Aladdin DAO, or any affiliated organizations.
The frontend interface communicates a cautionary notice to individuals who are citizens or residents of countries subject to OFAC sanctions or of the United States. Such individuals are expressly prohibited from utilizing the protocol in any manner. An unequivocal certification from the user, confirming their status in relation to these jurisdictions, is mandatory before proceeding.
Economic Risk
Maintaining an adequate system collateralization ratio (CR) is essential to the proper operation of the protocol. This depends on regulating the relative supply of fETH and xETH, in particular, to ensure there is sufficient xETH to absorb the volatility of the outstanding fETH. The target system CR range is 130%-200% (approx. 2-4x leverage).
Since the availability of fETH minting and the system CR is dependent on xETH, there is an assumption of sustained demand for ETH leverage. The f(x) whitepaper (pg.5-6) points out that the ETH funding rate has been overwhelmingly positive, indicating that there has historically been outsized demand for ETH leverage longs. This may not always be the case, in which case a sharp drop in leverage demand could threaten the protocol’s ability to absorb fETH volatility.
xETH effective leverage is dynamic and moves inversely to the CR. The whitepaper (pg.8-9) shows that during normal operation, leverage should range between 1x-4x, depending on system CR. When system CR drops below the point of Stability Mode, leverage rapidly increases. Theoretically, an event that reduces demand for leverage longs together with exponentially increasing leverage exposure could cause all outstanding xETH to be redeemed. This would reduce CR to 100% and the outstanding fETH would no longer maintain its volatility-dampening property, and instead would simply track the price of ETH.
An essential component to regulating the CR is the Rebalance pool. fETH tends to exit the Rebalance pool when the market gets bullish. As fETH leaves the pool, yield for depositors will rise. When the market becomes bearish, fETH tends to flow back to the Rebalance pool. However, there may be scenarios where incentives are not strong enough to attract sufficient capital to the Rebalance pool, which could inhibit the protocol’s ability to stabilize the system CR.
Collateralization Support Mechanisms
There are several mechanisms in place to support healthy CR levels that may protect against the economic risk to protocol operation.
As described previously, Stability Mode is activated when the collateral ratio of the system drops below 130% (130.55% to be precise). You can check the current stability mode activation threshold by querying marketConfig here. (Note: There are a few more ratios listed under marketConfig like liquidationRatio, selfLiquidationRatio, and recapRatio. These have no significance as they were a part of Stability Mode in their earlier release.)
In Stability Mode, to recover the system CR, the fee structure for minting and redemption of fETH and xETH are altered. Rates are favorable for users to redeem fETH and mint xETH to improve system CR.
Furthermore, the RebalancePool plays an active role in improving system CR. RebalancePool would be used to increase the collateral share backing the xETH supply by redeeming user-deposited fETH in the pool for stETH. Ensuring robust liquidity in this pool is vital, as it guarantees the protocol sufficient access to fETH to attempt recovery. RebalancePool is incentivized via the stETH yield earned by the stETH stored in the treasury. Failure to incentivize this pool can deteriorate the recovery potential from fETH redemption. Therefore a portion of protocol fees (and possibly native FXN tokens in the future) are directed to fETH stakers to provide deep liquidity in the pool.
A portion of the funds used to mint/redeem fETH and xETH are directed to the ReservePool. In Stability Mode, a keeper triggers an incentive mechanism, allowing users to receive additional rewards when redeeming fTokens (set at 5%). The funds in the ReservePool will become available as incentives for users to improve the system CR.
In case no other lever can successfully bring the system to a healthy CR, FXN governance tokens can be minted as part of a raise to accumulate ETH that would be used to buy back and redeem fETH and/or mint xETH.
Custody Risk
The protocol design involves ownership privileges that control critical system components. Aside from the owner, there is an emergency DAO role that only governs emergency functions. Both of these roles and the addresses operating them are described below.
There is no governance structure in place right now for the f(x) protocol. The team uses Aladdin DAO and CLever Snapshot to govern the system until they launch the veFXN token. They have expressed the intention to migrate to on-chain governance in the near future, although there does not appear to be a clear timeline for this.
Protocol Owner
The protocol owner is responsible for most critical operations which include updates to contract addresses and system parameter changes. This owner is set to a 6-of-9 multisig with signers disclosed on the deployments GitHub page. Most signers are anonymous contributors to f(x).
Owner: 6-of-9 f(x) Protocol Multisig
The protocol owner can control the following functions across system contracts:
Upgrade contract implementations
Update mint/redeem fees in Market
Update market and incentive configurations in Market
Update system addresses stored in the contract
Grant/revoke privileged address roles
Transfer ownership
Set a cap on stETH in the treasury
Change the harvest ratio in the treasury
Set liquidatable collateral ratio in RebalancePool
Set unlock duration in RebalancePool
Add/remove reward tokens in RebalancePool
Update addresses of fee recipients in PlatformFeeSplitter
Change the ratio of fee distribution among recipients in PlatformFeeSplitter
Add/remove reward tokens in PlatformFeeSplitter
Update bonus ratio (incentive bonus in Stability Mode) in ReserveFund
Withdraw tokens in the ReserveFund to any address
Emergency DAO
The emergency DAO role is in the Market contract. It is responsible for pausing the system in case of emergency. The emergency DAO is set to the same multisig as described above.
The emergency DAO can control the following functions in the Market contract:
Universally pause mints
Universally pause redeems
Toggle pause fETH mints when in Stability Mode
Toggle pause xETH redeem when in Stability Mode
Oracle Risk
The f(x) protocol uses a custom FxEthTwapOracle contract that is used during mint/redeem actions. It sources price data from
Chainlink ETH/USD (30-minute TWAP)
Chainlink stETH/USD (30-minute TWAP)
Curve stETH/ETH-ng pool EMA oracle.
In normal operation, the contract will return a value for stETH denominated in USD calculated as:
ABS((Chainlink ETH/USD - stETH/USD) / stETH/USD) < 1% OR 99% < (Curve ETH/stETH) < 101%
In case stETH is quoted as depegged over 1% from ETH, the system will do the following to protect f(x) Protocol from stETH depeg risk:
f(x) mint transactions are disabled
fETH redeem transactions will be done based on max (Chainlink ETH/USD, Chainlink stETH/USD, Curve stETH/USD)
xETH redeem transactions will be done based on min (Chainlink ETH/USD, Chainlink stETH/USD, Curve stETH/USD)
The Chainlink feeds can be considered highly secure, having operated reliably on mainnet for several years in occasionally severe market situations and operating with a network of independent nodes (19 nodes for stETH and 31 nodes for ETH). The Curve EMA oracle is relatively new and has undergone several iterations and audits. This oracle has less maturity, although we consider it reasonably reliable.
Dependence on the continued reliable performance of the oracles is essential for the operation of the protocol. In case of faulty oracle data, the protocol operation may be disrupted and/or may result in losses to the protocol, affecting fETH and xETH tokenholders.
Depeg Risk
There are two assets from the f(x) protocol, each with a dedicated Curve pool. fETH, paired with crvUSD, is a low volatility derivative of ETH initiated with a $1 price point. xETH is a leveraged derivative of ETH that is paired with ETH. Both pools are crypto V2 pools, meaning they concentrate liquidity around an internal oracle price and periodically rebalance liquidity concentration as prices move. fETH is set with parameters suggested by Curve for use with low volatility pairs and xETH is set with parameters suitable for higher volatility assets.
See the query below for the relative volatility of stETH vs fETH vs xETH:
fETH/crvUSD
fETH/crvUSD is a crypto V2 pair, which is suitable for asset pairings that do not keep a stable peg. As long as fETH volatility holds the peg to ETH with a beta of 0.1, the fETH/crvUSD would perform as a low-volatility, unpegged asset pair. As fETH is linked (dedicated volatility function that can be changed) to 0.1 beta and is readily redeemable for underlying stETH in normal operation, the only way fETH risks a substantial depeg from ETH at 0.1 beta is if the protocol becomes undercollateralized or an emergency situation requires pausing mints/redemptions.
xETH/ETH
xETH/ETH is also a crypto V2 pair. An LP participating in this pool should be aware that they would be exposed to the price fluctuations from ETH as well as xETH. As xETH is a leveraged derivative of ETH, during times of high volatility it is expected that xETH exhibits pronounced price changes, potentially exposing LPs to impermanent loss.
xETH also has the property of being dynamically leveraged. The variability of the leverage depends on the amount of fETH supply and xETH supply. For example, if there is an extensive supply of xETH and a marginal supply of fETH, the swings in xETH would be at low leverage compared to a case where the supply of fETH is extensive and the supply of xETH is marginal.
Moreover, the leverage mechanism is designed with the expectation that there is only a 0.1% chance that the ETH price would drop more than 25% in a day and unless the system is at 130.55% CR at that moment, there will be enough funds to back both the assets.
Collateral Risk
f(x) Protocol converts all the ETH deposited into the system to stETH, which is held in the protocol treasury. The protocol and holders of both the fETH and xETH tokens depend on stETH to keep its peg with ETH.
stETH is a Liquid Staking Derivative (LSD) offered by Lido, a decentralized protocol operated by a set of whitelisted ETH staking node operators. It is the preeminent LSD available, having held over 70% market dominance since its inception.
We have previously conducted a full review of stETH for Prisma Finance’s collateral onboarding, in which we found stETH to have the strongest risk profile of all available LSD tokens. An overview of our ranking is below, and readers can refer to our Collateral Risk Assessment - wstETH for more details.
Based on the risks identified for each category, the following chart summarizes a risk rating for wstETH as collateral. The rating for each category is ranked from excellent, good, ok, and poor.
We rank wstETH excellent on liquidity for being the clear market leader with deepest liquidity.
We rank wstETH ok in volatility due to multiple depeg events pre-Shanghai and a high level of uncertainty about withdrawal processing, which may inhibit arbitrage.
We rank wstETH good in smart contracts for being heavily audited, having a bug bounty program, and having a long history securing billions in TVL without major incident. The recent upgrade to V2 increases smart contract uncertainty.
We rank wstETH good in dependencies for having a reliable pricefeed available. Dependency of lido oracle daemons can result in disruptions that can cause incorrect reward distribution or liquidity mismanagement.
We rank wstETH good in centralization for having core system controls with a DAO that has reasonable backstop measures. Multiple multisigs are employed with limited privileges for specific precautionary functions.
We rank wstETH good in legal for having no enforcement actions historically, Lido limits liability in their terms and conditions and decentralization is sufficient that legal action is unlikely to disrupt the network. A concentration of NOs in Europe increases vulnerability in those jurisdictions.
Source
All LSD assets involve additional sets of risks beyond exposure to ETH which include smart contract risk, trust assumptions with node operators, and management of on-chain operations. There may be legal risks and centralization vectors involved in the operation of the LSD protocol, and failures in any of these factors can lead to partial or total loss to holders of the LSD token.
LlamaRisk Gauge Criteria
Centralization Factors
1. Is it possible for a single entity to rug its users?
Yes. The protocol owner has the power to upgrade system contracts, including the protocol treasury. If the protocol owner were to be malicious or compromised, it is possible to rug the protocol. The owner is set to a 6-of-9 multisig composed of both core team and community members, so the risk of a rugpull seems reasonably mitigated.
2. If the team vanishes, can the project continue?
No. The owner multisig holds the power to influence fees, incentive structures, and other critical functions that directly impact the behavior of the protocol when the system collateral ratio is less than 130%. Ownership is planned to be transferred to a DAO of tokenholders in the near future.
Economic Factors
3. Does the project’s viability depend on additional incentives?
Somewhat. The system depends on the demand for leverage long ETH (xETH). Since the protocol socializes its CR, all users are exposed to the risk that there may not always be organic demand for leverage. In such cases, the protocol may depend on extra incentives, either on its primary market or within the Curve pools, to drive extra demand and maintain system stability.
4. If demand falls to 0 tomorrow, can all users be made whole?
Yes. The f(x) Protocol should be in a position to make all users whole with stETH in their treasury during normal operation. The redemption order does matter because if all users redeem xETH first, the system may enter Stability Mode. This greatly increases xETH redemption fees, as the protocol attempts to disincentivize further redemption. If users redeem all fETH before redeeming xETH, everyone can be made whole with minimal losses.
Security Factors
5. Do audits reveal any concerning signs?
The protocol has undergone 3 audits and has a 4th in progress with additional updates to the system. The protocol is still in beta with a cap on deposits and adjustments to be made to its collateralization protection system. Audits suggest the f(x) team is committed to responsible security practices, but that the protocol has not yet reached a mature state.
Risk Team Recommendation
f(x) Protocol is the newest addition to the family of Curve-focused products by Aladdin DAO that also includes Concentrator and CLever. The previous history of the team inspires confidence in their ability to build complex products that have thus far shown themselves to be sustainable. Although the project is in its early stage and requires more centralized safety precautions, the team has shown a commitment to building this system to operate autonomously and to gradually eliminate central points of team control.
The main sustainability question is one of economic modeling. There is a complex inter-relationship between demand for minting fETH/xETH and an elaborate web of backstop mechanisms to incentivize a healthy balance between the two tokens. There may be extreme market events that test the endurance of the incentive structure, potentially trapping users unexpectedly and leading to high losses that incentives are unable to meaningfully counteract. For example, during Stability Mode, redemption fees of xETH increase to 8% while leverage increases exponentially, a scenario users are most likely to face during suddenly bearish market events when maintaining a leverage long position is least attractive.
The sustainability of the economic model is of paramount importance to the f(x) team. They are continuing to develop additional backstop mechanisms, including dynamic rewards to the Rebalance Pool depending on xETH leverage, an additional Rebalance Pool B that redeems fETH for xETH, and fETH redemption incentives. Plans for additional protocol functionality should also highlight how the system is still in active development.
Ultimately, the most significant risk factors are observable on-chain, so diligent users can investigate the contracts, read the whitepaper which comprehensively covers the system design, and come to an informed conclusion about the sustainability of the protocol. The f(x) Protocol pools meet suitable criteria to receive gauge incentives.