Add Gauge for sUSDf-long LlamaLend market

Summary:

Add gauge for the sUSDf-long LlamaLend market deployed in this tx to the gauge controller.

This proposal includes an overview of Falcon USDf and rationale for the LlamaLend market configuration.

Abstract:

The sUSDf-long market has been configured similar to the sUSDe-v2 LlamaLend market, as it is an analogous product with similar properties. One notable difference is the inclusion of a proxy oracle that allows the DAO to change the oracle implementation post-deployment. This may be necessary if liquidity migrates to new pools, making the original implementation an unreliable price source. The market also introduces a modified CryptoFromPoolsVaultWAgg oracle implementation that can chain multiple Curve pool price oracles + ERC4626 vault + agg price of crvUSD.

Falcon Finance (s)USDf Overview

Falcon Finance enables whitelisted users to mint USDf from a variety of supported assets, including stablecoins and crypto assets. A detailed list of supported collateral for minting USDf can be found in our documentation here. Falcon uses delta-hedging strategies with capital deployed to centralized exchanges, and on-chain liquidity and staking pools, employing off-exchange custody services through its partner custodians.

The protocol offers sUSDf, a yield-bearing version of USDf, an ERC-4626 vault that accrues rewards from Falcon’s delta-hedging operations. Unlike Ethena’s sUSDe (an analogous product), sUSDf does not involve an unstaking cooldown period. Note that the vault contract does include functionality for setting a cooldown period, but the Falcon team have indicated no plan to introduce a cooldown. However, there is a one week delay on USDf redemptions, available to whitelisted users. Due to delays on arbitrage operations, USDf may not always maintain a strong 1:1 USD peg, and may exhibit similar market dynamics as sUSDe.

Protocol Operations

When users deposit collateral, custody is delegated to trusted custodians (CEFFU and Fireblocks, at the time of writing). These custodians are responsible for redeploying the collateral into a range of strategies designed to achieve several key objectives for the protocol:

  • Minimising the effects of adverse market movements relative to the deposited collateral.
  • Generating yield on the underlying assets.
  • Maintaining the peg of USDf.
  • Maximising the overall capital efficiency of the Falcon Finance protocol.

The following diagram illustrates a high-level overview of this process:

USDf: The Protocol’s Stablecoin

USDf is the stablecoin minted through Falcon Finance’s CDP system. Users have two methods for minting USDf:

  1. Classic Mint:
  • Users can deposit various supported asset classes, including both stablecoins and non-stablecoin crypto assets.
  • For stablecoin collateral: USDf is minted on a 1:1 basis, contingent upon the market value of the deposited stablecoin.
  • For non-stablecoin collateral: An Overcollateralization Ratio (OCR) is applied, determined by the risk profile of the specific asset. The OCR is calculated as the inverse of the Loan-to-Value (LTV) ratio at the time the CDP was initiated.
  1. Innovative Mint:
  • This option is available for users depositing non-stablecoin assets. It involves agreeing to specific terms, notably committing their collateral to the protocol for a fixed period ranging from 3 to 12 months.
  • Additional terms include a “capital efficiency level” and a “strike price multiplier.”
  • Collateral deposited via this strategy is actively managed through “neutral market strategies that minimize sensitivity to market movements” (source).
  • Liquidations under this minting type are designed to occur only under conditions of significant, adverse market stress affecting the collateral.
  • The strike price multiplier defines a strike price for the collateral. If the collateral’s price appreciates to meet this strike price, ownership of the collateral is transferred to the protocol in exchange for the cancellation of the USDf debt, plus a bonus paid to the user. The bonus is calculated as: (StrikePrice * CollateralAmount) - USDf_Minted .
  • As of this writing, a minimum collateral value of $500,000 is required to utilize the Innovative Mint strategy.

USDf Redemptions:

  • All USDf redemptions are subject to a 7-day cooldown period, irrespective of the minting strategy employed. This cooldown allows the Falcon protocol to gracefully unwind any yield-bearing and arbitrage strategies applied to the underlying collateral.
  • For CDPs opened with stablecoins, users can withdraw their original stablecoin collateral directly.
  • For CDPs opened with non-stablecoin assets, users have the flexibility to redeem their position by receiving their original collateral asset, USDT, or a combination of both.

sUSDf: Yield-Bearing USDf

sUSDf is Falcon Finance’s yield-bearing token, structured as an ERC-4626 vault. Users can stake their USDf into this vault, and in return, they receive sUSDf, which acts as a receipt token representing their share of the vault.
The price of sUSDf relative to USDf is determined by the following formula:
USDf/sUSDf = (USDf_staked + Total_Staking_Rewards) / Total_sUSDf_Supply

Falcon Miles: Protocol Incentives

To incentivize the use of their products, Falcon Finance launched “Falcon Miles.” This is a points-based incentive mechanism designed to reward users for interacting directly with the protocol’s products. Further details on Falcon Miles can be found here.

Specification:

Market Parameters

Parameter Value
A (Band Width Factor) 200
AMM Swap Fee 0.2%
Liquidation Discount 1.4%
Loan DIscount 1.9%
Max LTV 97%

The market has been instantiated with the same market parameters as the sUSDe-v2 market in prod. USDf is a new product and very little history is available to refine specific attributes of this asset. However, given it is an analogous product with similar properties, the assumption of relatively similar market behavior to sUSDe is reasonable.

For reference, we have run an optimization analysis for sUSDf, which can be found below. The analysis suggests that the market can support much more aggressive parameterization, but this is with only two months of market history.


Monetary Policy

Parameter Value
Min Rate 0.1%
Max Rate 25%

The market uses Semilog Monetary Policy, the current standard for LlamaLend Markets. This policy uses a polynomial curve based on the market utilization and the min/max rates set by governance. The parameter config is consistent with other yieldbearing stablecoin markets and is intended to exceed the expected yield on the underlying, thereby protecting lenders against market illiquidity.

Oracle

Proxy: https://etherscan.io/address/0x6bff42e501e3a5ab0640c0064f1a0e085ef012c5
Implementation: https://etherscan.io/address/0x60010deBC9f6fC5E976505732f47c8219c661458

Both the oracle proxy and implementation are new with this market deployment. The proxy allows the DAO to set a new oracle implementation, if necessary, without requiring a market migration. The implementation CryptoFromPoolsVaultWAgg is an oracle that chains multiple curve pool price oracles with an ERC4626-compliant vault and the aggregated price of crvUSD.

The underlying pools and contracts used in the oracle include:

Falcon have indicated an intention to maintain the USDf/USDC pool so that it will be a reliable oracle source for the foreseeable future. Note that this oracle configuration assumes that sUSDf maintains a peg to USDf- this is considered a reasonable assumption because sUSDf can be instantly unstaked. In case an unstaking cooldown is introduced, this assumption would not hold true and may necessitate switching the market’s oracle source.

The use of aggregated price of crvUSD improves the resiliency of the market to instances of transient crvUSD depeg in the constituent pools. This reduces the probability that users can be liquidated as a result of crvUSD price deviations. Older LlamaLend markets do not include aggregated price of crvUSD, but it is now a standard for all future markets deployments.

Vote Actions

This vote is to add the sUSDf-long LlamaLend market to the gauge controller.

ACTIONS = [  
    # Add sUSDf-long gauge to gauge controller
    ("0x2F50D538606Fa9EDD2B11E2446BEb18C9D5846bB", "add_gauge", "0xfc31d6227E8b9341bDBf781b58C87C1ccFf7Ff2B", 0, 0), 
]

This vote is live here