# Frax Ecosystem Overview Overview of the Frax Finance Ecosystem Frax currently issues 3 stablecoins: FRAX, FPI, and frxETH, along with numerous other non-stablecoin tokens. There are also multiple contract groups or "subprotocols" within it that integrate these tokens to provide utility and stability. Core concepts to understand the unified Frax Finance ecosystem include: * Three Stablecoins – The Frax Protocol currently issues 3 stablecoins: * [FRAX](/frax-v3-100-cr-and-more/overview) – a USD pegged asset. * [FPI](/frax-price-index/overview-cpi-peg-and-mechanics) – The Frax Price Index (FPI) stablecoin, the first stablecoin pegged to a basket of consumer goods creating its own unit of account separate from any nation state denominated money. * [FraxEther (frxETH)](/frax-ether/frxeth-and-sfrxeth) – a [Liquid Staking Derivative (LSD)](https://www.coingecko.com/learn/what-is-liquid-staking-liquid-staked-derivatives-you-need-to-know) token pegged to ETH, and intended for use as a replacement for WETH in smart contracts. frxETH is also used as the gas token in the Fraxtal chain, explained below. sfrxETH is the complementary ERC4626 token that accrues value from ETH staking rewards, MEV, etc. * frxETH V2 is expected to allow anonymous validator pools that can use escrowed exit messages as collateral to borrow additional ETH. * [Fraxswap](https://docs.frax.finance/fraxswap/technical-specifications) – Native AMM (based on Uniswap V2) with added time weighted average market maker (TWAMM) orders used by the Frax Protocol for rebalancing collateral, mints/redemptions, expanding/contracting stablecoin supply, and deploying protocol owned liquidity onchain. * [Borrow AMM (BAMM) ](/bamm/overview)– Borrowing/lending module built on top of Fraxswap. Does not need an outside oracle or external liquidity to function safely. Borrowers rent liquidity provided by lenders to automatically leverage up and down, such that they can stay solvent even in the case of high volatility. * [Fraxlend](https://docs.frax.finance/fraxlend/fraxlend-overview) – Permissionless lending market that is the lending facility for Frax-based stablecoins. Allows debt origination, customized non-custodial loans, and onboarding collateral assets to the Frax Finance economy. * [AMOs / Protocol-owned Liquidity (POL)](/frax-v3-100-cr-and-more/amos) – The protocol operates numerous Algorithmic Market Operation (AMO) smart contracts to manage its collateral and use it to generate revenue. Examples include the Fraxlend AMO, Curve AMO, and Uniswap V3 AMO. * [Fraxtal](https://docs.frax.com/fraxtal) – A modular L2 chain, based on [Optimism](https://docs.optimism.io/) technology, that uses frxETH as the gas token. * [Fraxtal Points FXTL](https://docs.frax.com/fraxtal/fraxtal-incentives/fraxtal-point-system) – Users earn FXTL for useful activities on Fraxtal, such as spending gas, creating heavily-used contracts, and farming in specific pools. * [Frax Bonds (FXB)](/frax-v3-100-cr-and-more/fxbs) – Zero coupon bond-like tokens auctioned at below 1 FRAX, but exchangeable for 1 FRAX upon maturity. Used to help lock FRAX liquidity and stabilize the FRAX peg. * [Staked Frax (sFRAX) ](/frax-v3-100-cr-and-more/sfrax)– ERC4626 staking vault that distributes part of the Frax Protocol yield weekly to stakers. Denominated in FRAX stablecoins. * [Fraxferry](/cross-chain/bridge) – Optimistic transfer protocol for Frax-based tokens. Fraxferry transfers natively issued Frax Protocol tokens across many blockchains. * [Frax Share (FXS)](https://docs.frax.finance/seigniorage) – The base-layer governance token for the entire Frax ecosystem of smart contracts. It accrues fees, revenue, and excess collateral value. * [veFXS](/fxs-and-vefxs/vefxs) – Users lock FXS for a variable amount of time and receive voting power and farming weight boosts. Inspired by Curve's [veCRV](https://curve.readthedocs.io/dao-vecrv.html). * [Gauge Rewards System](https://docs.frax.finance/vefxs/gauge) – The community can propose new gauge rewards for strategies that integrate Frax-based stablecoins. FXS emissions are fixed, halve each year, and entirely flow to different gauges based on the votes of veFXS stakers. Modified from [Curve](https://curve.readthedocs.io/dao-gauges.html). Website: [https://app.\[frax.finance](https://docs.frax.finance/https:/app.\[frax.finance)]\( Telegram: \ Telegram (announcements / news): \ Discord: \ Twitter: \ Medium / Blog: \ Governance (discussion): \ Governance (voting):
# Frax Shares (FXS) FXS is the staking and governance token of the entire Frax ecosystem. All utility is concentrated into FXS and its locked variant, veFXS. ## Summary The Frax Share token (FXS) is the non-stable, utility token in the protocol, as opposed to FRAX the stablecoin. It is meant to be volatile and hold rights to governance and all utility of the system. Parameters that are up for governance through FXS include adjusting various fees, allocating protocol assets, and enabling new lending pairs for Fraxlend. Surplus protocol income is also distributed to locked FXS ([veFXS](/fxs-and-vefxs/vefxs)) holders, and these veFXS holders can also earn farm weight boosts and other benefits. FXS supply is initially set to 100 million tokens at genesis (distribution [here](/fxs-and-vefxs/frax-share-fxs-distribution)). As of 10/2/2024, the hard FXS supply cap is still 100 million tokens. The FXS token has the potential of upside utility and downside utility of the system, where the delta changes in value are always stabilized away from the FRAX token itself and not affecting the peg.

FXS

### Original Model (V1) In the original (V1) model of FRAX, FRAX minting required both FXS and another stablecoin, such as USDC. The percentage of each (e.g. 15% FXS, 85% USDC) varied according to market conditions. See [Frax V1 Background](https://docs.frax.finance/amo/overview#frax-v1-background) for details. The FXS token’s market capitalization would be calculated as the future expected net value creation from seigniorage of FRAX tokens in perpetuity, the cash flow from fees, and utilization of unused collateral. Additionally, as the market cap of FXS increases, so does the system’s ability to keep FRAX stable. Thus, the priority in the design is to accrue maximal value to the FXS token while maintaining FRAX as a stable currency. As Robert Sam’s described in the original Seigniorage Shares [whitepaper](https://github.com/rmsams/stablecoins/blob/master/paper.pdf): “Share tokens are like the asset side of a central bank’s balance sheet. The market capitalization of shares at any point in time fixes the upper limit on how much the coin supply can be reduced.” Likewise, the Frax protocol takes inspiration from Sams’ proposal as Frax is a hybrid (fractional) seigniorage shares model. FXS would be largely deflationary in supply as long as FRAX demand grows. ![Schematic of current utility of FXS (V1)](/files/-MVG9W_8fJNC_D62V0Gr) ### Current Model (V2 onwards) In the current model, FXS is still used for governance, receives excess protocol income, and confers other miscellaneous benefits to holders (via [veFXS](/fxs-and-vefxs/vefxs)). However, FXS is no longer needed to mint FRAX. That functionality is delegated to [AMOs](/amo/overview). # veFXS Locked FXS that provides voting power and other benefits ## Background veFXS is a vesting and yield system based off of Curve’s [veCRV](https://curve.readthedocs.io/dao-vecrv.html) mechanism. Users may lock up their FXS for up to 4 years for four times the amount of veFXS (e.g. 100 FXS locked for 4 years returns 400 veFXS). veFXS is not a transferable token nor does it trade on liquid markets. It is more akin to an account based point system that signifies the vesting duration of the wallet's locked FXS tokens within the protocol. The veFXS balance linearly decreases as tokens approach their lock expiry, approaching 1 veFXS per 1 FXS at zero lock time remaining. This encourages long-term staking and an active community. ### veFXS Governance Whitelisting Smart contracts & DAOs require whitelisting by governance to stake for veFXS. Only externally owned accounts and normal user wallets can directly call the veFXS stake locking function. In order to build veFXS functionality into your protocol, begin the governance process with the FRAX community at [gov.frax.finance](https://gov.frax.finance) by submitting a whitelisting proposal. ## Voting Power Each veFXS has 1 vote in governance proposals. Staking 1 FXS for the maximum time, 4 years, would generate 4 veFXS. This veFXS balance itself will slowly decay down to 1 veFXS after 4 years, at which time the user can redeem the veFXS back for FXS. In the meantime, the user can also increase their veFXS balance by locking up FXS, extending the lock end date, or both. It should be noted that veFXS is non-transferable and each account can only have a single lock duration meaning that a single address cannot lock certain FXS tokens for 2 years then another set of FXS tokens for 3 years etc. All FXS per account must have a uniform lock time. ## Gauge Farming Boosts Holding veFXS will give the user more weight when collecting certain farming rewards. All farming rewards that are distributed directly through the protocol are eligible for veFXS boosts. External farming that are promoted by other protocols (such as Sushi Onsen) are typically not available for veFXS boosts since they are independent of the Frax protocol itself. Other protocols can choose to distribute their rewards through Frax's gauge farming contracts to acquire the veFXS boost functionality. FXS gauge farming contracts support up to 4 different token rewards per gauge.\ \ A user's veFXS boost does not increase the overall emission of rewards. The boost is an additive boost that will be added to each farmer's yield proportional to their veFXS balance. The veFXS boost can be different for each LP pair by the discretion of the community based on partnership agreements and governance votes. Each gauge will display the exact terms of the boosts available.\ \ Farming boosts are given in ratios of veFXS per 1 FRAX in the LP deposit token. For example, a FRAX-IQ gauge with a 2x boost ratio of 10 veFXS per 1 FRAX means that a user that has 50,000 veFXS gets a 2x boost for an LP position that contains 5,000 FRAX (total value of $10,000). Most gauges currently offer a 2x boost in yield with a requirements of 4 veFXS to 1 FRAX. ## veFXS Yield The primary cash flow distribution mechanism of the Frax Protocol is to veFXS holders. Cash flow earned from AMOs, Fraxlend loans, Fraxswap fees, etc are typically used to buy back FXS from the market then distributed to veFXS stakers as yield. The emission rate varies depending on protocol profitability, sources of cash flow, market price of FXS, and governance actions.\ \ Historical view of veFXS yield can be viewed here: ## Future Functionality The veFXS system is modular and all-purpose. In the future, it can be expanded to vote on AMO weights, earn additional yield in new places/features, and help create long term alignment for the Frax Finance economy. This **benefits Frax** as a whole by: * Allocate voting power to long-term holders of FXS through veFXS * Incentivizing gauge farmers to stake FXS * Allowing DAOs and other projects to build a large and long term veFXS position and participate in Frax governance. * Creating a bond-like utility for FXS and create a benchmark APR rate for staked FXS ### Links
TypeChainLink
UIEthereumhttps://app.frax.finance/vefxs
ContractEthereum0xc8418aF6358FFddA74e09Ca9CC3Fe03Ca6aDC5b0
UIFraxtalhttps://app.frax.finance/fxtl-vefxs
ContractFraxtal0x007FD070a7E1B0fA1364044a373Ac1339bAD89CF
# Gauges Gauge weighted system for controlling FXS emissions A "gauge" is a farming smart contract that takes deposits in one asset (typically an LP token, a vault token, NFT position etc) and rewards the depositor yield in FXS (and potentially other) tokens. Gauge contracts can take many forms of deposits such as FRAX lending deposits (aFRAX in Aave, cFRAX in Compound, fFRAX in Fraxlend), LP tokens (Curve LP tokens or Fraxswap LP tokens), or even NFTs (such as Uniswap v3 NFT positions). Gauges are used to incentivize particular "strategies" and behaviors that are advantageous to the protocol such as increasing FRAX lending, deepening liquidity of certain pairs, or growing a partnership/integration between another project. The full list of current gauges can be found here: \ \ The FXS allocated to each gauge strategy is referred to to as its "gauge weight." They can distribute their voting power across multiple gauges or a single gauge. This allows veFXS holders who are the most long term users of the protocol to have control over the future FXS emission rate. Each veFXS is equal to 1 vote.\ \ Additionally, the gauge system lowers the influence of FRAX pairs where the majority of rewards are sold off since those LPs will not have veFXS to continue voting for their pair. This system strongly favors LP providers who continually stake their rewards for veFXS to increase their pool's gauge weight. Essentially, FRAX gauges align incentives of veFXS holders so that the most long term oriented FXS holders control where FXS emissions go. **Gauge weights are updated once every week every Wednesday at 5pm PST. This means that the FXS emission rate for each pair is constant for 1 week then updates to the new rate each Wednesday. Any user can change their weight allocation every 10 days.** Since FXS gauge emissions are fixed and halve every year, governance can decide whether to allocate part of protocol cash flows or newly minted FRAX to gauge rewards after a few years. Thus, veFXS stakers can feel confident staking the maximum duration of 4 years knowing that the gauge program is not temporary and won't be deprecated. Gauge strategies are currently a vital part of incentivizing the right behavior for the growth of the Frax ecosystem.
![The gauge voting list on app.frax.finance/gauge used for allocating all FXS emissions. The aggregate weights of all votes decide which gauge strategy contract FXS tokens are sent to.](/files/ba17ffe2U7EY8nFjcz7C) ### Current Types of Gauges **LP Gauge**: an LP gauge is the most common type of gauge contract taking an ERC20 LP token as a deposit. Most gauges incentivize LP positions from Fraxswap, Curve, Uniswap v2, etc. Typically, these gauges offer a 2x veFXS boost of 4 veFXS per 1 FRAX in the LP position and an additional 1 year 2x timelock boost (unless otherwise specified).\ **Lending Gauge**: a lending gauge is typically deployed to incentivize FRAX lending activity in a money market such as Aave, Fraxlend, Compound etc. The deposit token is aFRAX, fFRAX, cFRAX, etc. Lending gauges typically do not offer timelock boosts but offer up to 2x veFXS boost for 1 FRAX lent out per 4 veFXS.\ **Uniswap V3 Gauge**: Uniswap v3 gauges take an NFT LP position as a deposit. These gauges are pre-configured at launch to accept NFT LPs at a specific tick range to incentivize only the exact concentrated liquidity position that governance approved for the pair. These gauges offer a 2x veFXS boost of 4 veFXS per 1 FRAX in the LP position and an additional timelock boost of 2x-3x for 1-3 year locks (specified for each gauge on its corresponding staking page). \ **Vault Gauge**: a vault gauge takes a vault strategy token as a deposit such as a Stake DAO or Yearn Finance vault token. Vault gauges typically offer a 2x veFXS boost of 4 veFXS per 1 FRAX in the vault position and a timelock boost of 2-3x for 1-3 year (specified for each gauge). \
![Pie chart displaying the total weights for a particular weekly gauge period. Periods change on Wednesdays at 11:59:59 UTC. Votes can be changed by veFXS stakers once every 10 days.](/files/PcyQjapN5CT6w9kj55DT) ### veFXS Boosts & Timelock Boosts Users who stake tokens in a gauge contract earn boosts to their APR based on the amount of veFXS they have. Additionally, users that lock their deposited tokens within the gauge contract for a specific period of time will earn a further additive boost thus enabling stacking of both boosts for maximal APR. Since gauge weights change weekly, locked LPs in gauges do not get their deposits unlocked if the gauge weight changes. See the [veFXS spec page](https://docs.frax.finance/vefxs/vefxs) for an explanation of how boosts are calculated. Each gauge strategy can have different boost terms depending on the end behavior it is incentivizing. For example, a lending gauge might have a very low timelock boost since lending FRAX does not provide peg stability and thus not need extra rewards. However, a Curve, Uniswap, or Fraxswap liquidity gauge might provide a high timelock boost because locking liquidity helps FRAX peg strength during volatility. ### Gauge Agnostic Pairs FRAX gauges allow veFXS stakers to directly control the FXS emission rate to any pool that integrates FRAX. There is no restriction on which protocols or pairs can have a gauge weight other than they use FRAX stablecoins and pass the gauge governance vote. Any FRAX pool (including cross-chain pools) can be added as a gauge in the future. The veFXS gauge system is completely agnostic to the deposit token within a gauge as long as the FRAX stablecoin is being used within the strategy. Essentially, veFXS gauges are the money layer gauge weights of DeFi while other gauges (such as Curve gauge weights) are the DEX layer weights. Since veFXS stakers can control emissions into any protocol that integrates FRAX, many protocols and communities might compete for controlling the future cash flow of an algorithmic stablecoin protocol. It's important to note for any smart contract (non-EOA wallet) to stake veFXS, they must be whitelisted by a governance vote. For a full list of benefits of holding veFXS such as AMO profits and farming boosts, see the [veFXS full specs](https://docs.frax.finance/vefxs/vefxs).
# FXS Distribution The distribution of FXS across the system ## Community (65% – 65,000,000 FXS) DeFi Protocols have made use of liquidity programs to jumpstart growth and distribute protocol tokens to community members. To that end, 60% of all FXS tokens are to be distributed through various yield farming, liquidity incentives, and exclusive governance proposals across a number of years. 5% Is allocated to more team-discretionary activities such as 3rd-party grants, audits, bug bounties, and partnerships (not for personal team member benefits). **60% – Liquidity Programs / Farming / Community – Via gauges & governance halving naturally every 12 months** Per the original design specs for FXS distribution, the FXS supply will halve every 12 months on December 20th each year. Initially, per [FIP-16 veFXS gauges](https://gov.frax.finance/t/fip-16-vefxs-gauges/84), the emission was `25,000 FXS` per day to the FXS gauges. As of 10/2/2024, due to 3 halvenings (see below), the current daily emission is `3,125 FXS`. These changes do not unlock locked LPs as they are the normal emission schedule of the FXS supply.\ \ As DeFi is an evolving landscape, these emissions can be changed by a full Frax Improvement Proposal (FIP) governance vote where LP locks and boost weights can be redone if the FIP is passed. Full votes require 2 weeks of discussion followed by a token holder vote per the official governance process. Community governance can decide which pools, programs, and initiatives to support with the emission schedule, but it cannot be increased past the `100,000,000 FXS` supply max. Thus, a maximum of `60,000,000 FXS` will be distributed to the community for liquidity programs and other DeFi initiatives as they appear in the space as voted by governance. New programs can be added by governance to the remaining allocation, but no more than `60,000,000 FXS` can be allocated due to the hard cap of `100,000,000 FXS` distributed. This is to put a hard cap on the amount of FXS as well as to put a hard duration on the number of years required to distribute the FXS. This emission rate was chosen to balance the need for a large amount of rewards for early adopters while not distributing all FXS too early which is needed for long term community sustainability. The FXS emission should be thought of and modeled more after Bitcoin mining than anything else. FXS distribution needs to be multi-year, extended, and sustainable until the protocol reaches ubiquity. Community Treasury: [`0x63278bF9AcdFC9fA65CFa2940b89A34ADfbCb4A1`](https://etherscan.io/address/0x63278bF9AcdFC9fA65CFa2940b89A34ADfbCb4A1) **5% – Project Team Treasury / Grants / Partnerships / Audits / Security-Bug-Bounties – via Team and Community discretion**\ The Project Treasury should be used for making grants for development of the Frax technology, open source upkeep of the code, future audits of smart contracts, bug bounties through responsible disclosure, possible cross-chain implementations, team compensation, creation of new protocol level features and updates, Frax Improvement Proposals (FIPs), partnerships with exchanges and DeFi projects, providing liquidity on AMMs at launch. The usage of this fund is dependent on the discretion of the team. Team (Discretionary) Treasury: [`0x9AA7Db8E488eE3ffCC9CdFD4f2EaECC8ABeDCB48`](https://etherscan.io/address/0x9AA7Db8E488eE3ffCC9CdFD4f2EaECC8ABeDCB48) ## Team, Advisors, Investors (35% – 35,000,000 FXS) **20% – Team / Founders / Early Project Members – 12 months, 6 month cliff**\ Team tokens are retained for founders and original early contributors to Frax. The Frax Protocol was conceived in late 2018 and work began in early 2019. The Frax concept has been over 6 years old since conception. The contributions of founders and early members that worked on Frax was crucial to releasing the protocol. The team will continue to work on Frax for its lifetime along with the greater community. *This distribution was completed on 12/20/2021.* Team Distribution Treasury: [`0x8D4392F55bC76A046E443eb3bab99887F4366BB0`](https://etherscan.io/address/0x8D4392F55bC76A046E443eb3bab99887F4366BB0) **3% – Strategic Advisors / Outside Early Contributors – 36 months**\ Advisory tokens were allotted for strategic work done in legal, technical, and business efforts to advance the adoption of the Frax protocol. The tokens were vested evenly over 3 years and *completed on 12/20/2023.* Advisor Distribution Treasury: [`0x874a873e4891fB760EdFDae0D26cA2c00922C404`](https://etherscan.io/address/0x874a873e4891fB760EdFDae0D26cA2c00922C404) **12% – Accredited Private Investors – 2% unlocked at launch, 5% vested over the first 6 months, 5% vested over 1 year with a 6 month cliff** \ The first round in Frax was done in August of 2020 with a small allocation that was sold out in under 2 hours. The remainder of the round was done individually through private placements. This vesting had a small amount of their tokens (\~2% of the total 100M supply) distributed at Day 0 / launch. The remaining 10% was vested evenly over 1 year, half of which had a 6 month cliff. *This distribution was completed on 12/20/2021.* Investor Distribution Treasury: [`0xa95f86fE0409030136D6b82491822B3D70F890b3`](https://etherscan.io/address/0xa95f86fE0409030136D6b82491822B3D70F890b3) ### # FXS Smart Contract & Addresses Modified ERC-20 Contract representing the FXS token, which is used for staking and governance actions surrounding the FRAX stablecoin. ## Deployments | Chain | Address | | -------------------- | -------------------------------------------- | | Arbitrum | 0x9d2F299715D94d8A7E6F5eaa8E654E8c74a988A7 | | Aurora | 0xBb8831701E68B99616bF940b7DafBeb4CDb23e0b | | Avalanche | 0x214DB107654fF987AD859F34125307783fC8e387 | | Base (LayerZero) | 0x23432452B720C80553458496D4D9d7C5003280d0 | | Blast (LayerZero) | 0x23432452B720C80553458496D4D9d7C5003280d0 | | Boba | 0xae8871A949F255B12704A98c00C2293354a36013 | | BSC | 0xe48A3d7d0Bc88d552f730B62c006bC925eadB9eE | | Ethereum (native) | 0x3432B6A60D23Ca0dFCa7761B7ab56459D9C964D0 | | Ethereum (LayerZero) | 0x23432452B720C80553458496D4D9d7C5003280d0 | | Evmos | 0xd8176865DD0D672c6Ab4A427572f80A72b4B4A9C | | Fantom | 0x7d016eec9c25232b01F23EF992D98ca97fc2AF5a | | Fraxtal (native) | 0xFc00000000000000000000000000000000000002 | | Fraxtal (LayerZero) | 0x64445f0aecc51e94ad52d8ac56b7190e764e561a | | Harmony | 0x0767D8E1b05eFA8d6A301a65b324B6b66A1CC14c | | Metis (LayerZero) | 0x23432452B720C80553458496D4D9d7C5003280d0 | | Mode (LayerZero) | 0x64445f0aecc51e94ad52d8ac56b7190e764e561a | | Moonbeam | 0x2CC0A9D8047A5011dEfe85328a6f26968C8aaA1C | | Moonriver | 0x6f1D1Ee50846Fcbc3de91723E61cb68CFa6D0E98 | | Optimism | 0x67CCEA5bb16181E7b4109c9c2143c24a1c2205Be | | Polygon | 0x1a3acf6D19267E2d3e7f898f42803e90C9219062 | | Sei (LayerZero) | 0x64445f0aecc51e94ad52d8ac56b7190e764e561a | | Solana | 6LX8BhMQ4Sy2otmAWj7Y5sKd9YTVVUgfMsBzT6B9W7ct | | X-Layer | 0x64445f0aecc51e94ad52d8ac56b7190e764e561a | ## State Variables #### ERC-20 (Inherited) #### AccessControl (Inherited) #### FXS-Specific ``` address public FRAXStablecoinAdd ``` Address of the FRAX contract. ``` uint256 genesis_supply ``` Genesis supply of FXS. ``` uint256 public maximum_supply ``` Maximum supply of FXS. ``` uint256 public FXS_DAO_min ``` Minimum FXS required to join DAO groups. ``` address public owner_address ``` Address of the contract owner. ``` address public oracle_address ``` Address of the oracle. ``` address public timelock_address ``` Address of the timelock. ``` FRAXStablecoin private FRAX ``` The FRAX contract instance. ``` struct Checkpoint { uint32 fromBlock; uint96 votes; } ``` From Compound Finance. Used for governance voting. ``` mapping (address => mapping (uint32 => Checkpoint)) public checkpoints ``` List of voting power for a given address, at a given block. ``` mapping (address => uint32) public numCheckpoints ``` Checkpoint count for an address. ## Restricted Functions **setOracle** ``` setOracle(address new_oracle) external onlyByOracle ``` Change the address of the price oracle. **setFRAXAddress** ``` setFRAXAddress(address frax_contract_address) external onlyByOracle ``` Set the address of the FRAX contract. **setFXSMinDAO** ``` setFXSMinDAO(uint256 min_FXS) external onlyByOracle ``` Set minimum FXS required to join DAO groups. **mint** ``` mint(address to, uint256 amount) public onlyPools ``` Mint new FXS tokens. **pool\_mint** ``` pool_mint(address m_address, uint256 m_amount) external onlyPools ``` This function is what other FRAX pools will call to mint new FXS (similar to the FRAX mint). **pool\_burn\_from** ``` pool_burn_from(address b_address, uint256 b_amount) external onlyPools ``` This function is what other FRAX pools will call to burn FXS. ## **Overridden Public** Functions **transfer** ``` transfer(address recipient, uint256 amount) public virtual override returns (bool) ``` Transfer FXS tokens. **transferFrom** ``` transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) ``` Transfer FXS tokens from another account. Must have an allowance set beforehand. ## **Public** Functions **getCurrentVotes** ``` getCurrentVotes(address account) external view returns (uint96) ``` Gets the current votes balance for `account`. **getPriorVotes** ``` getPriorVotes(address account, uint blockNumber) public view returns (uint96) ``` Determine the prior number of votes for an account as of a block number. Block number must be a finalized block or else this function will revert to prevent misinformation. ## **Internal** Functions **\_moveDelegates** ``` _moveDelegates(address srcRep, address dstRep, uint96 amount) internal ``` Misnomer, from Compound Finance's `_moveDelegates`. Helps keep track of available voting power for FXS holders. **\_writeCheckpoint** ``` _writeCheckpoint(address voter, uint32 nCheckpoints, uint96 oldVotes, uint96 newVotes) internal ``` From Compound Finance's governance scheme. Helps keep track of available voting power for FXS holders at a specific block. Called when a FXS token transfer, mint, or burn occurs. **safe32** ``` safe32(uint n, string memory errorMessage) internal pure returns (uint32) ``` Make sure the provided int is 32 bits or less, and convert it to a uint32. **safe96** ``` safe96(uint n, string memory errorMessage) internal pure returns (uint96) ``` Make sure the provided int is 96 bits or less, and convert it to a uint96. **add96** ``` add96(uint96 a, uint96 b, string memory errorMessage) internal pure returns (uint96) ``` Add two uint96 integers safely. **sub96** ``` sub96(uint96 a, uint96 b, string memory errorMessage) internal pure returns (uint96) ``` Subtract two uint96 integers safely. **getChainId** ``` getChainId() internal pure returns (uint) ``` Return the Ethereum chain ID the contract is deployed on ## Events **VoterVotesChanged** ``` VoterVotesChanged(address indexed voter, uint previousBalance, uint newBalance) ``` Emitted when a voters account's vote balance changes **FXSBurned** ``` FXSBurned(address indexed from, address indexed to, uint256 amount) ``` Emitted when FXS is burned, usually from a redemption by the pool ## Modifiers **onlyPools** ``` onlyPools() ``` Restrict actions to pool contracts, e.g. minting new FXS. **onlyByOracle** ``` onlyByOracle() ``` Restrict actions to the oracle, such as setting the FRAX and oracle addresses # Frax Governance Overview Fully onchain, trustless, and decentralized governance based on Compound/OpenZeppelin Governor that controls Gnosis Safes ## Motivation Prior to Frax Governance, Frax Protocol operations were not fully decentralized. Most actions were taken by key Frax stakeholders through Gnosis Safes. The implied trust assumption was that the Frax stakeholders won’t act maliciously and external actors won’t force the stakeholders to execute malicious actions. With the introduction of Frax Governance, this trust assumption is removed and Frax Protocol is controlled by veFXS holders through onchain governance. ⚠️ (As of 10/2/2024) While the migration is ongoing, voting will be conducted through [Snapshot](https://snapshot.org/#/frax.eth) on Frax's own [Fraxtal](https://docs.frax.com/fraxtal) chain. ⚠️ ## Major Components

Frax Governance

## End State and Key Takeaways The final state of Frax Governance will have full control of all major safes, giving veFXS holders the final say over everything in the protocol. veFXS holders can vote for or against all proposals and can replace Frax team members as owners on the underlying Safes and execute any action, if it reaches quorum and passes. Frax team members have the ability to create optimistic proposals through FraxGovernorOmega which succeed by default. Typically proposals fail by default, but with Frax Governance, veFXS holders can vote for or against optimistic proposals as well. If an optimistic proposal reaches quorum and there are more against than for votes, the proposal will fail. # How It Works ## Prior Work Frax Governance is based largely on Compound/OpenZeppelin Governor contracts. The lifecycle of a Governor proposal is covered here: . ## Frax Governance Frax Governance is a dual Governor system consisting of FraxGovernorAlpha and FraxGovernorOmega. Alpha and Omega have different uses and configurations. ## FraxGovernorOmega FraxGovernorOmega has limited control over the underlying Safes. Only the Frax Team / Safe owners can create Omega proposals. Each proposal is mapped 1 to 1 to a Safe transaction. Omega is configured as an additional Safe owner and must approve of a Safe transaction before Safe owners can execute it. This is enforced using a custom Gnosis Safe Guard (). Omega has a very short voting delay, a short voting period, and a low quorum value. Safe owners can only add proposals to Omega after getting the Safe’s threshold number of signatures for that Safe transaction. For example, if a Safe is a 3/6 (5 owners + Omega) 3 owners must sign before the proposal can be put into Omega. After adding a proposal to Omega, it follows the same lifecycle as a Governor proposal. If it passes, Omega calls approveHash on the Safe and the proposal can be executed by any owner through the Gnosis Safe UI as usual. If the proposal fails, rejectTransaction can be called on Omega to approve a 0 ether transfer. Other owners can sign and execute the same 0 ether transfer, which just increments the nonce on the Safe, allowing creation of new Gnosis transactions. Omega has a feature called the short circuit threshold. **If 51% of the total veFXS supply votes for an Omega proposal, it will immediately succeed and be executable**. This helps in extraordinary circumstances, when the Frax team needs to take quick action to protect the protocol. Omega cannot change its own governance parameters or change any configuration on the underlying Safes. FraxGovernorAlpha must be used to change these values. ## FraxGovernorAlpha FraxGovernorAlpha has full control over underlying Safes. Any veFXS holder with a veFXS balance meeting or exceeding the proposal threshold can create a proposal. FraxGovernorAlpha is nearly identical to OpenZeppelin Governor. It has full control over each Gnosis Safe because its TimelockController is configured as a module () on the Safe and can execute any action. Modules are not constrained by Gnosis Safe Guards. Alpha has a long voting delay, long voting period, and much higher quorum than Omega. Once an Alpha proposal passes, it must be queued and after the configured timelock period, it can be executed. ## veFXS Holders veFXS holders are the most important part of the system. Proposals succeeding or failing is ultimately up to veFXS holders because they directly vote on them. Your veFXS balance is equal to your voting power.\ \ veFXS holders can delegate their voting power to others. If a veFXS holder has sufficient veFXS voting power between their own stake and delegated stake, they can propose anything with FraxGovernorAlpha. Through Alpha, veFXS holders can replace owners on the Safes, change governance parameters on Alpha or Omega, change parameters on any Frax smart contract, remove/add protocol owned liquidity to/from liquidity pools, etc. veFXS holders have ultimate control over the entire Frax protocol. ## Frax Governance Proposal Lifecycle
# Advanced Concepts ## Delegations Due to how the veFXS contract works, if you lock more FXS or increase the duration of your lock, you have to delegate your voting weight again using the `VeFxsVotingDelegation` contract.\ \ To delegate back to yourself, call the `delegate()` function with your address as the delegatee. Delegations can also be done by signature. See `delegateBySig()` . ## veFXS Voting Weight Decay When your veFXS lock expires, your balance is equal to the amount of FXS you locked. In Frax Governance, as soon as your lock expires your voting weight goes to 0. You need to have an active lock to have voting weight in Frax Governance. ## Smart Contract Design
## Create an Alpha proposal 1. Go to 2. Click Propose 3. Make sure your voting weight is above the proposal threshold 1. Check proposal threshold here: 2. Check your weight here: 4. Fill out your transaction data 5. Submit ## Fractional Voting Frax Governance makes use of ScopeLift’s fractional voting: This allows for users to split their voting power between for/against/abstain. It also allows smart contracts/custodians to pass through the voting power to liquidity providers based on their relative LP stake. ## Governance Configuration For a Safe to be properly configured for frxGov, it must have the FraxGuard installed, have FraxGovernorOmega as a signer, have FraxGovernorAlpha’s TimelockController installed as a module, and have FraxCompatibilityFallbackHandler set as the fallbackHandler. Safes can be sunset similarly through Alpha proposals by removing the configuration and removing them from the allowlist. FraxGovernorOmega and FraxGovernorAlpha uses OpenZeppelin Governor and the following extensions: * GovernorSettings * GovernorVotesQuorumFraction * GovernorCountingFractional In addition, Alpha uses these Governor extensions: * GovernorTimelockControl * GovernorPreventLateQuorum See their configuration here: ### Additional Frax Governance Specific Configuration: All of the following functions must be called from an Alpha proposal. Alpha and Omega: * `setVotingDelayBlocks()` * `setVeFxsVotingDelegation()` * `updateShortCircuitNumerator()` Omega only: * `addToSafeAllowlist()` * `removeFromSafeAllowlist()` * `addToDelegateCallAllowlist()` * `removeFromDelegateCallAllowlist()` * `setSafeVotingPeriod()` See the frxGov codebase for explanation of each of these functions. See the Gnosis Safe codebase for Safe configuration that Alpha controls. ## Full Proposal Flow ### Alpha Identical to OpenZeppelin Governor with GovernorTimelockControl. * Create proposal - `propose()` * Vote - `castVote()` * If fails do nothing * If succeeds * `queue()` * Wait Timelock's `minDelay` * `execute()` ### Omega 1. An owner uses the Gnosis Safe to initiate a DeFi transaction. This produces a transaction hash that identifies the action to be approved or rejected by the other Safe owners. 2. ⅗ EOA sign the transaction through the UI 3. After 3 signatures are collected, anyone can call `fraxGovernorOmega.addTransaction(address teamSafe, TxHashArgs calldata args, bytes calldata signatures)` to begin onchain governance. The team is incentivized to do so because they cannot execute any Gnosis transaction without FraxGovernorOmega’s approval. 4. veFXS voters have a 2-day window of time to vote on the proposal. 5. If no quorum is met during the voting window, or there are more for than against votes on the proposal, anyone can call `execute()`. This calls `safe.approveHash()` from Omega under the hood. It provides the needed approval from FraxGovernorOmega, which will allow the gnosis transaction to be executed through the Gnosis UI. 1. If quorum is met and there are more against than for votes. The proposal gets vetoed by anyone calling `fraxGovernorOmega.rejectTransaction (address teamSafe, uint256 nonce)`. This will cause FraxGovernorOmega to sign a zero ETH transfer Safe transaction with the same nonce. Safe owners can then sign the same transaction in the UI using the “replace transaction” functionality. Safe owners can then execute the zero ETH transfer, incrementing the nonce. The original transaction can never be executed, because there is no approval from FraxGovernorOmega and the nonce has moved on, invalidating the original transaction. ### Smart Contract Signature Support (EIP1271 / EIP712) Background: Gnosis Safes can provide smart contract signatures. The typical mechanism is contained in Safe’s CompatibilityFallbackHandler, which checks if the threshold number of signatures is met from the owners, and then the Safe provides its approval. This mechanism was not sufficient for frxGov because we want Omega + owners to provide approval OR Alpha alone to provide approval. To solve this we wrote FraxCompatibilityFallbackHandler, which only checks if `safe.signedMessages(messageHash)` is set. Alpha and Omega can both call the setter of this state using `SignMessageLib.signMessage()`. ## Attacks and Mitigations FraxGovernorAlpha could be used to create a proposal that essentially shuts down the entire Frax protocol and returns all protocol owned liquidity to FXS holders. We have the Timelock delay on Alpha for situations like this. It will take a day from when this proposal passes to when it can be executed, giving Frax users time to exit the protocol via various liquidity pools.\ \ We also added in the OpenZeppelin Governor extension GovernorPreventLateQuorum. If a proposal reaches quorum late in the voting period, the voting period will get extended by 2 days. This stops malicious user(s) from voting for a malicious proposal at the last second. It gives time for the community to react in such a scenario. We also created the frxEth redemption queue to allow users to exit frxEth if a malicious actor gets 51% of veFXS voting power and passes a proposal to infinite mint frxEth in an attempt to steal the treasury. ## Technical Discussions To conform to the ERC5805 standard, an implementing contract must implement several functions including function `getPastTotalSupply(uint256 timepoint) external view returns (uint256)`. We use timestamps throughout our Governor contracts, however this function is the one exception and it must accept a `block.number`. Unfortunately, `veFXS.totalSupply(timestamp)`doesn't work for historical values, so we must use `veFXS.totalSupplyAt(block.number)`. This also impacts quorum values. Typically quorum is calculated from voting start timestamp (snapshot). We allow similar functionality by making the `$votingDelayBlocks` value configurable by governance, so it mirrors the timestamp functionality. ## Codebase and Contract Addresses ### Codebase ### Contract Addresses **VeFxsVotingDelegation**: **FraxGovernorAlpha**: **FraxGovernorAlphaTimelock**: **FraxGovernorOmega**: **FraxGuard**: **FraxCompatibilityFallbackHandler**: # Fraxtal Snapshot Voting Delegating your combined veFXS for Snapshot After a proposal is discussed in the [Governance Forum](https://gov.frax.finance/c/governance-proposals/5), it can be voted on using [Snapshot](https://snapshot.org/#/frax.eth). Voting power is the sum of held FXS as well as veFXS from miscellaneous sources. Historically, voting was done on Ethereum, but it since moved to Fraxtal (see [vote](https://snapshot.org/#/frax.eth/proposal/0x60ce169bce5174b399fa09ccc35c14e692a6bb19229d5957e44940f58e89efbc)). Snapshot should pick up all of your voting power sources (Mainnet veFXS, Fraxtal FXS, Fraxtal veFXS, and Fraxtal FPISLocker) **EXCEPT** Mainnet FXS. You would need to bridge your FXS over to Fraxtal to receive the 1:1 votes for it, or lock it in Mainnet veFXS (which has an existing balance proof system on Fraxtal). ## Delegation Due to Snapshot limitations for the Fraxtal chain, many-to-one delegations will no longer be possible. If you are either 1) Delegating or 2) Unable to access your Mainnet (*delegator*) address on Fraxtal, we deployed a simple 1:1 delegation contract to help. First obtain an address on Fraxtal that you can make arbitrary calls from. It can be a new or existing address. This will be known as the *delegatee* address. You will need to send a cross-chain message to Fraxtal via the L1CrossDomainMessenger (on Ethereum), with the destination contract as DoubleOptInVeFXSDelegation (on Fraxtal). Below are useful addresses and function signatures: ``` // Ethereum L1CrossDomainMessenger: 0x126bcc31Bc076B3d515f60FBC81FddE0B0d542Ed // Fraxtal DoubleOptInVeFXSDelegation: 0x9D269188b741277fF316862B537bd4fce14637b3 - 0x6417e439: nominateDelegateeCrossChain - 0x617075fe: rescindDelegationAsDelegatorCrossChain ``` ### Nominate a delegatee *** Your *delegatee* address on Fraxtal will be able to vote with its own combined voting power as well as the combined voting power of the *delegator*. #### ***If delegator is on Ethereum only*** 1\) Prepare a hex message {% code overflow="wrap" %} ``` cast calldata "nominateDelegateeCrossChain(address)" "" ``` {% endcode %} 2\) Call the following on Ethereum with your *delegator* address: {% code overflow="wrap" %} ``` L1CrossDomainMessenger.sendMessage(0x9D269188b741277fF316862B537bd4fce14637b3, , 500000) ``` {% endcode %} This calls `DoubleOptInVeFXSDelegation.nominateDelegateeCrossChain` on Fraxtal 3\) Wait a few minutes 4\) With your *delegatee* address on Fraxtal, call: ``` DoubleOptInVeFXSDelegation.acceptDelegation() ``` #### ***If delegator is on Fraxtal*** 1\) With the delegator, call: ``` DoubleOptInVeFXSDelegation.nominateDelegatee() ``` 2\) With the delegatee, call: ``` DoubleOptInVeFXSDelegation.acceptDelegation() ``` *** ### Rescind a delegatee Either the delegator or delegatee can unilaterally revoke a delegation at any time. #### ***If delegator is on Ethereum only*** 1\) Call the following on Ethereum with your *delegator* address: {% code overflow="wrap" %} ``` L1CrossDomainMessenger.sendMessage(0x9D269188b741277fF316862B537bd4fce14637b3, 0x617075fe, 500000) ``` {% endcode %} This calls `DoubleOptInVeFXSDelegation.rescindDelegationAsDelegatorCrossChain` on Fraxtal 2\) Wait a few minutes, then your delegation on Fraxtal should be rescinded #### ***As the delegator on Fraxtal*** 1\) With the delegator, call: ``` DoubleOptInVeFXSDelegation.rescindDelegationAsDelegator() ``` #### ***As the delegatee on Fraxtal*** 1\) With the delegatee, call: ``` DoubleOptInVeFXSDelegation.rescindDelegationAsDelegatee() ``` # Original Design The original Frax framework ⚠️ The original mint/redeem model explained here has been retired in favor of later (V2 onwards) mechanisms and is for historic / information purposes only ⚠️ Frax originally launched on December 20th, 2020. In Frax V1, there was only a single mint/redeem AMO, the fractional-algorithmic stability mechanism. We refer to this as the **base stability mechanism**. You can read about it in the [Core Whitepaper](https://github.com/FraxFinance/frax-solidity/blob/master/frax_whitepaper_v1.pdf). In Frax v1, the collateral ratio of the protocol is dynamically rebalanced based on the market price of the FRAX stablecoin. If the price of FRAX is above $1, then the collateral ratio (CR) decreases ("decollateralization"). If the price of FRAX is below $1 then the CR increases ("recollateralization"). The protocol always [honors redemptions of FRAX at the $1 peg](https://docs.frax.finance/minting-and-redeeming), but since the CR is dynamic, it must fund redemptions of FRAX by minting Frax Share tokens (FXS) for the remainder of the value. For example, at a 85% CR, every redeemed FRAX gives the user $0.85 USDC and $0.15 of minted FXS. It is a trivial implementation detail whether the protocol returns to the redeemer $0.15 worth of FXS directly or atomically sells the FXS for collateral onchain to return the full $1 of value in collateral – the economic implementation is the same.

FRAX

#### This base mechanism can be abstracted down to the following: 1. Decollateralize - Lower the CR by some increment $$x$$ every time $$t$$ if FRAX > $1 2. Equilibrium - Don't change the CR if FRAX = $1 3. Recollateralize - Increase the CR by some increment $$x$$ every time $$t$$ if FRAX < $1 At its fundamental core, the Frax Protocol is a banking algorithm that adjusts its balance sheet ratio based on the market's pricing of FRAX. The collateral ratio is simply the ratio of the protocol's capital (collateral) over its liabilities (FRAX stablecoins). The market 'votes' on what this ratio should be by selling/exiting the stablecoin if it's too low (thereby slightly pushing the price below $1) or by continuing to demand FRAX (thereby slightly pushing the price above $1). This decollateralization and recollateralization helps find an equilibrium reserve requirement for the protocol to keep a very tight peg and maximize capital efficiency of money creation. **By definition, the protocol mints the exact amount of FRAX stablecoins the market demands at the exact collateral ratio the market demands for $1 FRAX.** # Staking Contracts Allows staking Uniswap trading pair liquidity pool tokens in exchange for FXS rewards. ⚠️ This page only applies to very early farms, though many newer farms share features and function names ⚠️ Based on Synthetix's staking contract: ## Description Frax users are able to stake in select Uniswap liquidity pool tokens in exchange for FXS rewards. Future pools and incentives can be added by governance. ## Deployment *Liquidity Pool Tokens (LP)* Uniswap FRAX/WETH LP: `0xFD0A40Bc83C5faE4203DEc7e5929B446b07d1C76` Uniswap FRAX/USDC LP: `0x97C4adc5d28A86f9470C70DD91Dc6CC2f20d2d4D` Uniswap FRAX/FXS LP: `0xE1573B9D29e2183B1AF0e743Dc2754979A40D237` Uniswap FXS/WETH LP: `0xecBa967D84fCF0405F6b32Bc45F4d36BfDBB2E81` *Staking Contracts* Uniswap FRAX/WETH staking: `0xD875628B942f8970De3CcEaf6417005F68540d4f` Uniswap FRAX/USDC staking: `0xa29367a3f057F3191b62bd4055845a33411892b6` Uniswap FRAX/FXS staking: `0xda2c338350a0E59Ce71CDCED9679A3A590Dd9BEC` Uniswap FXS/WETH staking (deprecated): `0xDc65f3514725206Dd83A8843AAE2aC3D99771C88` ## State Variables ``` FRAXStablecoin private FRAX ``` Instance of the FRAX contract. ``` ERC20 public rewardsToken ``` Instance for the reward token. ``` ERC20 public stakingToken ``` Instance for the staking token. ``` uint256 public periodFinish ``` Block when the staking period will finish. ``` uint256 public rewardRate ``` Maximum reward per second. ``` uint256 public rewardsDuration ``` Reward period, in seconds. ``` uint256 public lastUpdateTime ``` Last timestamp where the contract was updated / state change. ``` uint256 public rewardPerTokenStored ``` Actual reward per token in the current period. ``` uint256 public locked_stake_max_multiplier ``` Maximum boost / weight multiplier for locked stakes. ``` uint256 public locked_stake_time_for_max_multiplier ``` The time, in seconds, to reach `locked_stake_max_multiplier` . ``` uint256 public locked_stake_min_time ``` Minimum staking time for a locked staked, in seconds. ``` string public locked_stake_min_time_str ``` String version is `locked_stake_min_time_str` . ``` uint256 public cr_boost_max_multiplier ``` Maximum boost / weight multiplier from the collateral ratio (CR). This is applied to both locked and unlocked stakes. ``` mapping(address => uint256) public userRewardPerTokenPaid ``` Keeps track of when an address last collected a reward. If they collect it some time later, they will get the correct amount because `rewardPerTokenStored` is constantly varying. ``` mapping(address => uint256) public rewards ``` Current rewards balance for a given address. ``` uint256 private _staking_token_supply ``` Total amount of pool tokens staked . ``` uint256 private _staking_token_boosted_supply ``` `_staking_token_supply` with the time and CR boosts accounted for. This is not an actual amount of pool tokens, but rather a 'weighed denominator'. ``` mapping(address => uint256) private _balances ``` Balance of pool tokens staked for a given address. ``` mapping(address => uint256) private _boosted_balances ``` `_balances` , but with the time and CR boosts accounted for, like `_staking_token_boosted_supply`. ``` mapping(address => LockedStake[]) private lockedStakes ``` Gives a list of locked stake lots for a given address. ``` struct LockedStake { bytes32 kek_id; uint256 start_timestamp; uint256 amount; uint256 ending_timestamp; uint256 multiplier; // 6 decimals of precision. 1x = 1000000 } ``` A locked stake 'lot'. ## **View Functions** **totalSupply** ``` totalSupply() external override view returns (uint256) ``` Get the total number of staked liquidity pool tokens. **stakingMultiplier** ``` stakingMultiplier(uint256 secs) public view returns (uint256) ``` Get the time-based staking multiplier, given the `secs` length of the stake. **crBoostMultiplier** ``` crBoostMultiplier() public view returns (uint256) ``` Get the collateral ratio (CR) - based staking multiplier. **stakingTokenSupply** ``` stakingTokenSupply() external view returns (uint256) ``` same as totalSupply(). **balanceOf** ``` balanceOf(address account) external override view returns (uint256) ``` Get the amount of staked liquidity pool tokens for a given `account`. **boostedBalanceOf** ``` boostedBalanceOf(address account) external view returns (uint256) ``` Get the boosted amount of staked liquidity pool tokens for a given `account`. Boosted accounts for the CR and time-based multipliers. **lockedBalanceOf** ``` lockedBalanceOf(address account) public view returns (uint256) ``` Get the amount of locked staked liquidity pool tokens for a given `account` . **unlockedBalanceOf** ``` unlockedBalanceOf(address account) external view returns (uint256) ``` Get the amount of unlocked / free staked liquidity pool tokens for a given `account` . **lockedStakesOf** ``` lockedStakesOf(address account) external view returns (LockedStake[] memory) ``` Return an array of all the locked stake 'lots' for **stakingDecimals** ``` stakingDecimals() external view returns (uint256) ``` Returns the `decimals()` for `stakingToken` . **rewardsFor** ``` rewardsFor(address account) external view returns (uint256) ``` Get the amount of FXS rewards for a given `account` . **lastTimeRewardApplicable** ``` lastTimeRewardApplicable() public override view returns (uint256) ``` Used internally to keep track of `rewardPerTokenStored` . **rewardPerToken** ``` rewardPerToken() public override view returns (uint256) ``` The current amount of FXS rewards for staking a liquidity pool token. **earned** ``` earned(address account) public override view returns (uint256) ``` Returns the amount of unclaimed FXS rewards for a given `account` . **getRewardForDuration** ``` getRewardForDuration() external override view returns (uint256) ``` Calculates the FXS reward for a given `rewardsDuration` period. ## Mutative Functions **stake** ``` stake(uint256 amount) external override nonReentrant notPaused updateReward(msg.sender) ``` Stakes some Uniswap liquidity pool tokens. These tokens are freely withdrawable and are only boosted by the `crBoostMultiplier()`**.** **stakeLocked** ``` stakeLocked(uint256 amount, uint256 secs) external nonReentrant notPaused updateReward(msg.sender) ``` Stakes some Uniswap liquidity pool tokens and also locks them for the specified `secs` . In return for having their tokens locked, the staker's base `amount` will be multiplied by a linear time-based multiplier, which ranges from 1 at `secs` = 0 to `locked_stake_max_multiplier` at `locked_stake_time_for_max_multiplier`**.** The staked value is also multiplied by the `crBoostMultiplier()` . This multiplied value is added to `_boosted_balances` and acts as a weighted amount when calculating the staker's share of a given period reward. **withdraw** ``` withdraw(uint256 amount) public override nonReentrant updateReward(msg.sender) ``` Withdraw unlocked Uniswap liquidity pool tokens. **withdrawLocked** ``` withdrawLocked(bytes32 kek_id) public nonReentrant updateReward(msg.sender) ``` Withdraw locked Uniswap liquidity pool tokens. Will fail if the staking time for the specific `kek_id` staking lot has not elapsed yet. **getReward** ``` getReward() public override nonReentrant updateReward(msg.sender) ``` Claim FXS rewards. **exit** ``` exit() external override ``` Withdraw all unlocked pool tokens and also collect rewards. **renewIfApplicable** ``` renewIfApplicable() external ``` Renew a reward period if the period's finish time has completed. Calls `retroCatchUp()` . **retroCatchUp** ``` retroCatchUp() internal ``` Renews the period and updates `periodFinish` , `rewardPerTokenStored` , and `lastUpdateTime` . ## Restricted Functions **notifyRewardAmount** ``` notifyRewardAmount(uint256 reward) external override onlyRewardsDistribution updateReward(address(0)) ``` This notifies people (via the event `RewardAdded` ) that the reward is being changed. **recoverERC20** ``` recoverERC20(address tokenAddress, uint256 tokenAmount) external onlyOwner ``` Added to support recovering LP Rewards from other systems to be distributed to holders. **setRewardsDuration** ``` setRewardsDuration(uint256 _rewardsDuration) external onlyOwner ``` Set the duration of the rewards period. **setLockedStakeMaxMultiplierUpdated** ``` setLockedStakeMaxMultiplierUpdated(uint256 _locked_stake_max_multiplier) external onlyOwner ``` Set the maximum multiplier for locked stakes. **setLockedStakeTimeForMaxMultiplier** ``` setLockedStakeTimeForMaxMultiplier(uint256 _locked_stake_time_for_max_multiplier) external onlyOwner ``` Set the time, in seconds, when the locked stake multiplier reaches `locked_stake_max_multiplier` . **setLockedStakeMinTime** ``` setLockedStakeMinTime(uint256 _locked_stake_min_time) external onlyOwner ``` Set the minimum time, in seconds, of a locked stake. **setMaxCRBoostMultiplier** ``` setMaxCRBoostMultiplier(uint256 _max_boost_multiplier) external onlyOwner ``` aaa **initializeDefault** ``` initializeDefault() external onlyOwner ``` Intended to only be called once in the lifetime of the contract. Initializes `lastUpdateTime` and `periodFinish` . ## Modifiers **updateReward** ``` updateReward(address account) ``` Calls `retroCatchUp()` , if applicable, and otherwise syncs `rewardPerTokenStored` and `lastUpdateTime` . Also, syncs the `rewards` and `userRewardPerTokenPaid` for the provided `account` . # FRAX ABI & Token Addresses Modified ERC-20 Contract representing the FRAX stablecoin. ## Deployments
ChainAddress
Arbitrum0x17FC002b466eEc40DaE837Fc4bE5c67993ddBd6F
Aurora0xE4B9e004389d91e4134a28F19BD833cBA1d994B6
Avalanche0xD24C2Ad096400B6FBcd2ad8B24E7acBc21A1da64
Base (LayerZero)0x909DBdE1eBE906Af95660033e478D59EFe831fED
Blast (LayerZero)0x909DBdE1eBE906Af95660033e478D59EFe831fED
Boba0x7562F525106F5d54E891e005867Bf489B5988CD9
BSC0x90C97F71E18723b0Cf0dfa30ee176Ab653E89F40
Ethereum (native)0x853d955aCEf822Db058eb8505911ED77F175b99e
Ethereum (LayerZero)0x909DBdE1eBE906Af95660033e478D59EFe831fED
Evmos0xE03494D0033687543a80c9B1ca7D6237F2EA8BD8
Fantom0xdc301622e621166BD8E82f2cA0A26c13Ad0BE355
Fraxtal (Native)0xFc00000000000000000000000000000000000001
Fraxtal (LayerZero)0x80eede496655fb9047dd39d9f418d5483ed600df
Harmony0xFa7191D292d5633f702B0bd7E3E3BcCC0e633200
Linea (Axelar)0x406cde76a3fd20e48bc1e0f60651e60ae204b040
Mantle (Axelar)0x406Cde76a3fD20e48bc1E0F60651e60Ae204B040
Metis (LayerZero)0x909DBdE1eBE906Af95660033e478D59EFe831fED
Mode (LayerZero)0x80eede496655fb9047dd39d9f418d5483ed600df
Moonbeam0x322E86852e492a7Ee17f28a78c663da38FB33bfb
Moonriver0x1A93B23281CC1CDE4C4741353F3064709A16197d
Optimism0x2E3D870790dC77A83DD1d18184Acc7439A53f475
Polygon0x45c32fA6DF82ead1e2EF74d17b76547EDdFaFF89
Sei (LayerZero)0x80eede496655fb9047dd39d9f418d5483ed600df
Scroll (Axelar)0x406cde76a3fd20e48bc1e0f60651e60ae204b040
SolanaFR87nWEUxVgerFGhZM8Y4AggKGLnaXswr1Pd8wZ4kZcp
TRONTBD
X-Layer (LayerZero)0x80eede496655fb9047dd39d9f418d5483ed600df
## State Variables #### ERC-20 (Inherited) #### AccessControl (Inherited) \ \ **NOTE: FRAX & FXS contracts have no pause or blacklist controls in any way (including system contracts).** #### FRAX-Specific ``` enum PriceChoice { FRAX, FXS } ``` An enum declaring FRAX and FXS. Used with oracles. ``` ChainlinkETHUSDPriceConsumer eth_usd_pricer ``` Instance for the Chainlink ETH / USD trading. Combined with FRAX / WETH, FXS / WETH, collateral / FRAX, and collateral / FXS trading pairs, can be used to calculate FRAX/FXS/Collateral prices in USD. ``` uint8 eth_usd_pricer_decimals ``` Decimals for the Chainlink ETH / USD trading pair price. ``` UniswapPairOracle fraxEthOracle ``` Instance for the FRAX / WETH Uniswap pair price oracle. ``` UniswapPairOracle fxsEthOracle ``` Instance for the FXS / WETH Uniswap pair price oracle. ``` address[] public owners ``` Array of owner address, who have privileged actions. ``` address governance_address ``` Address of the governance contract. ``` address public creator_address ``` Address of the contract creator. ``` address public timelock_address ``` Address of the timelock contract. ``` address public fxs_address ``` Address of the FXS contract ``` address public frax_eth_oracle_address ``` Address for the `fraxEthOracle` . ``` address public fxs_eth_oracle_address ``` Address for the `fxsEthOracle` . ``` address public weth_address ``` Address for the canonical wrapped-Ethereum (WETH) contract. Should be `0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2` for the mainnet. ``` address public eth_usd_consumer_address ``` Address for the `ChainlinkETHUSDPriceConsumer` . ``` uint256 public genesis_supply ``` Genesis supply of FRAX. Should be a small nonzero amount. Most of the FRAX supply will come from minting, but a small amount is needed initially to prevent divide-by-zero errors in various functions. ``` address[] frax_pools_array ``` Array of all the `FraxPool` contract addresses. ``` mapping(address => bool) public frax_pools ``` Essentially the same as `frax_pools_array` , but in mapping form. Useful for gas savings in various functions like `globalCollateralValue()` . ``` uint256 public global_collateral_ratio ``` The current ratio of FRAX to collateral, over all `FraxPool` s. ``` uint256 public redemption_fee ``` The fee for redeeming FRAX for FXS and/or collateral. Also the fee for buying back excess collateral with FXS. See the `FraxPool` contract for usage. ``` uint256 public minting_fee ``` The fee for minting FRAX from FXS and/or collateral. See the `FraxPool` contract for usage. ``` address public DEFAULT_ADMIN_ADDRESS ``` Set in the constructor. Used in `AccessControl` . ``` bytes32 public constant COLLATERAL_RATIO_PAUSER ``` A constant used in the pausing of the collateral ratio. ``` bool public collateral_ratio_paused ``` Whether or not the collateral ratio is paused. ## View Functions **oracle\_price** ``` oracle_price(PriceChoice choice) internal view returns (uint256) ``` Get the FRAX or FXS price, in USD. **frax\_price** ``` frax_price() public view returns (uint256) ``` Returns the price for FRAX from the FRAX-ETH Chainlink price oracle. **fxs\_price** ``` fxs_price() public view returns (uint256) ``` Returns the price for FXS from the FXS-ETH Chainlink price oracle. **frax\_info** ``` frax_info() public view returns (uint256, uint256, uint256, uint256, uint256, uint256, uint256) ``` Returns some commonly-used state variables and computed values. This is needed to avoid costly repeat calls to different getter functions. It is cheaper gas-wise to just dump everything and only use some of the info. **globalCollateralValue** ``` globalCollateralValue() public view returns (uint256) ``` Iterate through all FRAX pools and calculate all value of collateral in all pools globally. This uses the oracle price of each collateral. ## Public Functions **refreshCollateralRatio** ``` refreshCollateralRatio() public ``` This function checks the price of FRAX and refreshes the collateral ratio if the price is not $1. If the price is above $1, then the ratio is lowered by .5%. If the price is below $1, then the ratio is increased by .5%. Anyone can poke this function to change the ratio. This function can only be called once every hour. ## Restricted Functions **mint** ``` mint(uint256 amount) public virtual onlyByOwnerOrGovernance ``` Public implementation of internal \_mint(). **pool\_burn\_from** ``` pool_burn_from(address b_address, uint256 b_amount) public onlyPools ``` Used by pools when user redeems. **pool\_mint** ``` pool_mint(address m_address, uint256 m_amount) public onlyPools ``` This function is what other frax pools will call to mint new FRAX. **addPool** ``` addPool(address pool_address) public onlyByOwnerOrGovernance ``` Adds collateral addresses supported, such as tether and busd, must be ERC20. **removePool** ``` removePool(address pool_address) public onlyByOwnerOrGovernance ``` Remove a pool. **setOwner** ``` setOwner(address owner_address) public onlyByOwnerOrGovernance ``` Sets the admin of the contract **setFraxStep** ``` setFraxStep(uint256 _new_step) public onlyByOwnerOrGovernance ``` Sets the amount that the collateral ratio will change by upon an execution of refreshCollateralRatio(), **setPriceTarget** ``` setPriceTarget(uint256 _new_price_target) public onlyByOwnerOrGovernance ``` Set the price target to be used for refreshCollateralRatio() (does not affect minting/redeeming). **setRefreshCooldown** ``` setRefreshCooldown(uint256 _new_cooldown) public onlyByOwnerOrGovernance ``` Set refresh cooldown for refreshCollateralRatio(). **setRedemptionFee** ``` setRedemptionFee(uint256 red_fee) public onlyByOwnerOrGovernance ``` Set the redemption fee. **setMintingFee** ``` setMintingFee(uint256 min_fee) public onlyByOwnerOrGovernance ``` Set the minting fee. **setFXSAddress** ``` setFXSAddress(address _fxs_address) public onlyByOwnerOrGovernance ``` Set the FXS address. **setETHUSDOracle** ``` setETHUSDOracle(address _eth_usd_consumer_address) public onlyByOwnerOrGovernance ``` Set the ETH / USD oracle address. **setFRAXEthOracle** ``` setFRAXEthOracle(address _frax_addr, address _weth_address) public onlyByOwnerOrGovernance ``` Sets the FRAX / ETH Uniswap oracle address **setFXSEthOracle** ``` setFXSEthOracle(address _fxs_addr, address _weth_address) public onlyByOwnerOrGovernance ``` Sets the FXS / ETH Uniswap oracle address **toggleCollateralRatio** ``` toggleCollateralRatio() public onlyCollateralRatioPauser ``` Toggle pausing / unpausing the collateral ratio. ## Events **FRAXBurned** ``` FRAXBurned(address indexed from, address indexed to, uint256 amount) ``` Emitted when FRAX is burned, usually from a redemption by the pool. ## Modifiers **onlyCollateralRatioPauser** ``` onlyCollateralRatioPauser() ``` Restrict actions to the designated collateral ratio pauser. **onlyPools** ``` onlyPools() ``` Restrict actions to pool contracts, e.g. minting new FRAX. **onlyByGovernance** ``` onlyByGovernance() ``` Restrict actions to the governance contract, e.g. setting the minting and redemption fees, as well as the oracle and pool addresses. **onlyByOwnerOrGovernance** ``` onlyByOwnerOrGovernance() ``` Restrict actions to the governance contract or owner account(s), e.g. setting the minting and redemption fees, as well as the oracle and pool addresses. # Frax V1 Pool ABI & Addresses Contract used for minting and redeeming FRAX, as well as buying back excess collateral. ⚠️ This pool has been deprecated in favor of FRAX V2 and later mechanisms ⚠️ ## Deployment Frax Pool contracts are deployed and permissioned from the governance system, meaning that a new type of collateral may be added at any time after a governance proposal succeeds and is executed. The current pool is USDC, with further collateral types open for future pools. USDC: [`0x3C2982CA260e870eee70c423818010DfeF212659`](https://etherscan.io/address/0x3C2982CA260e870eee70c423818010DfeF212659) ## Description A Frax Pool is the smart contract that mints FRAX tokens to users for placing collateral or returns collateral by redeeming FRAX sent into the contract. Each Frax Pool has a different type of accepted collateral. Frax Pools can be in any kind of cryptocurrency, but stablecoins are easiest to implement due to their small fluctuations in price. Frax is designed to accept any type of cryptocurrency as collateral, but low volatility pools are preferred at inception since they do not change the collateral ratio erratically. There are promising new projects, such as Reflex Bonds, which dampen the volatility of their underlying crypto assets. Reflex Bonds could make for ideal FRAX collateral in the future. New Frax Pools can be added through FXS governance votes. Each pool contract has a pool ceiling (the maximum allowable collateral that can be stored to mint FRAX) and a price feed for the asset. The initial Frax Pool at genesis will be USDC (USD Coin) and USDT (Tether) due to their large market capitalization, stability, and availability on Ethereum. The pools operate through permissioned calls to the FRAXStablecoin (FRAX) and FRAXShare (FXS) contracts to mint and redeem the protocol tokens. ### Minting and Redeeming FRAX The contract has 3 minting functions: mint1t1FRAX(), mintFractionalFRAX(), and mintAlgorithmicFRAX(). The contract also has 3 redemption functions that mirror the minting functions: redeem1t1FRAX(), redeemFractionalFRAX(), redeemAlgorithmicFRAX(). \ \ The functions are separated into 1 to 1, fractional, and algorithmic phases to optimize gas usage. The 1 to 1 minting and redemption functions are only available when the collateral ratio is 100%. The fractional minting and redemption functions are only available between a collateral ratio of 99.99% and 0.01%. The algorithmic minting and redemption functions are only available at a ratio of 0%. ### Slippage Each of the minting and redeeming functions also has an `AMOUNT_out_min` parameter that specifies the minimum units of tokens expected from the transaction. This acts as a limit for slippage tolerance when submitting transactions, as the prices may update from the time a transaction is created to the time it is included in a block. ## State Variables #### AccessControl (Inherited) #### FraxPool-Specific ``` ERC20 private collateral_token ``` Instance for the collateral token in the pool. ``` address private collateral_address ``` Address of the collateral token. ``` address[] private owners ``` List of the pool owners. ``` address private oracle_address ``` Address of the oracle contract. ``` address private frax_contract_address ``` Address of the FRAX contract. ``` address private fxs_contract_address ``` Address of the FXS contract. ``` address private timelock_address ``` Address of the timelock contract. ``` FRAXShares private FXS ``` Instance of the FXS contract. ``` FRAXStablecoin private FRAX ``` Instance of the FRAX contract. ``` UniswapPairOracle private oracle ``` Instance of the oracle contract. ``` mapping (address => uint256) private redeemFXSBalances ``` Keeps track of redemption balances for a given address. A redeemer cannot both request redemption and actually redeem their FRAX in the same block. This is to prevent flash loan exploits that could crash FRAX and/or FXS prices. They have to wait until the next block. This particular variable is for the FXS portion of the redemption. ``` mapping (address => uint256) private redeemCollateralBalances ``` Keeps track of redemption balances for a given address. A redeemer cannot both request redemption and actually redeem their FRAX in the same block. This is to prevent flash loan exploits that could crash FRAX and/or FXS prices. They have to wait until the next block. This particular variable is for the collateral portion of the redemption. ``` uint256 public unclaimedPoolCollateral ``` Sum of the `redeemCollateralBalances`. ``` uint256 public unclaimedPoolFXS ``` Sum of the `redeemFXSBalances`. ``` mapping (address => uint256) lastRedeemed ``` Keeps track of the last block a given address redeemed. ``` uint256 private pool_ceiling ``` Maximum amount of collateral the pool can take. ``` bytes32 private constant MINT_PAUSER ``` `AccessControl` role for the mint pauser. ``` bytes32 private constant REDEEM_PAUSER ``` `AccessControl` role for the redeem pauser. ``` bytes32 private constant BUYBACK_PAUSER ``` `AccessControl` role for the buyback pauser. ``` bool mintPaused = false ``` Whether or not minting is paused. ``` bool redeemPaused = false ``` Whether or not redeem is paused. ``` bool buyBackPaused = false ``` Whether or not buyback is paused. ## View Functions **unclaimedFXS** ``` unclaimedFXS(address _account) public view returns (uint256) ``` Return the total amount of unclaimed FXS. **unclaimedCollateral** ``` unclaimedCollateral(address _account) public view returns (uint256) ``` Return the total amount of unclaimed collateral. **collatDollarBalance** ``` collatDollarBalance() public view returns (uint256) ``` Return the pool's total balance of the collateral token, in USD. **availableExcessCollatDV** ``` availableExcessCollatDV() public view returns (uint256) ``` Return the pool's excess balance of the collateral token (over that required by the collateral ratio), in USD. **getCollateralPrice** ``` getCollateralPrice() public view returns (uint256) ``` Return the price of the pool's collateral in USD. ## Public Functions **mint1t1FRAX** ``` mint1t1FRAX(uint256 collateral_amount_d18) external notMintPaused ``` Mint FRAX from collateral. Valid only when the collateral ratio is 1. **mintFractionalFRAX** ``` mintFractionalFRAX(uint256 collateral_amount, uint256 fxs_amount) external notMintPaused ``` Mint FRAX from collateral and FXS. Valid only when the collateral ratio is between 0 and 1. **mintAlgorithmicFRAX** ``` mintAlgorithmicFRAX(uint256 fxs_amount_d18) external notMintPaused ``` Mint FRAX from FXS. Valid only when the collateral ratio is 0. **redeem1t1FRAX** ``` redeem1t1FRAX(uint256 FRAX_amount) external notRedeemPaused ``` Redeem collateral from FRAX. Valid only when the collateral ratio is 1. Must call `collectionRedemption()` later to collect. **redeemFractionalFRAX** ``` redeemFractionalFRAX(uint256 FRAX_amount) external notRedeemPaused ``` Redeem collateral and FXS from FRAX. Valid only when the collateral ratio is between 0 and 1. Must call `collectionRedemption()` later to collect. **redeemAlgorithmicFRAX** ``` redeemAlgorithmicFRAX(uint256 FRAX_amount) external notRedeemPaused ``` Redeem FXS from FRAX. Valid only when the collateral ratio is 0. Must call `collectionRedemption()` later to collect. **collectRedemption** ``` collectRedemption() public ``` After a redemption happens, transfer the newly minted FXS and owed collateral from this pool contract to the user. Redemption is split into two functions to prevent flash loans from being able to take out FRAX / collateral from the system, use an AMM to trade the new price, and then mint back into the system. **buyBackFXS** ``` buyBackFXS(uint256 FXS_amount) external ``` Function can be called by an FXS holder to have the protocol buy back FXS with excess collateral value from a desired collateral pool. This can also happen if the collateral ratio > 1 **recollateralizeAmount** ``` recollateralizeAmount() public view returns (uint256 recollateralization_left) ``` When the protocol is recollateralizing, we need to give a discount of FXS to hit the new CR target. Returns value of collateral that must increase to reach recollateralization target (if 0 means no recollateralization) **recollateralizeFrax** ``` recollateralizeFrax(uint256 collateral_amount_d18) public ``` Thus, if the target collateral ratio is higher than the actual value of collateral, minters get FXS for adding collateral. This function simply rewards anyone that sends collateral to a pool with the same amount of FXS + .75%. Anyone can call this function to recollateralize the protocol and take the hardcoded .75% arb opportunity ## Restricted Functions **toggleMinting** ``` toggleMinting() external onlyMintPauser ``` Toggle the ability to mint. **toggleRedeeming** ``` toggleRedeeming() external onlyRedeemPauser ``` Toggle the ability to redeem. **toggleBuyBack** ``` toggleBuyBack() external onlyBuyBackPauser ``` Toggle the ability to buyback. **setPoolCeiling** ``` setPoolCeiling(uint256 new_ceiling) external onlyByOwnerOrGovernance ``` Set the `pool_ceiling`, which is the total units of collateral that the pool contract can hold. **setOracle** ``` setOracle(address new_oracle) external onlyByOwnerOrGovernance ``` Set the `oracle_address`. **setCollateralAdd** ``` setCollateralAdd(address _collateral_address) external onlyByOwnerOrGovernance ``` Set the `collateral_address`. **addOwner** ``` addOwner(address owner_address) external onlyByOwnerOrGovernance ``` Add an address to the array of owners. **removeOwner** ``` removeOwner(address owner_address) external onlyByOwnerOrGovernance ``` Remove an owner from the owners array. ## Modifiers **onlyByOwnerOrGovernance** ``` onlyByOwnerOrGovernance() ``` Restrict actions to the governance contract or the owner(s). **notRedeemPaused** ``` notRedeemPaused() ``` Ensure redemption is not paused. **notMintPaused** ``` notMintPaused() ``` Ensure minting is not paused. # Core Frax Multisigs ## Ethereum Mainnet #### Frax Comptrollers
ChainAddress
Arbitrum0xe61D9ed1e5Dc261D1e90a99304fADCef2c76FD10
Aurora0x85F61CC39dB983948671b03B8EcB36877d9A337d
Avalanche0xc036Caff65c1A31eAa53e60F6E17f1E6689937AA
Base0xCBfd4Ef00a8cf91Fd1e1Fe97dC05910772c15E53
Boba0x3849Ff242Ff385F5124e6420BE681963d3977685
Boba BNB0x1b0772073Fc00de6dD760F734e94DB526F9B1307
Blast0x33A133020b2C2CD41a24F74033B11EC2fC0bF97a
BSC0x8811Da0385cCf1848B21475A42eA4D07Fc5d964a
Ethereum0xB1748C79709f4Ba2Dd82834B8c82D4a505003f27
Evmos0x18B34258F0972b19C3B757B2169b42b4D5b0856A
Fantom0xE838c61635dd1D41952c68E47159329443283d90
Fraxtal0xC4EB45d80DC1F079045E75D5d55de8eD1c1090E6
Harmony0x5D91bA85cfbC0A3673F312f3FD0BA75a85AD73e6
Linea0x6b603B58d7781a5967172e2FEa75f7E34c25F96d
Mantle0xC51585F9C1938fcE489da89d24d7A623d4BEDf35
Metis0xF4A4F32732F9B2fB84Ee28c58616946F3bF80F7d
Mode0x6336CFA6eDBeC2A459d869031DB77fC2770Eaa66
Moonbeam0x343e4f06BF240d22FbdFd4a2Fe5858BC66e79F12
Moonriver0x2bBbE751E8C36CD6c92767776067f8Dd3A21941f
Optimism0x0dF840dCbf1229262A4125C1fc559bd338eC9491
Polygon0xDCB5A4b6Ee39447D700F4FA3303B1d1c25Ea9cA7
Polygon zkEVM0x030BD43af99cb72B51dA233A73F7697Cd2461C0b
Scroll0x7efB8A3b929D1e12640Caf8E4889A3d08e4b9039
Sei0x0357D02fc95320b990322d3ff69204c3D251171b
SolanaFSRTW4KPGifKL8yKcZ8mfoR9mKtAjwZiTHbHwgix8AQo
TRONTNpqBqghn37FLcpWWQVcRAxuBvhUYu2FEB
zkSync0xd492dF0ce7905D7d91aE48F5e893AcAa38221486
#### Other Multisigs
NameAddress
Advisors0x874a873e4891fB760EdFDae0D26cA2c00922C404
Business Development0x11cC283d06FA762061df2B0D2f0787651ceef659
Community0x63278bF9AcdFC9fA65CFa2940b89A34ADfbCb4A1
Fraxtal L10xe0d7755252873c4eF5788f7f45764E0e17610508
Investors0xa95f86fE0409030136D6b82491822B3D70F890b3
Team0x8D4392F55bC76A046E443eb3bab99887F4366BB0
Treasury0x9AA7Db8E488eE3ffCC9CdFD4f2EaECC8ABeDCB48
## Layer Zero #### Comptrollers
ChainAddress
Base0xCBfd4Ef00a8cf91Fd1e1Fe97dC05910772c15E53
Blast0x33A133020b2C2CD41a24F74033B11EC2fC0bF97a
Fraxtal0x5f25218ed9474b721d6a38c115107428E832fA2E
Metis0xF4A4F32732F9B2fB84Ee28c58616946F3bF80F7d
Mode0x6336CFA6eDBeC2A459d869031DB77fC2770Eaa66
Sei0x0357D02fc95320b990322d3ff69204c3D251171b
SolanaFSRTW4KPGifKL8yKcZ8mfoR9mKtAjwZiTHbHwgix8AQo
X-Layer0xe7Cc52f0C86f4FAB6630f1E26167B487fbF66a61
# AMO Overview A framework for composable, autonomous central banking puzzle pieces The second (V2) expansion of FRAX focused on the idea of fractional-algorithmic stability by introducing the idea of the “Algorithmic Market Operations Controller” (AMO). An AMO module is an autonomous contract(s) that enacts arbitrary monetary policy so long as it *does not change the FRAX price off its peg*. This means that AMO controllers can perform open market operations algorithmically (as in the name), but they cannot arbitrarily mint FRAX out of thin air and break the peg. This keeps FRAX’s base layer stability mechanism pure and untouched, which has been the core of what makes our protocol special and inspired other smaller projects. ## AMOs We can generalize the [V1 mechanism](/frax-v1-original/original-design) to any arbitrarily complex market operation to create a Turing-complete design space of stability mechanisms. Thus, each AMO can be thought of as a central bank money puzzle piece. Every AMO has 3 properties: 1. Decollateralize - the portion of the strategy which lowers the CR 2. Market operations - the portion of the strategy that is run in equilibrium and doesn't change the CR 3. Recollateralize - the portion of the strategy which increases the CR With the above framework clearly defined, it's now easy to see how Frax V1 is the simplest form of an AMO. It is essentially the base case of any possible AMO. In V1, decollateralization allows for expansion of the money supply and excess collateral to flow to burning FXS. Recollateralization mints FXS to increase the collateral ratio and lower liabilities (redemptions of FRAX). \ \ The base layer fractional-algorithmic mechanism is always running just like before. If FRAX price is above the peg, the CR is lowered, FRAX supply expands like usual, and AMO controllers keep running. If the CR is lowered to the point that the peg slips, the AMOs have predefined recollateralize operations which increases the CR. The system recollateralizes just like before as protocol liabilities (stablecoins) are redeemed and the CR goes up to return to the peg. This allows all AMOs to operate with input from market forces and preserve the full design specs of the V1 base case. AMOs enable FRAX to become one of the most powerful stablecoin protocols by creating maximum flexibility and opportunity without altering the base stability mechanism that made FRAX the leader of the algorithmic stablecoin space. AMO modules open a modular design space that will allow for constant upgrades and improvements without jeopardizing design elegance, composability, or increasing technical complexity. Lastly, because AMOs are a complete "mechanism-in-a-box," anyone can propose, build, and create AMOs which can then be deployed with governance as long as they adhere to the above specifications. #### References and Resources/Links 1. [Original Announcement Post](https://samkazemian.medium.com/frax-v2-algorithmic-market-operations-b84521ed7133) 2. [Quick Twitter explainer thread](https://twitter.com/samkazemian/status/1380022644280414212) # AMO Minter Frax's updated structure for minting FRAX and processing mints & redeems ⚠️ This contract is deprecated in favor of FRAX V3 mechanisms ⚠️ In October 2021, the system moved to an updated model using a FraxPoolV3 system contract (`0x2fE065e6FFEf9ac95ab39E5042744d695F560729`) that handles responsive mints & redeems for the protocol with a lower attack surface. Through this new pool, the Frax AMO Minter contract was designed to do algorithmic minting according to the specifications of new AMOs attached to the FraxPoolV3. A consequence of this was that the old AMOs that were built on the FraxPoolV2 (`0x1864Ca3d47AaB98Ee78D11fc9DCC5E7bADdA1c0d`) were upgraded to new versions using the FraxPoolV3 collateral and minting system, all controlled through the comptroller msig & timelock system. The new system allows for automated collection of yields & return of collateral to the FraxPoolV3, of which the profit may be distributed to FXS holders by the FXS1559 AMO. ### Contract Addresses The AMO Minter is deployed at the following address on the Ethereum mainnet: `0xcf37B62109b537fa0Cb9A90Af4CA72f6fb85E241`. # Collateral Investor Invests idle collateral into various DeFi vaults/protocols ⚠️ This AMO has been deprecated. Many of its functions have been moved to [V3 AMOs](/frax-v3-100-cr-and-more/amos) ⚠️\ \ The Collateral Investor AMO moves idle USDC collateral to select DeFi protocols that provide reliable yield. Currently, the integrated protocols include: Aave, Compound, and Yearn. More can be added by governance. The main requirement for this AMO is to be able to pull out invested collateral immediately with no waiting period in case of large FRAX redemptions. Collateral that is invested with an instant withdrawal ability does not count as lowering the CR of the protocol since it is spontaneously available to the protocol at all times. Nevertheless, the decollateralize function in the specs pulls out invested collateral starting with any time-delayed withdrawals (which there are none currently and not planned to be as of now).\ \ Any investment revenue generated that places the protocol above the CR is burned with FXS1559. FraxPoolInvestorForV2 (deprecated): [`0xEE5825d5185a1D512706f9068E69146A54B6e076`](https://etherscan.io/address/0xEE5825d5185a1D512706f9068E69146A54B6e076) ### AMO Specs 1. Decollateralize - Places idle collateral in various yield generating protocols. Investments that cannot be immediately withdrawn lower the CR calculation. Investments that can always be withdrawn at a 1 to 1 rate at all times such as Yearn USDC v2 and Compound do not count as lowering the CR. 2. Market operations - Compounds the investments at the CR. 3. Recollateralize - Withdraws investments from vaults to free up collateral for redemptions. 4. FXS1559 - Daily revenue that accrues from investments over the CR. # Curve A stableswap pool with liquidity controlled and owned predominantly by the protocol ⚠️ This specific AMO has been deprecated, but the underlying rationale (Curve/Convex protocol-owned liquidity to achieve peg stability and protocol income) and math is still used by newer AMOs. See [V3 AMOs](/frax-v3-100-cr-and-more/amos) ⚠️\ \ The Curve AMO puts FRAX and USDC collateral to work providing liquidity for the protocol and tightening the peg. Frax has deployed its [own FRAX3CRV metapool](https://etherscan.io/tx/0x1f2a0d4e1c1eca594bd7f27f9952480ccda422c3453e0c5074a63aa46a2ed628). This means that the Frax deployer address owns admin privileges to its own Curve pool. This allows the Curve AMO controller to set and collect admin fees for FXS holders and various future functions. The protocol can move idle USDC collateral or new FRAX to its own Curve pool to create even more liquidity and tighten the peg while earning trading revenue. CurveAMO (deprecated): [`0xbd061885260F176e05699fED9C5a4604fc7F2BDC`](https://etherscan.io/address/0xbd061885260F176e05699fED9C5a4604fc7F2BDC) ### AMO Specs 1. Decollateralize - Places idle collateral and newly minted FRAX into the FRAX3CRV pool. 2. Market operations - Accrues transaction fees, CRV rewards, and periodically rebalances the pool. The FRAX3CRV LP tokens are deposited into Yearn crvFRAX vault, Stake DAO, and Convex Finance for extra yield. 3. Recollateralize - Withdraws excess FRAX from pool first, then withdraws USDC to increase CR. 4. FXS1559 - Daily transaction fees and LP value accrued over the CR. (currently in development) ![A comparison of the Uniswap and Stableswap curves, taken from the Curve whitepaper](/files/-MWX0ujRjRza9qKPylvb) Curve's Stableswap invariant allows for dampened price volatility between stablecoin swaps when reserves are not extremely imbalanced, approximating a linear swap curve when doing so. ![Linear swap curve generalized to N coins](/files/-MWWwLwnlO4C_nvU8Ges) In cases of extreme imbalance, the invariant approaches the Uniswap constant-product curve. ![Constant-product swap curve generalized to N coins](/files/-MWWwSHq7XewbeLd48hX) The combination of two such curves allows for the expression of one or another, depending on what the ratio of the balances in the pool are, according to a coefficient. Using a dimensionless parameter $$XD^{n-1}$$ as the coefficient, one may generalize the combination of the two curves to N coins. ![Absolute magic](/files/-MWWwb84FHwdPmjHYla7) ## Curve AMO The protocol calculates the amount of underlying collateral the AMO has access to by finding the balance of USDC it can withdraw if the price of FRAX were to drop to the CR. Since FRAX is always backed by collateral at the value of the CR, it should never go below the value of the collateral itself. For example, FRAX should never go below $.85 at an 85% CR. This calculation is the safest and most conservative way to calculate the amount of collateral the Curve AMO has access to. This allows the Curve AMO to mint FRAX to place inside the pool in addition to USDC collateral to tighten the peg while knowing exactly how much collateral it has access to if FRAX were to break its peg. Additionally, the AMO’s overall strategy allows for optimizing the minimum FRAX supply Y such that selling all of Y at once into a Curve pool with Z TVL and A amplification factor will impact the price of FRAX by less than X%, where X is the CR’s band sensitivity. Said in another way, the Curve AMO can put FRAX+USDC into its own Curve pool and control TVL. Since the CR recollateralizes when FRAX price drops by more than 1 cent under $1, that means that there is some value of FRAX that can be sold directly into the Curve pool before the FRAX price slips by 1%. The protocol can have at least that amount of algorithmic FRAX circulating on the open market since a sale of that entire amount at once into the Curve pool’s TVL would not impact the price enough to cause the CR to move. These amounts are quite large and impressive when considering Curve’s stablecoin optimized curve. For example, a 330m TVL FRAX3Pool (assuming balanced underlying 3Pool) can support at minimum a $39.2m FRAX sell order without moving the price by more than 1 cent. If the CR band is 1% then the protocol should have at least 39.2m algorithmic FRAX in the open market at minimum. The above strategy is an extremely powerful market operation which would mathematically create a floor of algorithmic FRAX that can circulate without any danger of breaking the peg. \ \ Additionally, Curve allocates CRV tokens as rewards for liquidity providers to select pools (called gauge rewards). Since the Frax protocol will likely be the largest liquidity provider of the FRAX3CRV pool, it can allocate all its FRAX3CRV LP tokens into Curve gauges to earn a significant return. The CRV tokens held within the Curve AMO can be used to vote in future Curve DAO governance controlled by FXS holders. This essentially means that the more the protocol employs liquidity to its own Curve pool, the more of the Curve protocol it will own and control through its earned CRV rewards. The long term effect of the Curve AMO is that Frax could become a large governance participant in Curve itself. ### Smart Contract `iterate()` The iterate function calculates the balances of FRAX and 3CRV in the metapool in the hypothetical worst-case assumption of FRAX price falling to the CR. To start, the function takes the current live balances of the metapool and simulates an external arbitrageur swapping 10% of the current FRAX in the metapool until the price given is equal (or close to) the CR, swapping out the corresponding amount of 3CRV. This simulates the situation wherein the open-market price of FRAX falls to the CR, and the resulting 1-to-1 swap normally offered by the metapool is picked off by arbitrageurs until there is no more profit to be had by buying FRAX elsewhere for the CR price and selling it into the metapool. [Line 282](https://github.com/FraxFinance/frax-solidity/blob/master/contracts/Curve/CurveAMO.sol#L282) is the specific location where the price of FRAX is checked. Then, the metapool checks how much its LP tokens would withdraw in that worst-case scenarios in terms of the underlying FRAX and 3CRV. The ratio between the two is normally tilted roughly 10-to-1 in terms of FRAX withdrawable to 3CRV withdrawable. For the protocol's accounting of how much collateral it has, it values each 3CRV withdrawable at the underlying collateral value (i.e. how much USDC it can redeem for it) and each FRAX at the collateral ratio. Since the protocol never actually sends this much FRAX into circulation under normal circumstances, this is a highly conservative estimate on the amount of collateral it is actually entitled to in terms of USDC. To check scenarios of how much reserves would be indebted to the Curve AMO at other prices, one may simply adjust the `fraxFloor()` value in local testing through setting a `custom_floor`. # Uniswap v3 Deploying idle collateral to stable-stable pairs on Uni v3 with FRAX The key innovation of Uniswap v3's AMM algorithm allowing for LPs to deploy liquidity between specific price ranges allows for stablecoin-to-stablecoin pairs (e.g. FRAX-USDC) to accrue extremely deep liquidity within a tight peg. Compared to Uniswap v2, range orders in Uniswap v3 concentrate the liquidity instead of spreading out over an infinite price range. ![Taken from the Uniswap v3 whitepaper](/files/-MhFPP-uCKUJ4QnZR9Gm) The Uniswap v3 Liquidity AMO puts FRAX and collateral to work by providing liquidity to other stablecoins against FRAX. Since the AMO is able enter any position on Uni v3 and mint FRAX against it, it allows for expansion to any other stablecoin and later volatile collateral on Uni v3. Additionally, the function `collectFees()` can be periodically called to allocate AMO profits to market operations of excess collateral. UniV3LiquidityAMO (deprecated): [`0x3814307b86b54b1d8e7B2Ac34662De9125F8f4E6`](https://etherscan.io/address/0x3814307b86b54b1d8e7B2Ac34662De9125F8f4E6) UniV3LiquidityAMO\_V2: [`0xc91Bb4b0696e3b48c0C501B4ce8E7244Fc363A79`](https://etherscan.io/address/0xc91Bb4b0696e3b48c0C501B4ce8E7244Fc363A79) ### AMO Specs 1. Decollateralize - Deposits idle collateral and newly minted FRAX into the a Uni v3 pair. 2. Market operations - Accrues Uni v3 transaction fees and swaps between collateral types. 3. Recollateralize - Withdraws from the Uni v3 pairs, burns FRAX and returns USDC to increase CR. 4. FXS1559 - Daily transaction fees accrued over the CR. ### Derivation ![A diagram showing range-order virtualized reserves using the constant-product invariant](/files/-MhFXFIzSENjlb1eBzyo) All prices exist as ratios between one entity and another. Conventially, we select a currency as the shared unit-of-account in the denominator (e.g. USD) to compare prices for everyday goods and services. In Uniswap, prices are defined by the ratio of the amounts of reserves of $$x$$ to reserves of $$y$$ in the pool. Uniswap v3's range-order mechanic fits into the existing $$x\*y = k$$ constant-product market-making invariant (CPMM) by "virtualizing" the reserves at a specific price point, or `tick`. Through specifying which ticks a liquidity position is bounded by, range-orders are created that follow the constant-product invariant without having to spread the liquidity across the entire range$$(0, \infty)$$for a specific asset. A price in Uniswap v3 is defined by the value `1.0001` to the power of the tick value $$i$$. The boundaries for the prices of ticks can be represented by the algebraic group $$G = { g^i \mid i \in \mathbb{Z}, g = 1.0001}$$. This mechanism allows for easy conversion of integers to price boundaries, and has the convenience of discretiating each tick-price-boundary as one basis point (`0.01%`) in price from another. ![Defining price in terms of ticks](/files/-MhG9L6TjhMbf5voe_-7) Virtual reserves are tracked by tracking the `liquidity` and `tick` bounds of each position. Crossing a tick boundary, the liquidity $$L$$ available for that tick may change to reflect positions entering and leaving their respective price ranges. Within the tick boundaries, swaps change the price $$\sqrt{P}$$ according to the virtual reserves, i.e. it acts like the constant-product ($$x\*y=k$$) invariant. The virtual reserves `x` and `y` can be calculated from the liquidity and price: ![L: Liquidity; P: Price; x, y: reserves of X and Y](/files/-MhG7A3U3fRzIVsiE4sc) Note that the actual implementation uses a square root of the price, since it saves a square-root operation from calculating intra-tick swaps, and thus helps prevent rounding errors. ![Converting price to square root of ticks](/files/-MhI-eASpsUs5P-qWx_5) Liquidity can be thought of as a virtual $$k$$ in the $$x\*y=k$$ CPMM, while $$\Delta Y$$ corresponds to amount of asset $$Y$$ and $$\Delta\sqrt P$$ represents the intra-tick price slippage. ![Describing the relationship between liquidity, price, and the amount of one asset swapped](/files/-MhI310r4l25FcgdlRyl) Since $$L$$ is fixed for intra-tick swaps, $$\Delta X$$ and $$\Delta Y$$ can be calculated from the liquidity and square root of the price. When crossing over a tick, the swap must only slip until the $$\sqrt P$$ boundary, and then re-adjust the liquidity available for the next tick. # FRAX Lending Earns APY from lending out FRAX to DeFi platforms ⚠️ This AMO is deprecated. Most lending activities are now conducted via the [Fraxlend AMO](/frax-v3-100-cr-and-more/amos#fraxlend-amo). ⚠️\ \ This AMO mints FRAX into money markets such as Compound or CREAM to allow anyone to borrow FRAX by paying interest instead of the base minting mechanism. FRAX minted into money markets don’t enter circulation unless they are overcollateralized by a borrower through the money market so this AMO does not lower the direct collateral ratio (CR). This controller allows the protocol to directly lend FRAX and earn interest from borrowers through existing money markets. Effectively, this AMO is MakerDAO’s entire protocol in a single market operations contract. The cash flow from lending can be used to buy back and burn FXS (similar to how MakerDAO burns MKR from stability fees). Essentially the Lending AMO creates a new avenue to get FRAX into circulation by paying an interest rate set by the money market. FraxLendingAMO (deprecated): [`0x9507189f5B6D820cd93d970d67893006968825ef`](https://etherscan.io/address/0x9507189f5B6D820cd93d970d67893006968825ef) ### AMO Specs 1. Decollateralize - Mints FRAX into money markets. The CR does not lower by the amount of minted FRAX directly since all borrowed FRAX are overcollateralized. 2. Market operations - Accrues interest revenue from borrowers. 3. Recollateralize - Withdraws minted FRAX from money markets. 4. FXS1559 - Daily interest payments accrued over the CR. (currently in development) ### Adjusting Interest Rates and Capital Efficiency The AMO can increase or decrease the interest rate on borrowing FRAX by minting more FRAX (lower rates) or removing FRAX and burning it (increase rates). This is a powerful economic lever since it changes the cost of borrowing FRAX on all lenders. This permeates all markets since the AMO can mint and remove FRAX to target a specific rate. This also effectively makes the cost of shorting FRAX more or less expensive depending on which direction the protocol wishes to target. Additionally, the fractional-algorithmic design of the protocol allows for unmatched borrowing rates compared to other stablecoins. Because the Frax Protocol can mint FRAX stablecoins at will until the market responds with pricing FRAX at $.99 and recollateralizing the protocol, this means that money creation costs are minimal compared to other protocols. This creates unmatched, best-in-class rates for lending if the protocol decides to outcompete all other stablecoin rates. Thus, the AMO strategy can optimize for conditions for when to lower the rates (and also bring them under other stablecoin rates) and also increase rates in opposing conditions. Ironically, the lending rate on their own token is something other stablecoin projects have difficulty controlling. Frax has total control over this property through this AMO. # Decentralization Ratio (DR) Reducing reliance on centralized assets The Frax Decentralization Ratio (DR) is the ratio of decentralized collateral value over the total stablecoin supply backed/redeemable for those assets. Collateral with excessive off-chain risk (i.e. fiatcoins, securities, & custodial assets such as gold/oil etc) are counted as 0% decentralized. The DR goes through underlying constituent pieces of collateral that a protocol has claims on, not just what is inside its system contracts. The DR is a recursive function to find the base value of every asset. For example, FRAX3CRV LP is 50% FRAX so remove that, as you cannot back yourself with your own coin. The other half is 3CRV which is 33% USDC, 33% USDT, and 33% DAI. DAI itself is about 60% fiatcoins. So each $1 of FRAX3CRV LP only has about $.066 ($1 x 0.5 \* 0.33 \* 0.4) of value coming from decentralized sources. In contrast, Ethereum, as well as reward tokens like CVX and CRV, are counted as 100% decentralized. FRAX minted through Lending AMOs also counts as decentralized since borrowers overcollateralize their loan w/ crypto sOHM, RGT, etc. This is the same reason DAI's vaults give it high DR. The DR is a generalized algorithm that can be used to compute any stablecoin's excessive off-chain risk. Other stablecoins like LUSD are much easier to calculate: their DR is 100%. FEI is around 90% DR. For a list of assets backing FRAX, see [Frax Facts](https://facts.frax.finance/frax/balance-sheet). # Overview FRAX v3: The Final Stablecoin FRAX is a dollar-pegged stablecoin that uses “Algorithmic Market Operation” (AMO) smart contracts and permissionless, non-custodial subprotocols as stability mechanisms. The three main internal subprotocols used as stability mechanisms are [Fraxlend](https://docs.frax.finance/fraxlend/fraxlend-overview), a decentralized lending market, [Frax Bonds](/frax-v3-100-cr-and-more/fxbs) for peg stability, and [Fraxswap](https://docs.frax.finance/fraxswap/technical-specifications), an automated market maker (AMM) with special features. The primary external locations for stability include Curve and Uniswap V3 pools. Additional subprotocols and AMOs can be added with governance allowing FRAX to incorporate future stability mechanisms seamlessly as they are discovered.\ \ The V3 expansion of FRAX introduces the following concepts and benchmarks:\ \ **1) Full exogenous collateralization of FRAX:** The protocol will attempt to keep >=100% CR at all times. Starting in V3 and after [FIP188](https://gov.frax.finance/t/fip-188-increase-cr-to-100/2147), the Frax Protocol attempts to keep all FRAX stablecoins at a minimum of 100% collateralization ratio (CR) through AMO smart contracts and certain real world assets held by partner entities approved by the Frax Governance module ([frxGov](/governance/frax-governance-overview)). The FRAX CR is calculated as the value of exogenous collateral held on the [FRAX balance sheet](https://facts.frax.finance/frax/balance-sheet). The segregated balance sheet of the stablecoin is collateral that is used to stabilize the open market price of FRAX stablecoins.\ **2) Sovereign USD peg:** Once the FRAX stablecoin reaches 100% CR, its peg will track to USD using a combination of Chainlink oracles & governance approved reference rates. If FRAX CR drops, AMOs and governance should attempt to restore CR to 100% and keep FRAX price at $1.000 regardless of prices of other assets such as USDC, USDT, or DAI.\ **3)** [**IORB**](https://www.federalreserve.gov/monetarypolicy/reserve-balances.htm) **oracle:** FRAX V3 smart contracts intake the Federal Reserve Interest on Reserve Balances (IORB) rate for certain protocol functions such as sFRAX staking yield. As the IORB oracle rate increases, the Frax Protocol’s AMO strategies will react to heavily collateralize FRAX with treasury bills, reverse repurchase contracts, and/or USD deposited at Federal Reserve Banks that pay the IORB rate. As the IORB oracle reports low/decreasing rates, the AMO strategies will begin to rebalance FRAX collateral with on-chain, decentralized assets and overcollateralized loans in Fraxlend.\ **4) Removal of multi-signature trust assumptions:** FRAX V3 smart contracts will eventually operate entirely on-chain using the [frxGov](https://docs.frax.finance/frax-governance/frax-governance-overview) module in addition to [Snapshot](https://snapshot.org/#/frax.eth) votes by the community.\ **5) Frax Bonds (FXBs):** Bonds will be issued under face value with various maturity dates in order to intake/lock FRAX and help stabilize its peg.\ **6) Non-redeemability:** FRAX stablecoins are non-redeemable, similar to fiat currencies that do not give the holder a right to assets. Holding a FRAX stablecoin does not guarantee you the right to redeem it for any specific financial instrument or token at any particular time. The Frax Protocol’s only function is to use AMO contracts, real-world assets (RWAs), and governance actions through [frxGov](https://docs.frax.finance/frax-governance/frax-governance-overview) to stabilize the FRAX price to $1.000 by using USD oracles as reference.\ **7) Fraxtal:** A modular rollup blockchain (L2) based off Optimism technology. [frxETH](/frax-ether/overview) will be used as the gas token. Includes blockspace incentives (called Flox / FXTL points) that reward users and developers for spending gas and interacting with smart contracts on the network.\ \ \&#xNAN;*\*FRAX v3 deployment is a gradual and iterative process. As smart contracts are deployed, their address will be added to their appropriate documentation sections. Not all features discussed in this document is deployed at this time.\**
# Fraxtal A modular rollup blockchain (L2) based on Optimism, with frxETH as the gas token ### Overview Fraxtal is an EVM equivalent rollup utilizing the [OP stack](https://docs.optimism.io/stack/getting-started) as its smart contract platform and execution environment. The native gas token is Frax Ether ([frxETH](/frax-ether/overview)) issued by Frax Finance. Fraxtal also has blockspace incentives (called [Flox](https://docs.frax.com/fraxtal/fraxtal-incentives/fraxtal-blockspace-incentives/overview)) that reward users and developers for spending gas and interacting with any smart contract on the network. ### What is the point of Fraxtal? Aren't there so many L2 chains already? You can read the whole rationale on the [Fraxtal Docs](https://docs.frax.com/fraxtal), but the main reasons are: 1. Trivial transaction costs 2. Increased speed 3. Usage of frxETH as the gas token 4. Income via Sequencer fees 5. Flox / FXTL blockspace incentives Documentation: {% embed url="" %} # AMOs The Interface Contracts Between FRAX Stablecoins and Subprotocols ## Summary The Frax V3 expansion introduced several new AMOs. “Algorithmic Market Operations” (AMO) contracts are autonomous contracts that enact pre-programmed monetary policy into a specific subprotocol (either internally built and owned by Frax Protocol such as Fraxlend and Fraxswap, or external, such as [Curve](https://curve.fi)). This means that AMO controllers can perform open market operations such as minting FRAX stablecoins into an AMM or lending newly minted FRAX into a money market protocol if certain preprogrammed conditions are met or actions approved by governance. AMOs can interact with any separate protocol allowing FRAX V3 to add, remove, and combine any stability mechanism desired without changing the protocol. Many of these AMOs also earn income for the protocol. Read about older & obsolete (V2 & V1) AMOs [here](/amo/overview). ## AMOs (new for V3) *** ### **Aave AMO** The Aave AMO takes minted FRAX and supplies it into various Aave V3 pools, such as Ethereum and EtherFi, earning protocol interest by allowing users to borrow it. As of 10/2/2024, it is soon expected, per Aave [governance](https://governance.aave.com/t/arfc-remove-frax-from-isolation-mode-and-onboard-sfrax-to-aave-v3-mainnet/18506), that FRAX will be removed from isolation mode, allowing Aave borrowers to use it as collateral for a wider range of borrowing opportunities. As a side benefit, the Aave AMO itself can temporarily borrow other stablecoins such as USDC use them to balance the FRAX peg by swapping out FRAX from Curve pools (such as FRAX/USDC) in times of extreme market stress. Aave AMO (V3): [0x0F2a32f4f54Ec9D52a193E9E3493fb5FeA86Cbbe](https://etherscan.io/address/0x0F2a32f4f54Ec9D52a193E9E3493fb5FeA86Cbbe) ### **Curve AMO** The Curve AMO mints FRAX stablecoins in select Curve pools approved by governance. The AMO also withdraws FRAX and burns supply to keep the exchange rate of each Curve pool in a tight range based on the USD price of FRAX by the reference oracles. Further depositing the Curve LP into Convex can give additional yield via Convex's CRV gauge boost, as well as CVX tokens. Curve AMO (deprecated, many operations are now conducted via the main comptroller [multisig](https://etherscan.io/address/0xB1748C79709f4Ba2Dd82834B8c82D4a505003f27) but the goals are the same): [0x49ee75278820f409ecd67063D8D717B38d66bd71](https://etherscan.io/address/0x49ee75278820f409ecd67063D8D717B38d66bd71)

Complete transaction flow of Curve AMO

### **Fraxlend AMO** [Fraxlend](https://docs.frax.finance/fraxlend/fraxlend-overview) is a permissionless, isolated lending market subprotocol of the Frax Finance ecosystem. Anyone can lend FRAX stablecoins into isolated Fraxlend markets where users deposit collateral to borrow FRAX and pay a [dynamic interest rate](https://docs.frax.finance/fraxlend/advanced-concepts/interest-rates) to lenders. The Fraxlend AMO lends newly created FRAX into Fraxlend pairs that are approved by the [frxGov](https://docs.frax.finance/frax-governance/frax-governance-overview) process and earns interest from borrowers. The Fraxlend AMO [live stats](https://facts.frax.finance/fraxlend/amo) are displayed on Frax Facts. The Fraxlend AMO contract addresses: Ethereum Mainnet - Fraxlend AMO V1: [`0x0Ed8fA7FC63A8eb5487E7F87CAF1aB3914eA4eCa`](https://etherscan.io/address/0x0ed8fa7fc63a8eb5487e7f87caf1ab3914ea4eca)Ethereum Mainnet - Fraxlend AMO V3: [`0xf6E697e95D4008f81044337A749ECF4d15C30Ea6`](https://etherscan.io/address/0xf6e697e95d4008f81044337a749ecf4d15c30ea6)Arbitrum One - Fraxlend AMO V3: [`0xCDeE1B853AD2E96921250775b7A60D6ff78fD8B4`](https://arbiscan.io/address/0xcdee1b853ad2e96921250775b7a60d6ff78fd8b4)\ Fraxtal - Fraxlend AMO V3: [`0x58C433482d74ABd15f4f8E7201DC4004c06CB611`](https://fraxscan.com/address/0x58C433482d74ABd15f4f8E7201DC4004c06CB611)

Complete transaction flow of Fraxlend AMO

### **Fraxswap TWAMM AMO** The Fraxswap TWAMM AMO loads [time-weighted average market maker orders](https://docs.frax.finance/fraxswap/technical-specifications#time-weighted-average-market-maker-twamm) into the Fraxswap AMM to buy or sell collateral over a long period of time. This allows for expanding of the FRAX balance sheet by buying collateral with FRAX stablecoins or contracting the supply of FRAX by selling balance sheet assets through TWAMM orders. The AMO can also be used to repurchase FXS tokens with protocol revenue/fees. \ \ The Fraxswap TWAMM AMO contract address is [`0x629C473e0E698FD101496E5fbDA4bcB58DA78dC4`](https://etherscan.io/address/0x629C473e0E698FD101496E5fbDA4bcB58DA78dC4) ### FXB AMO The FRAX Bonds AMO provides the FRAX ecosystem an ability to sell FRAX "bonds" at a discounted rate to the market through FRAX governance. Each unit of FRAX bond (also called FXB) is equal to one unit of locked FRAX, and at a pre-determined date the owner of the FXB is able to burn their FXB and receive their equal unit of FRAX. Through the FXB AMO, the Frax team auctions off FXBs to the public. The FRAX received by the AMO is then sent to FinresPBC. Technical specifications such as interface and access control can be found on [Github](https://github.com/fraxfinance/frax-bonds-amo) (TODO: make repo public). Ethereum Mainnet FXB AMO: [`0x452420df4AC1e3db5429b5FD629f3047482C543C`](https://etherscan.io/address/0x452420df4ac1e3db5429b5fd629f3047482c543c)\ Fraxtal FXB AMO: [`0xE6ed07952dC9993DD52c6d991Fa809C00eBE58a3`](https://fraxscan.com/address/0xE6ed07952dC9993DD52c6d991Fa809C00eBE58a3) ### Miscellaneous Various protocol-owned multisig addresses hold and manage revenue-earning positions in accordance with governance decisions. Examples include Curve/Convex farms and directly held tokens like sDAI and sfrxETH. The largest multisig ([0xB1748C79709f4Ba2Dd82834B8c82D4a505003f27](https://etherscan.io/address/0xB1748C79709f4Ba2Dd82834B8c82D4a505003f27)) is on Ethereum. You can see a full list of positions [here](https://facts.frax.finance/frax/balance-sheet). # RWAs Real-World Assets that Yield the IORB Rate with Minimal Maturity Risk FRAX V3 utilizes a real-world asset (RWA) strategy when the IORB oracle reports high rates. FRAX V3 only utilizes RWAs that yield very close to the IORB rate with as little duration risk as possible. Thus, only the following assets are considered at this time unless changed by the [frxGov](https://docs.frax.finance/frax-governance/frax-governance-overview) process:\ \ 1.) Short-dated United States treasury bills \ 2.) [Federal Reserve Overnight Repurchase Agreements](https://www.federalreserve.gov/monetarypolicy/standing-overnight-repurchase-agreement-facility.htm)\ 3.) USD deposited at Federal Reserve Bank master accounts\ 4.) Select shares of money market mutual funds\ \ FRAX V3 partner custodians primarily concentrate on only the above assets. RWA partners must report the custody, broker, banking, and trust arrangements employed in the course of holding the assets for FRAX V3 no later than monthly. [FIP-277](https://gov.frax.finance/t/fip-277-onboard-finrespbc-as-frax-v3s-offchain-rwa-partner/2492) enshrined FinresPBC as the first RWA partner for FRAX V3. FinresPBC will concentrate on securing “cash equivalent” low risk RWAs and optimize for yielding close to the IORB rate for the sFRAX staking vault. Additional RWA partners can be onboarded per governance voting through [frxGov](https://docs.frax.finance/frax-governance/frax-governance-overview). # sFRAX Staking vault targeting the IORB rate ## Summary Staked FRAX (sFRAX) is an ERC4626 staking vault that distributes part of the Frax Protocol yield weekly to stakers denominated in FRAX stablecoins. The sFRAX token represents pro rata deposits within the vault and is always withdrawable for FRAX stablecoins at the pro rata rate at all times. sFRAX APY attempts to roughly track the [interest on reserve balances](https://www.federalreserve.gov/monetarypolicy/reserve-balances.htm) (IORB) rate of the United States Federal Reserve using the IORB oracle. This benchmark rate is generally accepted as the “risk free rate” of the US Dollar. The FRAX staking vault attempts, but does not guarantee in any way, to target this rate.

sFRAX

## Details The sFRAX vault APY is based on a utilization function that can be set by the [frxGov governance module](https://docs.frax.finance/frax-governance/frax-governance-overview). The utilization curve started at a top end of 50% APY and theoretically has no bottom, but as of 10/2/2024, has settled in the 5-10% range. As more FRAX is staked in the vault, the protocol will attempt to deploy FRAX to DeFi governance approved AMOs/strategies as well as RWA sources that yield as close to the IORB rate as possible to keep the floor APY near the IORB target. Every Wednesday at 11:59:59 UTC the Frax Protocol adds newly minted FRAX stablecoins into the sFRAX vault. This newly minted FRAX is one-to-one proportional to the earnings of the Frax Protocol over the prior week and thus fully backed at 100% CR. Each sFRAX epoch is 1 week and identical in length and start time as the FXS gauge and sfrxETH epoch. There is no protocol guarantee that the deployed capital will be from a particular type of asset at any time. The [frxGov](https://docs.frax.finance/frax-governance/frax-governance-overview) governance module will control the deployment path and asset type for sFRAX yield. The Staked FRAX vault’s yield predominantly originates from [real-world asset (RWA) strategies](https://docs.frax.finance/frax-v3/rwas) employed by Frax Protocol partner custodians including, but not limited to, FinresPBC.\ \ sFRAX: [`0xA663B02CF0a4b149d2aD41910CB81e23e1c41c32`](https://etherscan.io/token/0xa663b02cf0a4b149d2ad41910cb81e23e1c41c32)

Complete transaction flow through the sFRAX staking vault system.

# FXBs Zero-coupon bonds that help stabilize the FRAX peg ## Summary FXB tokens are simple, trustless tokens that resemble a [zero-coupon bond](https://www.investopedia.com/terms/z/zero-couponbond.asp) that converts to the FRAX stablecoin upon maturity. FXB AMOs auction off FXBs at a discount to face value. This discount provides the equivalent of RWA yield to buyers without the assumption of RWA risk. They also help remove circulating FRAX and stabilize the peg, as users cannot sell FRAX that is locked (until maturity) in a FXB.

FXB

## Details FXBs are debt tokens denominated in FRAX stablecoins, not a claim on any other asset or collateral. FXB tokens are only convertible to FRAX stablecoins, they do not guarantee FRAX peg, FRAX value, or yield/interest denominated in any other asset except FRAX. FXBs do not entitle the holder to any asset offchain or onchain (other than FRAX stablecoins). Thus, FXBs are not redeemable for US Treasury Bills nor any real-world asset, are not directly backed/collateralized by them (or any specific asset), and do not have any utility except trustlessly converting to FRAX stablecoins at the pre-programmed maturity timestamp generated at their minting. This is important and not merely a semantic distinction because it directly defines the normative and economic property of FXBs. Frax Bond tokens only guarantee that they convert to FRAX on a one-to-one basis through smart contracts that issue them.\ \ FXBs allow the formation of a yield curve to price the time value of lending FRAX back to the protocol itself. Each FXB token is a fungible ERC20 token deployed from an onchain factory contract. **At FXB minting time, FRAX stablecoins are transferred into the FXB contract for conversion on maturity.** This prevents any external actions being necessary for the full FXB cycle to occur and entirely remains trustless. There can be multiple FXB series circulating at all times and no limit for the minimum or maximum maturity timestamp for FXBs deployed from the factory. FXBs mature at the end of the day of their maturity date in UTC and have no expiration. For example, the 20261231 FXB is able to be burned back for its' corresponding FRAX as soon as 1893456000.

FXB system economical flow

### Series Auctions FXB series price discovery happens through a continuous gradual Dutch auction (GDA) auction system that has quantity and price limit set by the Frax team. This guarantees that FXB tokens are not sold for prices lower than the floor limit. Auctions happen through the FXB AMO contract and are trustless, permissionless, and non-custodial. New auctions can happen at any time by the [Fraxtal Comptroller](https://fraxscan.com/address/0xC4EB45d80DC1F079045E75D5d55de8eD1c1090E6) and [Fraxtal AMO Operator](https://fraxscan.com/address/0x5f25218ed9474b721d6a38c115107428E832fA2E), initiated through the [FXB AMO](https://fraxscan.com/address/0xE6ed07952dC9993DD52c6d991Fa809C00eBE58a3).

Complete transaction flow of FXB system

### Minting & Redemptions: Origin chain vs. Bridged chain As mentioned, **at FXB minting time, FRAX stablecoins are transferred into the FXB contract for conversion on maturity.** An FXB can be broken down into two types, *Origin* and *Bridged,* referring to the chain the FXB is originally minted on. This differentiation is needed as the *Origin* chain, the chain the FXB was originally minted from, is where the FXB owner is able to burn their FXB for the equivalent FRAX after maturity. An FXB which, for example, originates on Fraxtal and is then bridged to Fraxtal, is considered *Bridged,* **whereby the underlying FRAX remains on Fraxtal and the FXB must be bridged back to redeem the FRAX**. **Similarly, the FXB must be minted on the origin chain to contain the underlying FRAX.** Why does this happen? When an FXB is originally created, it is done through the [FXBFactory](https://github.com/FraxFinance/dev-frax-bonds/blob/develop/src/contracts/FXBFactory.sol). This origin FXB contains the code to [mint](https://github.com/FraxFinance/dev-frax-bonds/blob/3608454b1e8a83b77b60afbd7ca541e2594bb1cd/src/contracts/FXB.sol#L110-L114) and [burn](https://github.com/FraxFinance/dev-frax-bonds/blob/3608454b1e8a83b77b60afbd7ca541e2594bb1cd/src/contracts/FXB.sol#L130-L134). Once the FXB is bridged, the destination chain creates the FXB from the bridge [ERC20Factory](https://etherscan.io/address/0x6ca98f43719231d38f6426db64c7f3d5c7ce7876#code). This bridged version can only be [minted](https://etherscan.io/address/0x6ca98f43719231d38f6426db64c7f3d5c7ce7876#code#F3#L71) and [burned](https://etherscan.io/address/0x6ca98f43719231d38f6426db64c7f3d5c7ce7876#code#F3#L82) (redeemed) by the bridge. ## Contracts To trustfully import contracts to your local repository, refer to the [frax-template](https://github.com/fraxfinance/frax-template). ### Operations Contracts
ContractEthereumFraxtal
FXB Factory0xa8478781D9605E17c3b4c9C79e7127c4597116E40xaFa1705021f65418e746D8664f4B8A58271f6De4
Auction Factory (permission-less)0xc9268c7F59850B26567b0f5d3Dcc317cEDC434900x2606C2BbE377EDa9e38FFf300D422Ca7cCAB1e5d
FXB AMO0x452420df4AC1e3db5429b5FD629f3047482C543C0xE6ed07952dC9993DD52c6d991Fa809C00eBE58a3
AMO Operator (msig)0x831822660572bd54ebaa065C2acef662a6277D400x5f25218ed9474b721d6a38c115107428E832fA2
AMO Timelock (msig)0x831822660572bd54ebaa065C2acef662a6277D400xC4EB45d80DC1F079045E75D5d55de8eD1c1090E6
### Core Contracts {% tabs %} {% tab title="2024" %} #### Origin Chain Ethereum #### Maturity Date December 31, 2024 | | Fraxtal | Ethereum | Arbitrum One | | ------------ | --------------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------ | | FXB | 0xa71bB8c79dc8FfA90A6Dd711aA9Fbe5114c19cba | 0xF8FDe8A259A3698902C88bdB1E13Ff28Cd7f6F09 | | | Auction | 0x36b3b471c7486Eb9583759681404c48d3c8CC813 | | | | Oracle | | 0x08a0748cF885F46e20fA30A50a035808eab293D3 | | | Curve Pool | | | | | {% endtab %} | | | | {% tab title="2025" %} #### Origin Chain Fraxtal #### Maturity Date December 31, 2025 | | Fraxtal | Ethereum | Arbitrum One | | ------------ | --------------------------------------------------------------- | -------- | ------------ | | FXB | 0xacA9A33698cF96413A40A4eB9E87906ff40fC6CA | | | | Auction | 0x6e6B61369A4f549FF3A7c9E0CFA5F7E8Ada5CD22 | | | | Oracle | | | | | Curve Pool | | | | | {% endtab %} | | | | {% tab title="2026" %} #### Origin Chain Ethereum #### Maturity Date December 31, 2026 | | Fraxtal | Ethereum | Arbitrum One | | ------------ | --------------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------ | | FXB | 0x8e9C334afc76106F08E0383907F4Fca9bB10BA3e | 0x76237BCfDbe8e06FB774663add96216961df4ff3 | | | Auction | 0x334f19B2B6ab1B16eC65A7138dCEe22B60E1A60c | | | | Oracle | | 0x2ec5D1C13fEF1C7029eE329a1D31B2180c9b3707 | | | Curve Pool | | | | | {% endtab %} | | | | {% tab title="2029" %} #### Origin Chain Fraxtal #### Maturity Date December 31, 2029 | | Fraxtal | Ethereum | Arbitrum One | | ------------ | --------------------------------------------------------------- | -------- | ------------ | | FXB | 0xF1e2b576aF4C6a7eE966b14C810b772391e92153 | | | | Auction | 0xb29002BF776066BF8d73B3F0597cA8B894E30050 | | | | Oracle | | | | | Curve Pool | | | | | {% endtab %} | | | | {% tab title="2055" %} #### Origin Chain Fraxtal #### Maturity Date December 31, 2055 | | Fraxtal | Ethereum | Arbitrum One | | ------------- | --------------------------------------------------------------- | -------- | ------------ | | FXB | 0xc38173D34afaEA88Bc482813B3CD267bc8A1EA83 | | | | Auction | 0xfC9f079e9D7Fa6080f61F8541870580Ee7af7CF2 | | | | Oracle | | | | | Curve Pool | | | | | {% endtab %} | | | | | {% endtabs %} | | | | # sFRAX Token Addresses ## sFRAX
ChainAddress
Arbitrum0xe3b3FE7bcA19cA77Ad877A5Bebab186bEcfAD906
Avalanche0x3405E88af759992937b84E58F2Fe691EF0EeA320
Base (LayerZero)0xe4796cCB6bB5DE2290C417Ac337F2b66CA2E770E
Blast (LayerZero)0xe4796cCB6bB5DE2290C417Ac337F2b66CA2E770E
BSC0xa63f56985F9C7F3bc9fFc5685535649e0C1a55f3
Ethereum (native)0xA663B02CF0a4b149d2aD41910CB81e23e1c41c32
Ethereum (LayerZero)0xe4796cCB6bB5DE2290C417Ac337F2b66CA2E770E
Fraxtal (native)0xfc00000000000000000000000000000000000008
Fraxtal (LayerZero)0x5bff88ca1442c2496f7e475e9e7786383bc070c0
Metis (LayerZero)0xe4796cCB6bB5DE2290C417Ac337F2b66CA2E770E
Mode (LayerZero)0x5bff88ca1442c2496f7e475e9e7786383bc070c0
Optimism0x2Dd1B4D4548aCCeA497050619965f91f78b3b532
Polygon zkEVM0x2C37fb628b35dfdFD515d41B0cAAe11B542773C3
Sei (LayerZero)0x5bff88ca1442c2496f7e475e9e7786383bc070c0
X-Layer (LayerZero)0x5bff88ca1442c2496f7e475e9e7786383bc070c0
# sFRAX & FXB Multisigs
ChainNameAddress
EthereumsFRAX & FXB Comptroller0x831822660572bd54ebaa065C2acef662a6277D40
# Fraxferry A slower, simpler, more secure method of bridging tokens. ## Summary A 24-48hr token bridging solution designed and implemented by the Frax team.
## Motivation * Too many bridge hacks from bugs, team rugs, anon devs, etc. * Risks of infinite mints. * Some chains have slow bridges, especially on return trip back to Ethereum (e.g. Arbitrum, Optimism, etc).

Fraxferry

## Benefits * Risk is capped by token amounts in bridge contracts. No risk of infinite mints. * Slower transactions give more time for bad batches to be caught and stopped, assuming they are not cancelled automatically by bots. * Crewmembers can pause contracts so any issues can be investigated. ## Risks * Captain is tricked into proposing a batch with a false hash AND all crewmember bots are offline/censured/compromised AND no one disputes the proposal. * Reorgs on the source chain. Avoided, by only returning the transactions on the source chain that are at least one hour old. * Rollbacks of optimistic rollups. Avoided by running a node. * Operators do not have enough time to pause the chain after a fake proposal. Avoided by requiring a minimal amount of time between sending and executing the proposal. * Centralization ## Process 1. User sends tokens to the contract. This transaction is stored in the contract. `embark()`, `embarkWithRecipient()`, or `embarkWithSignature()`. 2. Captain queries the source chain for transactions to ship. 3. Captain sends batch (start, end, hash) to start the trip. `depart()` 4. Wait at least 24 hrs. 5. Crewmembers check the batch and can dispute it if it is invalid. `disputeBatch()` or `do nothing`. 6. Non disputed batches can be executed by the first officer by providing the transactions as calldata. User receives their tokens on the other chain. `disembark()` 7. Hash of the transactions must be equal to the hash in the batch. 8. In case there was a fraudulent transaction (a hacker for example), the owner can cancel a single transaction, such that it will not be executed. `jettison()`, `jettisonGroup()`, `removeBatches()`. 9. The owner can manually manage the tokens in the contract and must make sure it has enough funds. # LayerZero x Stargate Bridge tokens in minutes through the LayerZero x Stargate partnership. ## Motivation * Alternative and scalable multichain bridging solution. ## Benefits * Bridging complete within minutes. * Flexible choice in source or destination chain. ## Risks * Trust delegated to LayerZero / Stargate. * LayerZero Endpoint * LayerZero, Horizen DVN * Stargate UI ## OFTs Frax assets are represented as OFTs (as defined by [LayerZero](https://docs.layerzero.network/v2/developers/evm/oft/quickstart)) on chains other than Fraxtal, Ethereum, and Arbitrum. An OFT operates the exact same as an ERC20 with the additional function of bridge-ability through the LayerZero protocol. ### Available Frax OFTs * FRAX * sFRAX * frxETH * sfrxETH * FXS * FPI ### Legacy vs. Upgradeable OFTs In the initial deployment with LayerZero, the LayerZero team deployed Frax assets across several chains as fixed contracts. After the initial deployment, the Frax team has assumed additional deployment responsibilities and currently deploys OFTs as upgradeable, transparent proxies (contracts audited, repo [link](https://github.com/FraxFinance/LayerZero-v2-upgradeable)). Legacy and Upgradeable OFTs maintain the same address per asset across chains, respectively. All OFTs with bridging permissions are managed by a 3/6 msig on each respective chain. ## Process * Bridge through the Stargate UI ([link](https://stargate.finance/bridge)) * Bridge directly with LayerZero ```sh npm install @fraxfinance/layerzero-v2-upgradeable ``` ```solidity import { OptionsBuilder } from "@fraxfinance/layerzero-v2-upgradeable/oapp/contracts/oapp/libs/OptionsBuilder.sol"; import { SendParam, MessagingFee, IOFT } from "@fraxfinance/layerzero-v2-upgradeable/oapp/contracts/oft/interfaces/IOFT.sol"; uint256 amount = 1e18; // Upgradeable FRAX - Bridging FROM Mode address oft = 0x80eede496655fb9047dd39d9f418d5483ed600df; // Ethereum - choose destination EID from https://github.com/FraxFinance/frax-oft-upgradeable/blob/master/scripts/L0Config.json uint32 dstEid = 30101; bytes memory options = OptionsBuilder.newOptions(); SendParam memory sendParam = SendParam({ dstEid: dstEid, to: bytes32(uint256(uint160(msg.sender))), amountLD: amount, minAmountLD: amount, extraOptions: options, composeMsg: '', oftCmd: '' }); MessagingFee memory fee = IOFT(_oft).quoteSend(sendParam, false); IOFT(_oft).send{value: fee.nativeFee}( sendParam, fee, payable(msg.sender) ); ``` ## Contracts & Addresses ### Admin * `ProxyAdmin`: `0x223a681fc5c5522c85c96157c0efa18cd6c5405c` * Msigs (links to gnosis safe) * [`Ethereum`](https://app.safe.global/home?safe=eth:0xB1748C79709f4Ba2Dd82834B8c82D4a505003f27) * [`Blast`](https://blast-safe.io/home?safe=blast:0x33A133020b2C2CD41a24F74033B11EC2fC0bF97a) * [`Metis`](https://metissafe.tech/home?safe=metis-andromeda:0xF4A4F32732F9B2fB84Ee28c58616946F3bF80F7d) * [`Base`](https://app.safe.global/home?safe=base:0xCBfd4Ef00a8cf91Fd1e1Fe97dC05910772c15E53) * [`Mode`](https://safe.optimism.io/home?safe=mode:0x6336CFA6eDBeC2A459d869031DB77fC2770Eaa66) * [`Sei`](https://sei-safe.protofire.io/home?safe=sei:0x0357D02fc95320b990322d3ff69204c3D251171b) * [`Fraxtal`](https://safe.mainnet.frax.com/home?safe=fraxtal:0x5f25218ed9474b721d6a38c115107428E832fA2E) * [`X-Layer`](https://app.safe.global/home?safe=xlayer:0xe7Cc52f0C86f4FAB6630f1E26167B487fbF66a61) ### Legacy OFTs * **Chain**: `Ethereum`, `Metis`, `Blast`, `Base` * **Admin**: Chain-respective msig * OFTs * `FRAX`: `0x909DBdE1eBE906Af95660033e478D59EFe831fED` * `sFRAX`: `0xe4796cCB6bB5DE2290C417Ac337F2b66CA2E770E` * `sfrxETH`: `0x1f55a02A049033E3419a8E2975cF3F572F4e6E9A` * `FXS`: `0x23432452B720C80553458496D4D9d7C5003280d0` * `frxETH` : `0xF010a7c8877043681D59AD125EbF575633505942` * `FPI`: `0xE41228a455700cAF09E551805A8aB37caa39D08c` ### Upgradeable OFTs * **Chain**: `Mode`, `Sei`, `Fraxtal`, `X-Layer` * **Admin**: `ProxyAdmin` (owned by chain-respective msig) * OFTs * `FRAX`: `0x80eede496655fb9047dd39d9f418d5483ed600df` * `sFRAX`: `0x5bff88ca1442c2496f7e475e9e7786383bc070c0` * `sfrxETH`: `0x3ec3849c33291a9ef4c5db86de593eb4a37fde45` * `FXS`: `0x64445f0aecc51e94ad52d8ac56b7190e764e561a` * `frxETH`: `0x43eDD7f3831b08FE70B7555ddD373C8bF65a9050` * `FPI` : `0xEed9DE5E41b53D1C8fAB8AAB4b0e446F828c1483` ### Source Code * * * [https://github.com/fraxfinance/frax-oft-legacy](broken://spaces/-MJQZW1mSg2O5N7HXHo0-2020321539/pages/-ML58MM-VYC3Y0uouI69) ## Security Considerations Layer Zero OFT Frax Assets are not a liability of the Frax Protocol. They do not appear on the balance sheet on [facts.frax.finance](https://facts.frax.finance/frax/balance-sheet). **They are not redeemable for protocol owned assets.** They are only redeemable for the Frax Asset in the Layer Zero “lockbox” contract that is part of the Layer Zero Protocol.\ \ Layer Zero OFT Frax Assets are settled by Layer Zero Decentralized Verification Networks (DVNs) that are not operated by the Frax Protocol, Frax Core Developers, or any associated entity of Frax. Therefore, the risk of OFT Frax Assets are borne by their holders. This is similar to holding “USDC tokens” on a network that its issuer, Circle, does not support minting/redeeming on. Such “USDC tokens” do not appear on Circle’s balance sheet as a liability nor are they redeemable from its issuer. They are only redeemable for the underlying USDC token in the bridge (ie ‘lockbox’) contract.
In the future, the Frax Protocol can work with Layer Zero to upgrade certain OFT Frax Assets on select networks to allow the Frax Protocol to have direct oversight in the settlement process similar to the Frax Ferry system. After this, the OFT Frax Assets for those select networks will be reported on the associated balance sheet of those Frax Assets. When this occurs, the Frax Protocol will consider such tokens at that time as its liability that are backed directly by the assets it holds on its respective balance sheets. At this time, no Frax OFT tokens are native liabilities of the protocol.
# Fraxtal Bridge Bridging and messaging between Ethereum and Fraxtal The bridging process for Fraxtal is derived from that of [Optimism](https://docs.optimism.io/builders/app-developers/bridging/standard-bridge). Assets going from Ethereum Mainnet to Fraxtal (L1StandardBridge & L1ERC721Bridge) usually only take a few minutes, but coming back from Fraxtal to Ethereum (L2StandardBridge & L2ERC721Bridge) can take 7 days. The same applies for messages (L1CrossDomainMessenger & L2CrossDomainMessenger). To mitigate this, Frax Ferry is also available for Fraxtal, and most users will opt to use the Ferry to come back to Ethereum, taking only 24-48 hrs instead of 7 days. Fraxtal Bridge UI: \ Fraxtal Bridge Docs: ### Ethereum -> Fraxtal (\~ a few minutes) | Type | Contract | Address (on Ethereum) | | ----------------- | ---------------------- | --------------------------------------------------------------------------------------------------------------------- | | ETH/frxETH/ERC20s | L1StandardBridge | [0x34C0bD5877A5Ee7099D0f5688D65F4bB9158BDE2](https://etherscan.io/address/0x34C0bD5877A5Ee7099D0f5688D65F4bB9158BDE2) | | ERC721s | L1ERC721Bridge | [0xa9B5Fb84B7aeAF0D51C95DB04a76B1D4738D0eC5](https://etherscan.io/address/0xa9B5Fb84B7aeAF0D51C95DB04a76B1D4738D0eC5) | | Messages | L1CrossDomainMessenger | [0x126bcc31Bc076B3d515f60FBC81FddE0B0d542Ed](https://etherscan.io/address/0x126bcc31Bc076B3d515f60FBC81FddE0B0d542Ed) | ### Fraxtal -> Ethereum (7 days) | Type | Contract | Address (on Fraxtal) | | ----------------- | ---------------------- | --------------------------------------------------------------------------------------------------------------------- | | ETH/frxETH/ERC20s | L2StandardBridge | [0x4200000000000000000000000000000000000010](https://fraxscan.com/address/0x4200000000000000000000000000000000000010) | | ERC721s | L2ERC721Bridge | [0x4200000000000000000000000000000000000014](https://fraxscan.com/address/0x4200000000000000000000000000000000000014) | | Messages | L2CrossDomainMessenger | [0x4200000000000000000000000000000000000007](https://fraxscan.com/address/0x4200000000000000000000000000000000000007) | # Overview (CPI Peg & Mechanics) A novel stablecoin pegged to a basket of consumer goods ### FPI The Frax Price Index (FPI) is the second stablecoin of the Frax Finance ecosystem. FPI is the first stablecoin pegged to a basket of real-world consumer items as defined by the [US CPI-U](https://www.bls.gov/news.release/cpi.t01.htm) average. The FPI stablecoin is intended to keep its price constant to the price of all items within the CPI basket and thus hold its purchasing power with on-chain stability mechanisms. Like the FRAX stablecoin, all FPI assets and market operations are on-chain and use AMO contracts.

FPI

### FPIS ⚠️ FPIS is set to be [phased out](/frax-price-index/fpis-conversion-fpis-locker) by March 22, 2028 and convertible thereafter to FXS ⚠️ The Frax Price Index Share (FPIS) token is the governance token of the system, which is also entitled to seigniorage from the protocol. Excess yield will be directed from the treasury to FPIS holders, similar to the FXS structure. During times in which the FPI treasury does not create enough yield to maintain the increased backing per FPI due to inflation, new FPIS may be minted and sold to increase the treasury. Since the protocol is launched from within the Frax ecosystem, the FPIS token will also direct a variable part of its revenue to FXS holders.

FPIS

### Inflation & Peg Calculation FPI uses the CPI-U unadjusted 12 month inflation rate reported by the US Federal Government: . The $1 start date was based on the December 2021 CPI-U result. Thus, the FPI market price after that date should track the same purchasing power of Dec 2021. For example, on October 4 2024, FPI's market price was approximately $1.11. That means that it takes about $1.11 of October 4 2024 US Dollars to purchase something that used to cost $1 in December of 2021 (\~3.5-4% inflation per year). A specialized Chainlink oracle commits this data on-chain immediately after it is publicly released. The oracle's reported inflation rate is then applied to the redemption price of FPI stablecoins in the system contract. This redemption price grows per second on-chain (or declines in rare cases of deflation). The peg calculation rate is updated once every 30 days when bls.gov releases their monthly CPI price data. The contract handling the FPI peg price targeting is the [CPI Tracker Oracle](/frax-price-index/cpi-tracker-oracle).\ \ Thus, the FPI peg tracks the above 12 month inflation rate and pegs to it at all times from the FPI redemption contract. When buying FPI stablecoins for another asset (such as ETH) the trader is taking the position that CPI purchasing power is growing faster over time than the sold ETH. If selling FPI for ETH, then the trader is taking the position that ETH growth is outpacing the CPI inflation rate of the US Dollar. ![The 12 month inflation rate is used as the peg target of FPI. At an inflation rate of 9.1% in June 2022, the FPI peg would grow at a rate of 9.1% against USD for the next 30 days. Note that during deflationary periods (June 2009) where the rate of inflation is negative, the FPI peg would decrease against USD.](/files/n0lF0y5vxhrfWGk3YZTa) #### FPI as a Unit of Account FPI aims to be the first on-chain stablecoin to have its own unit of account derived from a basket of goods, both crypto and non-crypto. While FPI can be considered an inflation resistant yield asset, its primary motivation is to create a new stablecoin to denominate transactions, value, and debt. Denominating DAO treasuries and measuring revenue in FPI as well as benchmarking performance against an FPI trading pair helps better gauge if value accrual is actively growing against inflation in real terms. It also helps ground on-chain economics to baskets of real world assets.\ \ At first, the treasury will be comprised solely of $FRAX, but will expand to include other crypto-native assets such as bridged BTC, ETH, and non-crypto consumer goods and services. #### FPI Stability Mechanism FPI uses the same type of AMOs as the FRAX stablecoin however it is modeled to keep a 100% collateral ratio (CR) at all times. This means that for the collateral ratio to stay at 100% the protocol balance sheet must be growing at least at the rate of CPI inflation. Thus, AMO strategy contracts must earn a yield proportional to CPI otherwise the CR will decrease to below 100%. During times that AMO yield is under the CPI rate, a TWAMM AMO will sell FPIS tokens for FRAX stablecoins to keep the CR at 100% at all times. The FPIS TWAMMs will be removed when the CR returns to 100%. Minting of FPI (using FRAX) and redeeming FPI (to receive FRAX) can be done at any time for a small fee using the [FPI Controller Pool](/frax-price-index/fpi-controller-pool). Users can also buy/sell FPI in various markets such as [Curve](https://curve.fi/#/ethereum/pools/factory-stable-ng-33/swap) or Fraxswap. FPI Controller Pool: [`0x2397321b301B80A1C0911d6f9ED4b6033d43cF51`](https://etherscan.io/address/0x2397321b301B80A1C0911d6f9ED4b6033d43cF51) #### **FPI Comptroller Multisig** The FPI Comptroller multisig collects/deposits surplus/deficit FRAX from the FPI Controller Pool and is the owner of FPI-related contracts. It also invests in various income streams like Curve/Convex farms and uses the proceeds to help add backing to the FPI peg. FPI Comptroller Multisig: [`0x6A7efa964Cf6D9Ab3BC3c47eBdDB853A8853C502`](https://etherscan.io/address/0x6A7efa964Cf6D9Ab3BC3c47eBdDB853A8853C502) # Frax Price Index Share (FPIS) ⚠️ FPIS is set to be [phased out](/frax-price-index/fpis-conversion-fpis-locker) by March 22, 2028 and convertible thereafter to FXS ⚠️\ \ The Frax Price Index Share (FPIS) is the governance token of the Frax Price Index (FPI) stablecoin. FPIS is interconnected to the Frax Share (FXS) token thus it is referred to as a "linked governance token." The FXS & FPIS are economically linked programmatically in a similar way that a layer 1 token is connected to a dapp token on its network.\ \ FXS is the base token of the Frax Ecosystem thus FXS will always accrue value as both FRAX & FPI stablecoins grow no matter what. FXS accrues value proportional to the aggregate growth of the entire Frax economy as a whole similar to how ETH captures value from the sum total of all dapp economic activity that pays gas for access to Ethereum blockspace. FPIS tracks FPI growth specifically similar to a specific ERC20 token tracks growth of its own protocol rather than the entire L1 economy. If you think the Frax economy is undervalued as a whole, you should want to own more FXS. If you think people are undervaluing FPI growth specifically, you should increase more exposure to FPIS. It's the exact same dynamic of whether you would invest in a specific project or you invest in ETH instead. If you think the ETH economy as a whole is undervalued, you'd buy more ETH. But if you think a specific project will grow faster than the sum total of the economy, you'll want to own that specific token rather than the L1 token.\*\ \ The Frax Collateral Ratio (FCR) is the ratio of FRAX stablecoins directly backing FPI tokens. The FCR is directly calculated before value distribution to FPIS & veFPIS token holders. The FCR specifically is used for FXS value capture of the system. Whenever excess FPI balance sheet value is distributed back to FPIS token holders it will pass through an "FCR contract" or function call that calculates how much "FRAX collateral FPI uses." Essentially, any economic productivity above the inflation rate goes to FPIS holders. Since the FPI is pegged to a basket of consumer items, it represents a claim on the value of the basket. The value the protocol generates in excess beyond that basket is captured by FPIS holders. FPIS supply is initially set to 100 million tokens at genesis (distribution [here](/frax-price-index/fpis-distribution)) but is expected to decrease to around \~41M that are actually eligible for 2.5 : 1 conversion to FXS in March 22, 2028. **\*No discussion of value capture in this documentation is investment advice. Governance token mechanics are merely meant to describe how the Frax/FPI system functions.**\
# FPIS Distribution Initial distribution plan for FPIS tokens ### FPIS Token Distribution (100,000,000 FPIS total supply) ⚠️ Remaining tokens in the Frax and FPI Treasuries will be burned per the [phase out](/frax-price-index/fpis-conversion-fpis-locker) and not be eligible for 2.5 : 1 conversion to FXS. The total supply is thus expected to decrease to around \~41M eligible FPIS. ⚠️ **30% Frax Finance Treasury 30,000,000**\ FXS voters have total control in voting how to distribute these tokens through governance. Frax Finance Treasury (multisig): [`0x9AA7Db8E488eE3ffCC9CdFD4f2EaECC8ABeDCB48`](https://etherscan.io/address/0x9AA7Db8E488eE3ffCC9CdFD4f2EaECC8ABeDCB48) \ **25% FPI Protocol Treasury 25,000,000**\ FPIS voters themselves have total control in how to distribute these tokens. FPI Protocol Treasury (multisig): [`0x5181C3c36bD52F783e6E1771d80b1e3AdCB36019`](https://etherscan.io/address/0x5181C3c36bD52F783e6E1771d80b1e3AdCB36019)\ \ **10% veFPIS Emissions 10,000,000** ⚠️ veFPIS emissions were stopped in early July 2024 per the phase out. The leftover tokens are stored in the FPI Protocol Treasury multisig and are planned to be burned. ⚠️ FPIS allotted to veFPIS stakers on a yearly halvening emissions schedule starting February 20th, 2023 at 4pm PST. First year emissions of 5M FPIS, second year emissions of 2.25M FPIS, third year 1.125M FPIS, etc. This emission will be augmented with additional FPI Protocol profits distributed to veFPIS holders when the FPI stablecoin is above a certain collateral ratio set by governance. **25% Core Developers & Contributors Treasury 25,000,000**\ 4 year back-vested to start from February 20th 2022 at the same time as airdrop genesis with a 6 month cliff. Distribution occurs on/around 20th of each month. FPI Core Contributors (Ethereum): [`0x708695db8dF61e646571E78b9b3e2BAd7D6c42E3`](https://etherscan.io/address/0x708695db8dF61e646571E78b9b3e2BAd7D6c42E3)\ FPI Core Contributors (Fraxtal): [`0xe0EefF64eAB79C78221f9571BBDA70eEe65620ce`](https://fraxscan.com/address/0xe0EefF64eAB79C78221f9571BBDA70eEe65620ce)\ \ **10% February 2022 Airdrop to FXS Holders 10,000,000**\ Snapshot on February 20th 11:59:59 UTC 2022 and were claimable until August 20th 11:59:59 UTC 2022. Approximately 459,074.53 FPIS went unclaimed and was recovered to the FPI Comptroller Multisig at [`0x6A7efa964Cf6D9Ab3BC3c47eBdDB853A8853C502`](https://etherscan.io/address/0x6A7efa964Cf6D9Ab3BC3c47eBdDB853A8853C502) FPISAirgrabber: [`0x3266724e4e58E5891Eb30E6d329bA119A192483c`](https://etherscan.io/address/0x3266724e4e58E5891Eb30E6d329bA119A192483c) # CPI Tracker Oracle ## Description The oracle uses Chainlink's December 2021 CPI-U data point (provided by Fiews) as the 'base' index for determining the peg price. Each month, the change / delta percent of the index is applied to the previous month's data point to determine the peg price. December 2021 was chosen because the oracle contract requires two initial 'historical' data points. #### *Example:* December 2021 CPI-U: 280.126 January 2022 CPI-U: 281.933 Delta is (281.933 / 280.126) - 1 = 0.64506686% Assuming December 2021 is $1, applying the delta percentage gives $1 x (1.0064506686) = $1.0064506686 as the peg price. If February 2022 CPI-U data was 284.182, the delta would be (284.182 / 281.933) - 1 = 0.79770726%. Applying this to the previous peg price would give $1.0064506686 \* (1 + 0.0079770726) = $1.0144791987 as the new peg price. In other words, you would need this many Feb 2022 dollars to buy one Dec 2021 dollar. **CPITrackerOracle (V2):** [`0x66B7DFF2Ac66dc4d6FBB3Db1CB627BBb01fF3146`](https://etherscan.io/address/0x66B7DFF2Ac66dc4d6FBB3Db1CB627BBb01fF3146) **Raw data source:** **Chainlink / Fiews Oracle:** ## Code {% embed url="" %} # FPI Controller Pool ## Description The FPI Controller Pool has various helper functions related to FPI and its peg, such as minting and redeeming FPI. FPI Controller Pool: [`0x2397321b301B80A1C0911d6f9ED4b6033d43cF51`](https://etherscan.io/address/0x2397321b301B80A1C0911d6f9ED4b6033d43cF51) ### Mint / Redeeming Users can mint FPI with FRAX or redeem FPI for FRAX. There is a small fee associated with this, initially 0.30%. ### twammToPeg The twammToPeg function is used by the protocol to introduce market pressure to bring the market price of FPI up (or down) to the target peg price. ### giveFRAXToAMO / receiveFRAXFromAMO The contract can lend FRAX collateral to various AMOs that earn yield (among other things). ## Code {% embed url="" %} # veFPIS An updated and modular veFPIS ⚠️ veFPIS is now unlocked, and yield for it stopped, per the [Frax Singularity Roadmap Part 1](https://gov.frax.finance/t/fip-341-frax-singularity-roadmap-part-1/2987). Users are encouraged to migrate to the [FPIS Locker](/frax-price-index/fpis-conversion-fpis-locker) on Fraxtal for eventual FPIS conversion into FXS ⚠️ veFPIS is an updated and vesting + yield system for the FPIS governance token. Similar to veFXS, users may lock their FPIS for up to 4 years for four times the amount of veFPIS (e.g. 100 FPIS locked for 4 years returns 400 veFPIS). veFPIS is not a transferable token nor does it trade on liquid markets. It's akin to an account based point system that signifies the vesting duration of the wallet's locked FXS tokens within the protocol. The veFPIS balance linearly decreases as tokens approach their lock expiry, approaching 1 veFPIS per 1 FPIS at zero lock time remaining. ### Double Whitelist & Modular Functionality veFPIS has an additional "DeFi whitelist" for smart contracts that add modular functionality to the staking system. Governance can approve each new whitelisted DeFi feature. For example, a liquidation contract can be whitelisted by governance which allows a staker's underlying FPIS tokens to be liquidated if they borrow against their veFPIS balance. Users will have to approve each DeFi whitelisted contract to spend their FPIS tokens before the new functionality can be unlocked for each user. This allows the staking system to remain fully trustless so that no extra logic can access a staker's veFPIS balance without a staker's approval thus keeping modules opt-in per wallet address. This system allows governance to add new iterative functionality to veFPIS staking such as "slashing conditions" and new ways to earn higher yield (and potentially be slashed if users opt-in) by adding smart contracts which allow veFPIS holders to vote on CPI gauge weights, borrow FPI, or control liquidity deployment. # FPIS Conversion / FPIS Locker Retiring FPIS and converting it to FXS Per the [Frax Singularity Roadmap Part 1](https://gov.frax.finance/t/fip-341-frax-singularity-roadmap-part-1/2987) vote, the community decided to eventually retire the FPIS token in the interest of focusing on FXS. On March 22, 2028, FPIS will be eligible for conversion to FXS at the ratio of 2.5 FPIS to 1 FXS. Until then, users may choose to lock their FPIS on Fraxtal using the [FPIS Locker](https://app.frax.finance/fpifpis/fpislocker). This will give the user 1.333x - 0.333x veFXS voting power based on the length of their lock. After the March 22, 2028 conversion date, positions that are still locked on the FPIS Locker can be converted to their FXS equivalent and rolled over into veFXS until the remaining lock time is completed, after which FXS can be withdrawn. FPIS that was never locked in the FPIS Locker or became unlocked before the conversion date may also be converted to FXS after the conversion date without having to go via the FPIS Locker. Users that have locked [veFPIS](/frax-price-index/vefpis) positions may now freely withdraw their FPIS. # FPI and FPIS Token Addresses ## FPI
ChainAddress
Arbitrum0x1B01514A2B3CdEf16fD3c680a818A0Ab97Da8a09
Base (LayerZero)0xE41228a455700cAF09E551805A8aB37caa39D08c
Blast (LayerZero)0xE41228a455700cAF09E551805A8aB37caa39D08c
BSC0x2Dd1B4D4548aCCeA497050619965f91f78b3b532
Ethereum0x5Ca135cB8527d76e932f34B5145575F9d8cbE08E
Ethereum (LayerZero)0xE41228a455700cAF09E551805A8aB37caa39D08c
FantomN/A
Fraxtal (native)0xFc00000000000000000000000000000000000003
Fraxtal (LayerZero)0xEed9DE5E41b53D1C8fAB8AAB4b0e446F828c1483
Metis (LayerZero)0xE41228a455700cAF09E551805A8aB37caa39D08c
Mode (LayerZero)0xEed9DE5E41b53D1C8fAB8AAB4b0e446F828c1483
MoonbeamN/A
Optimism0xC5d43A94e26fCa47A9b21CF547ae4AA0268670E1
PolygonN/A
Sei (LayerZero)0xEed9DE5E41b53D1C8fAB8AAB4b0e446F828c1483
X-Layer (LayerZero)0xEed9DE5E41b53D1C8fAB8AAB4b0e446F828c1483
## FPIS
ChainAddress
Arbitrum0x3405E88af759992937b84E58F2Fe691EF0EeA320
BSC0xD1738eB733A636d1b8665f48bC8a24dA889c2562
Ethereum (native)0xc2544A32872A91F4A553b404C6950e89De901fdb
Fraxtal (native)0xfc00000000000000000000000000000000000004
FantomN/A
MoonbeamN/A
Optimism0x8368Dca5CE2a4Db530c0F6e535d90B6826428Dee
PolygonN/A
# FPI Multisigs ## Ethereum
NameAddress
Comptroller0x6A7efa964Cf6D9Ab3BC3c47eBdDB853A8853C502
Treasury0x5181C3c36bD52F783e6E1771d80b1e3AdCB36019
Team Incentives0x708695db8dF61e646571E78b9b3e2BAd7D6c42E3
## Other Chains
ChainNameAddress
ArbitrumComptroller0xF0D5007dB0393c9D5F6A88A5F82Df520EA483fDb
AvalancheComptroller0xB3e03c9C1820C6216953FB1BBC6fFd232ac12a19
BSCComptroller0x49f9cbf5333d8e50c9BE76c775777DB2ACb1d456
FantomComptroller0xe722B0fA594e290a8E53bFB5654cE4Ad8a4BE811
FraxtalComptroller0x7fC64FFDdf99Cd64dc2CFf86A82F3b749962cF33
FraxtalTeam Incentives0xe0EefF64eAB79C78221f9571BBDA70eEe65620ce
MoonbeamComptroller0xc4d89dcE72cde17DC3BEF317E62530b6A0733971
OptimismComptroller0x8Acc8819cBB632dE4a8E732f08b9E578D2A8F635
PolygonComptroller0x4EBd698a5dB2580587EE0000929128190524006c
Polygon zkEVMComptroller0xDD2a221c0A9B88052af736D5CcCb27362b8EF57B
# Overview A Unique Time Weighted Average Market Maker for Trustless Monetary Policy ## Summary Fraxswap is the first constant product automated market maker with an embedded time-weighted average market maker (TWAMM) for conducting large trades over long periods of time trustlessly. It is fully permissionless and the core AMM is based on Uniswap V2. This new AMM helps traders execute large orders efficiently. Fraxswap is a fully permissionless AMM which means others can create their own LP pairs in for any two tokens, like Uniswap. The motivation for building Fraxswap was to create a unique AMM with specialized features for algorithmic stablecoin monetary policy, forward guidance, and large sustained market orders to stabilize the price of one asset by contracting its supply or acquiring a specific collateral over a prolonged period. Specifically, Frax Protocol will use Fraxswap for: 1. Buying back and burning FXS with AMO profits, 2. Increase the stability of the pegs for the FRAX & FPI stablecoins 3. Selling FRAX to purchase hard assets 4. Deploying protocol-owned liquidity for income and utility, such as FRAX/FXS and FRAX/\ on various chains.

Fraxswap

### **Ideal use cases by other protocols, stablecoin issuers, & DAOs include:** 1\) Accumulation of a treasury asset (such as stablecoins) over time by slowly selling governance tokens.\ 2\) Buying back governance tokens slowly over time with DAO revenues & reserves.\ 3\) Acquiring another protocol's governance tokens slowly over time with the DAO's own governance tokens (similar to a corporate acquisition/merger but in a permissionless manner).\ 4\) Defending "risk free value" (RFV) for treasury based DAOs such as Olympus, Temple, and various projects where the backing of the governance token is socially or programmatically guaranteed. To use Fraxswap for monetary policy, the best method is to create a token pair and add protocol controlled liquidity. Then TWAMM orders can be placed in any size in either direction as desired for forward guidance and rebalancing of the DAO's net assets. See the [technical specifications section](https://docs.frax.finance/fraxswap/technical-specifications) to understand slippage calculations and liquidity optimizations for TWAMMs. Fraxswap UI:
# Technical Specifications Fraxswap technical details ## Diagram ![Diagram of order flow on a Fraxswap pair with a TWAMM order active.](/files/W5FFqbbmU7lhD8orx3qp) ### Core AMM The Core AMM for Fraxswap is Uniswap V2 and based on the full range xy=k constant product design. Fraxswap has adhered to many of the design decisions of Uniswap V2 as it extended the codebase to support TWAMMs. Fraxswap v2 plans to support concentrated liquidity & correlated asset liquidity in a unique & novel way to allow TWAMM functionality across such pairs as well. Extensive documentation on Uniswap core functionality can be found here: ### Time-weighted Average Market Maker (TWAMM) Fraxswap is the first live TWAMM implementation. The embedded TWAMM adheres to Paradigm’s [original whitepaper specifications](https://www.paradigm.xyz/2021/07/twamm). Features mentioned in the whitepaper are used to optimize the execution of long-term orders which include: order pooling and aligning order expiries (hourly). Long-term orders are executed prior to any interaction with Fraxswap, this means the long-term orders are executed first before the AMM interaction and once per block (see above schematic). Fraxswap implements an approximation formula of Paradigm’s original formula and allows for a simplified, more gas-efficient TWAMM.\ \ The TWAMM whitepaper describes the fundamental mechanics:\ \&#xNAN;*"Each TWAMM instance facilitates trading between a particular pair of assets, such as ETH and \[FRAX].* *The TWAMM contains an embedded AMM, a standard constant-product market maker for \[...] two assets. Anyone may trade with this embedded AMM at any time, just as if it were a normal AMM.*\ *Traders can submit long-term orders to the TWAMM, which are orders to sell a fixed amount of one of the assets over a fixed number of blocks — say, an order to sell 100 ETH over the next 2,000 blocks.*\ *The TWAMM breaks these long-term orders into infinitely many infinitely small virtual sub-orders, which trade against the embedded AMM at an even rate over time. Processing transactions for each of these virtual sub-orders individually would cost infinite gas, but a closed-form mathematical formula allows us to calculate their cumulative effect only when needed.*\ *The execution of long-term orders will push the embedded AMM's price away from prices on other markets over time. When this happens, arbitrageurs will trade against the embedded AMM's price to bring it back in line, ensuring good execution for long-term orders.*\ *For example, if long-term sells have made ETH cheaper on the embedded AMM than it is on a particular centralized exchange, arbitrageurs will buy ETH from the embedded AMM, bringing its price back up, and sell it on the centralized exchange for a profit."* Interactive comparison of Paradigm’s TWAMM formula and Fraxswap’s TWAMM formula can be found at: ### Code {% embed url="" %} # Fraxswap Contract Addresses Smart contract addresses for Fraxswap V1 & V2 ## Fraxswap V2 V2 includes a new feature, allowing for different LP Fees per pool
ChainFactoryRouter
Arbitrum0x8374A74A728f06bEa6B7259C68AA7BBB732bfeaD0xCAAaB0A72f781B92bA63Af27477aA46aB8F653E7
Avalanche0xf77ca9B635898980fb219b4F4605C50e4ba58afF0x5977b16AA9aBC4D1281058C73B789C65Bf9ab3d3
Binance Smart Chain0xf89e6CA06121B6d4370f4B196Ae458e8b969A0110x67F755137E0AE2a2aa0323c047715Bf6523116E5
Ethereum0x43eC799eAdd63848443E2347C49f5f52e8Fe0F6f

Regular: 0xC14d550632db8592D1243Edc8B95b0Ad06703867

Multihop: 0x25e9acA5951262241290841b6f863d59D37DC4f0

Fantom0xDc745E09fC459aDC295E2e7baACe881354dB7F640x7D21C651Dd333306B35F2FeAC2a19FA1e1241545
Fraxtal0xE30521fe7f3bEB6Ad556887b50739d6C7CA667E6

Regular:

0x2Dd1B4D4548aCCeA497050619965f91f78b3b532

Multihop:
0x67E04873691258950299Bd8610403D69bA0A1e10

Moonbeam0x51f9DBEd76f5Dcf209817f641b549aa82F35D23F0xD356d5b92a2329777310ECa03E7e708D1D21D182
Moonriver0x7FB05Ca29DAc7F5690E9b5AE0aF0415D579D7CD30xD8FC27ec222E8d5172CD63aC453C6Dfb7467a3C7
Optimism0x67a1412d2D6CbF211bb71F8e851b4393b491B10f0xB9A55F455e46e8D717eEA5E47D2c449416A0437F
Polygon0x54F454D747e037Da288dB568D4121117EAb34e790xE52D0337904D4D0519EF7487e707268E1DB6495F
## ------------------------------------- ## ~~Fraxswap V1~~ ~~**DEPRECATED**~~ ### ~~Ethereum~~ ~~Fraxswap Factory: `0xB076b06F669e682609fb4a8C6646D2619717Be4b`~~ ~~Fraxswap Router: `0x1C6cA5DEe97C8C368Ca559892CCce2454c8C35C7`~~ ### ~~Arbitrum~~ ~~Fraxswap Factory: `0x5Ca135cB8527d76e932f34B5145575F9d8cbE08E`~~ ~~Fraxswap Router: `0xc2544A32872A91F4A553b404C6950e89De901fdb`~~ ### ~~Avalanche~~ ~~Fraxswap Factory: `0x5Ca135cB8527d76e932f34B5145575F9d8cbE08E`~~ ~~Fraxswap Router: `0xc2544A32872A91F4A553b404C6950e89De901fdb`~~ ### ~~Binance Smart Chain~~ ~~Fraxswap Factory: `0xa007a9716dba05289df85A90d0Fd9D39BEE808dE`~~ ~~Fraxswap Router: `0x0AE84c1A6E142Ed90f8A35a7E7B216CB25469E37`~~ ### ~~Fantom~~ ~~Fraxswap Factory: `0xF55C563148cA0c0F1626834ec1B8651844D76792`~~ ~~Fraxswap Router: `0xa007a9716dba05289df85A90d0Fd9D39BEE808dE`~~ ### ~~Harmony~~ ~~Fraxswap Factory: `0x5Ca135cB8527d76e932f34B5145575F9d8cbE08E`~~ ~~Fraxswap Router: `0xc2544A32872A91F4A553b404C6950e89De901fdb`~~ ### ~~Moonbeam~~ ~~Fraxswap Factory: `0x5Ca135cB8527d76e932f34B5145575F9d8cbE08E`~~ ~~Fraxswap Router: `0xc2544A32872A91F4A553b404C6950e89De901fdb`~~ ### ~~Moonriver~~ ~~Fraxswap Factory: `0x5Ca135cB8527d76e932f34B5145575F9d8cbE08E`~~ ~~Fraxswap Router: `0xc2544A32872A91F4A553b404C6950e89De901fdb`~~ ### ~~Optimism~~ ~~Fraxswap Factory: `0xBe90FD3CDdaf0D3B8576ffb5E51aDbfD304d0437`~~ ~~Fraxswap Router: `0xffE66A866B249f5d7C97b4a4c84742A393bC9354`~~ ### ~~Polygon~~ ~~Fraxswap Factory: `0xc2544A32872A91F4A553b404C6950e89De901fdb`~~ ~~Fraxswap Router: `0x9bc2152fD37b196C0Ff3C16f5533767c9A983971`~~ # Fraxlend Overview An isolated pair lending protocol ## Summary & Motivation Fraxlend is a lending platform that provides lending markets between a pair of ERC-20 assets. Each pair is an isolated market which allows anyone to participate in lending and borrowing activities. Lenders are able to deposit ERC-20 assets into the pair and receive yield-bearing fTokens. As interest is earned, fTokens can be redeemed for ever-increasing amounts of the underlying asset. The main purpose for the creation of Fraxlend was for usage by the [Fraxlend AMO](/frax-v3-100-cr-and-more/amos). The AMO contract supplies protocol-owned FRAX (and other Frax ecosystem tokens like frxETH and sfrxETH) for other users to borrow, in exchange for those borrowers depositing various collateral tokens and paying interest. This both generates income for the protocol and diversifies the collateral backing FRAX. The max [loan-to-value (LTV)](https://www.investopedia.com/terms/l/loantovalue.asp) for each pair can voted on by the community, but generally is around 75% for pairs with volatile tokens and 90% for stablecoin/stablecoin pairs (the latter is generally less risky). The protocol also maintains a liquidation bot, but liquidations can be performed by any user against any unhealthly/underwater position. **Fraxlend UI:** [Link](https://app.frax.finance/fraxlend/available-pairs) **Public Repo**:

Fraxlend

## Ecosystem Participants ![](/files/BJvMhOyptYnznOuQjAxc) The primary participants in Fraxlend are **Lenders** and **Borrowers**, these participants interact with individual **Pairs**. * Lenders provide Asset Tokens to the pair in exchange for fTokens * Borrowers provide Collateral Tokens to the pair and in exchange receive Asset Tokens. Borrowing incurs an interest rate which is capitalized and paid to lenders upon redemption of fTokens. Beyond **Pairs**, the rest of the ecosystem includes: **Oracles**, **Rate Calculators**, and the **Fraxlend Pair Deployer** * Each pair relies on an **Oracle** to determine the market rate for both the Asset Token and the Collateral Token. Oracles combine price feeds from multiple places to achieve a robust and manipulation resistant price feed. * Each pair is deployed with a **Rate Calculator**. These contracts calculate the interest rate based on the amount of available capital to borrow. Typically less borrowing will lead to lower rates, with more borrowing leading to higher rates. * Each pair is deployed by a **Deployer** contract * The pair **Registry** keeps track of all Fraxlend Pairs deployed # Key Concepts ## Pairs Each pair is an isolated market to borrow a single ERC-20 token (known as the Asset Token) by depositing a different ERC-20 token (known as the Collateral Token). When Lenders deposit Asset Tokens into the Pair, they receive fTokens. fTokens are ERC-20 tokens and are redeemable for Asset Tokens (sometimes referred to as the underlying asset). As interest is accrued, fTokens are redeemable for increasing amounts of the underlying asset. Borrowers deposit Collateral Tokens into the Pair and in exchange receive the right to borrow Asset Tokens ## Loan-To-Value Each borrower's position has a Loan-To-Value (LTV). This represents the ratio between the value of the assets borrowed and the value of the collateral deposited. The LTV changes when the exchange rate between Asset and Collateral Tokens move or when interest is capitalized. If a borrower's LTV rises above the Maximum LTV, their position is considered unhealthy. In order to remediate this, a borrower can add collateral or repay debt in order to move the LTV back into a healthy range. The Maximum LTV value is immutable and configured at deployment. Typically the value is set to 75%. Custom Term Sheet deployments can set this value manually, even creating under-collateralized loans by setting the value above 100%. Maximum LTV configured above 100% must be accompanied by a borrower whitelist to protect against malicious actors. The configured value can be found by calling the `maxLTV()` function on the pair. ## Rate Calculator Each pair is configured to use a specific Rate Calculator contract to determine interest rates. At launch, Fraxlend supports two types of Rate Calculators. * **Time-Weighted Variable Rate Calculator** - allows the interest rate to change based on the amount of assets borrowed, known as the utilization. When utilization is below the target, interest rates will adjust downward, when utilization is above the target, interest rates will adjust upward. For more information see [Advanced Concepts: Time-Weighted Variable Interest Rate](/fraxlend/advanced-concepts/interest-rates#time-weighted-variable-interest-rate) * **Linear Rate Calculator** - calculates the interest rate purely as a function of utilization. Lower utilization results in lower borrowing rate, while higher utilization results in higher borrowing rates. For more information see [Advanced Concepts: Linear Rate](/fraxlend/advanced-concepts/interest-rates#linear-rate) * **Variable Rate V2** - calculates the interest rate as a function of utilization. The interest rate responds immediately to changes in utilization along a rate function f(Utilization) = rate. However, the slope of the function increases when utilization is above the target and decreases when utilization is below the target. This means that rates will respond instantly to changes in utilization. Extended periods of low or high utilization will change the shape of the rate curve. For more information see [Advanced Concepts: Variable Rate V2](/fraxlend/advanced-concepts/interest-rates#variable-rate-v2-interest-rate) ## Liquidations When a borrowers LTV rises above the Maximum LTV, any user can repay all or a portion of the debt on the borrower's behalf and receive an equal value of collateral plus a liquidation fee. The liquidation fee is immutable and defined at deployment. By default the value is set to 10% and can be accessed by calling the `liquidationFee()` view function on the pair. ## fToken Share Price When lenders deposit Asset Tokens they receive fTokens at the current fToken Share Price. fTokens represent a lender's share of the total amount of underlying assets deposited in the pair, plus the capitalized interest from borrowers. As interest accrues, the Share Price increases. Upon redemption, the fTokens are redeemable for an ever-increasing amount of Asset Tokens which includes capitalized interest. To check the current fToken Share Price, call the `totalAsset()` view function and compare the value of amount/shares. ## Vault Account The Vault Account is core concept to all accounting in the Pair. A Vault Account is a struct which contains two values: 1\. The total **Amount** of tokens in the Vault Account. 2\. the total number of **Shares** in the Vault Account. ``` struct VaultAccount { // Represents the total amount of tokens in the vault uint128 amount; // Analogous to market capitalization // Represents the total number of shares or claims to the vault uint128 shares; // Analogous to shares outstanding } ``` The Shares represent the total number of claims to the amount. Shares can be redeemed for Asset Tokens. The rate of redemption, known as the **Share Price** is determined by dividing the Amount value by the Shares value. It is essentially the exchange rate between Shares and the underlying Asset Token. To convert between a value represented as an Amount into the corresponding Shares, divide the Amount by the Share Price. To convert from Shares to Amount, multiply by Share Price. Shares = Amount / Share Price\ Amount = Shares x Share Price # Lending **Lenders** deposit Asset Tokens into the Pair and in return receive the corresponding number of Asset Shares (fTokens) depending on the current Share Price. ![](/files/WllEUzoti3w5jAlvj67Q) At any time a Lender can exchange their fTokens for the underlying Asset Tokens at the rate given by the current price. The fToken Share Price increases as more interest is accrued. Accruing interest is the only operation which can change the Share Price. Because interest accrual is always positive, the number of Asset Tokens that each fToken is redeemable for cannot decrease. ### A Lending Example Alice has deposited 100 FRAX tokens to be lent out to borrowers, the initial fToken Share Price was 1.00 and she received 100 fTokens. Since her initial deposit, the pair has earned 10 FRAX of interest. So the Amount shows 110 (100 deposited FRAX + 10 FRAX earned as interest). The current fToken Share Price is 1.10 (110 FRAX / 100 fTokens)
Asset Vault AccountTotal
Amount110
Shares100
Alice Share Balance (fToken)100
Bob Share Balance (fToken)0
If Bob now deposits 100 FRAX for lending we would see the following changes. First the Amount in the pair will increase by 100. The current Share Price for fTokens is 1.10. Therefore Bob will receive 90.91 (100 / 1.10) fTokens for his deposit. The Asset Vault Account now looks like this:
Asset Vault AccountTotal
Amount210
Shares190.91
Alice Share Balance (fToken)100
Bob Share Balance (fToken)90.91
As interest accrues, the Amount increases. If an additional 20 FRAX are accrued as interest the Asset Vault Account looks like this:
Asset Vault AccountTotal
Amount230
Shares190.91
Alice Share Balance (fToken)100
Bob Share Balance (fToken)90.91
The Share Price has now increased to 1.2048 (230 FRAX / 190.91 fToken). This means that Bob can redeem his 90.91 fTokens for 109.52 FRAX. Likewise, Alice can redeem her 100 fTokens for 120.48 FRAX. Over time, as more interest accrues, Alice and Bob can redeem their fTokens for an ever-increasing amount of the underlying asset. # Borrowing Each pair gives the opportunity for users to borrow Asset Tokens, in return borrowers must supply the Pair with the appropriate amount of Collateral Tokens ![](/files/MrvDQUyPHeuukBBEX0oa) As long as borrowers have an open position, interest accrues and is capitalized. This means that over time the amount a borrower owes increases by an amount equal to the interest they owe. In order for a borrower to receive their collateral back, they must return the original loan amount plus all accrued interest. ### A Borrowing Example Just like we used the Asset Vault Account to keep track of the total asset amounts and the corresponding number of shares, we use the Borrow Vault Account to keep track of the total amount borrowed, the capitalized interest, and the number of outstanding borrow shares. Suppose that Alice has borrowed 100 FRAX ($100 of value) using $150 worth of ETH. Since her initial borrow she has accumulated 10 FRAX of interest. The Borrow Vault Account would appear as follows: | Borrow Vault Account | Total | | --------------------------- | -------- | | Amount | 110 FRAX | | Shares | 100 | | Alice Collateral Amount | $150 ETH | | Alice Borrow Shares Balance | 100 | Remember that borrower's positions must remain below the Maximum Loan-To-Value (LTV). Because Alice's LTV is 73.33% she is below the max value of 75% and her position is considered healthy. We calculate Alice's LTV in the following way. First we calculate the value of her loan to be $110 by multiplying her Borrow Share Balance (100 shares) by the Borrow Share Price (1.10), then multiply by the FRAX price given in USD (1.00). The value of her loan is $100 (100x1.10x1.00). The value of her collateral is $150. This gives $110 / $150 = 73.33% Bob now borrows 100 FRAX, using $175 worth of ETH. Given the current Borrow Share Price of 1.10, his Borrows Shares Balance would be approximately 90.91. Unlike lenders, borrowers do not receive an ERC20 token representing their debt, instead the Share Balances are simply stored in the Pair. Now the Borrow Vault Account looks like this: | Borrow Vault Account | Total | | --------------------------- | -------- | | Amount | 210 FRAX | | Shares | 190.91 | | Alice Collateral Amount | $150 ETH | | Alice Borrow Shares Balance | 100 | | Bob Collateral Amount | $175 ETH | | Bob Borrow Shares Balance | 90.91 | Suppose that the Pair accrues another 20 FRAX of interest. The Borrow Vault Account now looks like this: | Borrow Vault Account | Total | | --------------------------- | -------- | | Amount | 230 FRAX | | Shares | 190.91 | | Alice Collateral Amount | $150 ETH | | Alice Borrow Shares Balance | 100 | | Bob Collateral Amount | $175 ETH | | Bob Borrow Shares Balance | 90.91 | The new Borrow Share Price is 1.2048 (230 / 190.91). This means that in order for Alice to repay her debt she will need to repay 120.48 FRAX (Alice Shares (100) x Share Price (1.2048)). Likewise, Bob would need to repay 109.52 FRAX (Bob Shares (90.91) x Share Price (1.2048)). As interest accrues the amount required to repay the loan increases and the LTV of each position changes. Alice's LTV: 80.32% (120.48 / 150) Bob's LTV: 62.58% (109.52 / 175) As the interest accrued and was capitalized, Alice's position has entered an unhealthy state as her LTV is above the Maximum LTV of 75%. This puts her at high risk of having her position liquidated. # Advanced Concepts [Position Health & Liquidations](/fraxlend/advanced-concepts/position-health-and-liquidations) [Interest Rates](/fraxlend/advanced-concepts/interest-rates) # Position Health & Liquidations ### Position Health Each pair has a configured Maximum Loan-To-Value (LTV). Over time, as interest is capitalized, borrowers must add more collateral or repay a portion of their debt. Otherwise they risk having their position become unhealthy. To determine a borrower’s LTV we use the value of the collateral and the value of the fTokens. $$ LTV=\frac{BorrowShares \times Share Price}{CollateralBalance / ExchangeRate} $$ *Share Price is the price of 1 fToken in Asset Token Units (i.e. AssetToken:fToken ratio)*\ *Exchange Rate is the price of 1 Asset Token in Collateral Units (i.e. Collateral:Asset ratio)* ### Liquidations When a borrowers LTV rises above the Maximum LTV, any user can repay the debt on the borrower's behalf and receive an equal value of collateral plus a liquidation fee. The liquidation fee is immutable and defined at deployment. By default the value is set to 10% and can be accessed by calling the `liquidationFee()` view function on the pair. The configured Maximum LTV can be found by calling the `maxLTV()` function on the pair. ### Dynamic Debt Restructuring Liquidators can close a borrower's position as soon as LTV exceeds the Maximum LTV (typically 75%). However, in cases of extreme volatility, it is possible that liquidators cannot close the unhealthy position before the LTV exceeds 100%. In this unlikely scenario bad debt is accumulated. In this case, the liquidator repays the maximum amount of the borrower's position covered by the borrower's collateral and the remaining debt is reduced from the total claims that all lenders have on underlying capital. This prevents the situation wherein lenders rush to withdraw liquidity, leaving the last lender holding worthless fTokens (commonly known as "bad debt" in other lending markets) and ensures the pair is able to resume operating normally immediately after adverse events. # Interest Rates Each pair is configured to change interest rates as a function of Utilization. Utilization is the total amount of deposited assets which have been lent to borrowers. Fraxlend currently has two interest rate models available for use: 1. The Linear Rate 2. Time-Weighted Variable Rate 3. Variable Rate V2 ### Linear Rate The Linear rate is a configurable function that allows for two linear functions of the form `y = mx +b` . The function takes parameters which are defined at the time the Pair is created. ![](/files/CWQO2Z9n6SpHe4gn3WFP) **Minimum Rate**: Rate when Utilization is 0%\ **Vertex Rate**: Rate when utilization is equal to vertex utilization (i.e when the two slopes meet)\ **Vertex Utilization**: The Utilization % where the two slopes meet\ **Maximum Rate**: Rate when Utilization is 100% These configuration values are immutable and fixed at time of Pair creation. The Interest Rate is calculated using the following formulae: If **Utilization Rate is equal to Vertex Utilization** then: $$ InterestRate(U = U\_{vertex}) = Rate\_{vertex} $$ If **Utilization Rate is less than Vertex Utilization** then: $$ InterestRate(U\U\_{vertex})= Rate\_{vertex} + \left((U - U\_{vertex}) \times \left(\frac{Rate\_{max} - Rate\_{vertex}}{1 - U\_{vertex}}\right)\right) $$ ### Time-Weighted Variable Interest Rate The Time-Weighted Variable Interest Rate adjusts the current rate over time. The variable interest rate is configured with a half-life value, given in seconds, which determines how quickly the interest rate adjusts. **Minimum Rate**: Minimum Rate to which interest can fall\ **Target Utilization Range**: The Utilization Range where the interest rate does not adjust, it is considered in equilibrium with the market expectations.\ **Maximum Rate**: Maximum Rate to which interest can rise\ **Interest Rate Half-Life**: The time it takes for the interest to halve when Utilization is 0%. This is the speed at which the interest rate adjusts. ***In the currently available Rate Calculator, the Interest Rate Half-Life is 12 hours.*** The Time-Weighted Variable Interest Rate allows the market to signal the appropriate interest rate. When **Utilization is below the target range**, the interest rate lowers, this encourages more borrowing and lenders to pull their capital, both of which push the Utilization Rate back into the target range. When **Utilization is above the target range**, the interest rate increases which encourages more lending and less borrowing, bringing the Utilization back towards the target range. Encouraging participants to borrow or lend as a function of both time and utilization. The following graph shows how the interest rate changes when the Interest Rate Half-Life is 4 hours, with a Target Utilization Range of 75% - 85%: ![](/files/flxtoELi1Indlwh2DYcx) This allows the market, not the pair creator, to decide the appropriate interest rate of a given asset-collateral pair, the pair creator only needs to provide a target utilization. ### Variable Rate V2 Interest Rate The Variable Rate V2 Interest Rate combines the concepts from the Linear Interest Rate and the Time-Weighted Variable Interest Rate. Specifically, it utilizes the linear function from the Linear Interest Rate to determine the current rate, but adjusts the vertex and max rate utilizing the formula from the Time-Weighted Variable Interest Rate.
Just like the Time-Weighted Variable Interest Rate, the Variable Rate V2 takes a half-life and target utilization parameters. When utilization is low, the Vertex and Max Rate will decrease. If utilization is high, the Vertex and Max Rate will increase. The rate of the decrease/increase is determined by both the utilization and half-life. If utilization is 0% the Vertex and Max Rates will decrease by 50% each half-life. If the utilization is 100%, the increase will be 100% per half-life. \ \ This means that interest rates will immediately respond to changes in utilization along the linear rate curve while at the same time adjusting to market conditions over the long term by scaling the slope of the linear rate curve. # Vault Account The **Vault Account** is a struct used for accounting in the Fraxlend Pair: ```solidity struct VaultAccount { uint128 amount; uint128 shares; } ``` The **Vault Account** contains two elements: 1. **`amount`** - represents a total amount 2. **`shares`** - represents claims against the amount #### Lending Accounting In lending, **`amount`** represents the total amount of assets deposited and the interest accrued. When lenders deposit assets, the amount of assets deposited increases **`amount`,** the **`shares`** value is also increased by an amount such that the ratio between **`amount`**/**`shares`** remains unchanged. When interest is accrued, **`amount`** is increased and **`shares`** remains the same. Each lender's share of the underlying assets are measured in shares. When lenders remove liquidity, they redeem shares for the underlying asset. The **`shares`** amount will be decreased by the number of shares redeemed, the **`amount`** will be decreased such that the ratio between **`amount`**/**`shares`** remains unchanged. **Borrow Accounting** In borrowing, **`amount`** represents the total amount of assets borrowed and the interest accrued. When borrowers receive assets, the number of tokens received increases **`amount`,** the **`shares`** value is also increased by an amount such that the ratio between **`amount`**/**`shares`** remains unchanged. When interest is accrued, **`amount`** is increased and **`shares`** remains the same. Each borrower's debt is measured in shares. When borrower's repay debt, **`amount`** is decremented by the amount of assets returned, **`shares`** is decreased by an amount such that the ratio of **`amount`**/**`shares`** remain unchanged. An individual borrowers shares balance is decremented by this number of shares. # ABI & Code ### Public Repo {% embed url="" %} ## ABI ### FraxlendPairCore An abstract contract which contains the core logic and storage for the FraxlendPair ### constructor ```solidity constructor(bytes _configData, bytes _immutables, uint256 _maxLTV, uint256 _liquidationFee, uint256 _maturityDate, uint256 _penaltyRate, bool _isBorrowerWhitelistActive, bool _isLenderWhitelistActive) internal ``` The `constructor` function is called on deployment | Param | Type | Description | | --------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | \_configData | bytes | abi.encode(address \_asset, address \_collateral, address \_oracleMultiply, address \_oracleDivide, uint256 \_oracleNormalization, address \_rateContract, bytes memory \_rateInitData) | | \_immutables | bytes | | | \_maxLTV | uint256 | The Maximum Loan-To-Value for a borrower to be considered solvent (1e5 precision) | | \_liquidationFee | uint256 | The fee paid to liquidators given as a % of the repayment (1e5 precision) | | \_maturityDate | uint256 | The maturityDate date of the Pair | | \_penaltyRate | uint256 | The interest rate after maturity date | | \_isBorrowerWhitelistActive | bool | Enables borrower whitelist | | \_isLenderWhitelistActive | bool | Enables lender whitelist | ### initialize ```solidity function initialize(string _name, address[] _approvedBorrowers, address[] _approvedLenders, bytes _rateInitCallData) external ``` The `initialize` function is called immediately after deployment *This function can only be called by the deployer* | Param | Type | Description | | ------------------- | ---------- | ------------------------------------------------------- | | \_name | string | The name of the contract | | \_approvedBorrowers | address\[] | An array of approved borrower addresses | | \_approvedLenders | address\[] | An array of approved lender addresses | | \_rateInitCallData | bytes | The configuration data for the Rate Calculator contract | ### \_totalAssetAvailable ```solidity function _totalAssetAvailable(struct VaultAccount _totalAsset, struct VaultAccount _totalBorrow) internal pure returns (uint256) ``` The `_totalAssetAvailable` function returns the total balance of Asset Tokens in the contract | Param | Type | Description | | ------------- | ------------------- | -------------------------------------------------------------------- | | \_totalAsset | struct VaultAccount | VaultAccount struct which stores total amount and shares for assets | | \_totalBorrow | struct VaultAccount | VaultAccount struct which stores total amount and shares for borrows | | Return | Type | Description | | ------ | ------- | -------------------------------------------- | | \[0] | uint256 | The balance of Asset Tokens held by contract | ### \_isSolvent ```solidity function _isSolvent(address _borrower, uint256 _exchangeRate) internal view returns (bool) ``` The `_isSolvent` function determines if a given borrower is solvent given an exchange rate | Param | Type | Description | | -------------- | ------- | ------------------------------------------------------------------ | | \_borrower | address | The borrower address to check | | \_exchangeRate | uint256 | The exchange rate, i.e. the amount of collateral to buy 1e18 asset | | Return | Type | Description | | ------ | ---- | --------------------------- | | \[0] | bool | Whether borrower is solvent | ### \_isPastMaturity ```solidity function _isPastMaturity() internal view returns (bool) ``` The `_isPastMaturity` function determines if the current block timestamp is past the maturityDate date | Return | Type | Description | | ------ | ---- | ---------------------------------------- | | \[0] | bool | Whether or not the debt is past maturity | ### isSolvent ```solidity modifier isSolvent(address _borrower) ``` Checks for solvency AFTER executing contract code | Param | Type | Description | | ---------- | ------- | ----------------------------------------- | | \_borrower | address | The borrower whose solvency we will check | ### approvedBorrower ```solidity modifier approvedBorrower() ``` Checks if msg.sender is an approved Borrower ### approvedLender ```solidity modifier approvedLender(address _receiver) ``` Checks if msg.sender and \_receiver are both an approved Lender | Param | Type | Description | | ---------- | ------- | --------------------------------------- | | \_receiver | address | An additional receiver address to check | ### isNotPastMaturity ```solidity modifier isNotPastMaturity() ``` Ensure function is not called when passed maturity ### AddInterest ```solidity event AddInterest(uint256 _interestEarned, uint256 _rate, uint256 _deltaTime, uint256 _feesAmount, uint256 _feesShare) ``` The `AddInterest` event is emitted when interest is accrued by borrowers | Param | Type | Description | | ---------------- | ------- | ---------------------------------------------------- | | \_interestEarned | uint256 | The total interest accrued by all borrowers | | \_rate | uint256 | The interest rate used to calculate accrued interest | | \_deltaTime | uint256 | The time elapsed since last interest accrual | | \_feesAmount | uint256 | The amount of fees paid to protocol | | \_feesShare | uint256 | The amount of shares distributed to protocol | ### UpdateRate ```solidity event UpdateRate(uint256 _ratePerSec, uint256 _deltaTime, uint256 _utilizationRate, uint256 _newRatePerSec) ``` The `UpdateRate` event is emitted when the interest rate is updated | Param | Type | Description | | ----------------- | ------- | ------------------------------------- | | \_ratePerSec | uint256 | The old interest rate (per second) | | \_deltaTime | uint256 | The time elapsed since last update | | \_utilizationRate | uint256 | The utilization of assets in the Pair | | \_newRatePerSec | uint256 | The new interest rate (per second) | ### addInterest ```solidity function addInterest() external returns (uint256 _interestEarned, uint256 _feesAmount, uint256 _feesShare, uint64 _newRate) ``` The `addInterest` function is a public implementation of \_addInterest and allows 3rd parties to trigger interest accrual | Return | Type | Description | | ---------------- | ------- | ----------------------------------------------- | | \_interestEarned | uint256 | The amount of interest accrued by all borrowers | | \_feesAmount | uint256 | | | \_feesShare | uint256 | | | \_newRate | uint64 | | ### \_addInterest ```solidity function _addInterest() internal returns (uint256 _interestEarned, uint256 _feesAmount, uint256 _feesShare, uint64 _newRate) ``` The `_addInterest` function is invoked prior to every external function and is used to accrue interest and update interest rate *Can only called once per block* | Return | Type | Description | | ---------------- | ------- | ----------------------------------------------- | | \_interestEarned | uint256 | The amount of interest accrued by all borrowers | | \_feesAmount | uint256 | | | \_feesShare | uint256 | | | \_newRate | uint64 | | ### UpdateExchangeRate ```solidity event UpdateExchangeRate(uint256 _rate) ``` The `UpdateExchangeRate` event is emitted when the Collateral:Asset exchange rate is updated | Param | Type | Description | | ------ | ------- | ---------------------------------------------------------------------------- | | \_rate | uint256 | The new rate given as the amount of Collateral Token to buy 1e18 Asset Token | ### updateExchangeRate ```solidity function updateExchangeRate() external returns (uint256 _exchangeRate) ``` The `updateExchangeRate` function is the external implementation of \_updateExchangeRate. *This function is invoked at most once per block as these queries can be expensive* | Return | Type | Description | | -------------- | ------- | --------------------- | | \_exchangeRate | uint256 | The new exchange rate | ### \_updateExchangeRate ```solidity function _updateExchangeRate() internal returns (uint256 _exchangeRate) ``` The `_updateExchangeRate` function retrieves the latest exchange rate. i.e how much collateral to buy 1e18 asset. *This function is invoked at most once per block as these queries can be expensive* | Return | Type | Description | | -------------- | ------- | --------------------- | | \_exchangeRate | uint256 | The new exchange rate | ### \_deposit ```solidity function _deposit(struct VaultAccount _totalAsset, uint128 _amount, uint128 _shares, address _receiver) internal ``` The `_deposit` function is the internal implementation for lending assets *Caller must invoke `ERC20.approve` on the Asset Token contract prior to calling function* | Param | Type | Description | | ------------ | ------------------- | ---------------------------------------------------------------------------------------------- | | \_totalAsset | struct VaultAccount | An in memory VaultAccount struct representing the total amounts and shares for the Asset Token | | \_amount | uint128 | The amount of Asset Token to be transferred | | \_shares | uint128 | The amount of Asset Shares (fTokens) to be minted | | \_receiver | address | The address to receive the Asset Shares (fTokens) | ### deposit ```solidity function deposit(uint256 _amount, address _receiver) external returns (uint256 _sharesReceived) ``` The `deposit` function allows a user to Lend Assets by specifying the amount of Asset Tokens to lend *Caller must invoke `ERC20.approve` on the Asset Token contract prior to calling function* | Param | Type | Description | | ---------- | ------- | ------------------------------------------------- | | \_amount | uint256 | The amount of Asset Token to transfer to Pair | | \_receiver | address | The address to receive the Asset Shares (fTokens) | | Return | Type | Description | | ---------------- | ------- | ---------------------------------------------- | | \_sharesReceived | uint256 | The number of fTokens received for the deposit | ### mint ```solidity function mint(uint256 _shares, address _receiver) external returns (uint256 _amountReceived) ``` The `mint` function allows a user to Lend assets by specifying the number of Assets Shares (fTokens) to mint *Caller must invoke `ERC20.approve` on the Asset Token contract prior to calling function* | Param | Type | Description | | ---------- | ------- | -------------------------------------------------------------- | | \_shares | uint256 | The number of Asset Shares (fTokens) that a user wants to mint | | \_receiver | address | The address to receive the Asset Shares (fTokens) | | Return | Type | Description | | ---------------- | ------- | -------------------------------------------------- | | \_amountReceived | uint256 | The amount of Asset Tokens transferred to the Pair | ### \_redeem ```solidity function _redeem(struct VaultAccount _totalAsset, uint128 _amountToReturn, uint128 _shares, address _receiver, address _owner) internal ``` The `_redeem` function is an internal implementation which allows a Lender to pull their Asset Tokens out of the Pair *Caller must invoke `ERC20.approve` on the Asset Token contract prior to calling function* | Param | Type | Description | | ---------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | \_totalAsset | struct VaultAccount | An in-memory VaultAccount struct which holds the total amount of Asset Tokens and the total number of Asset Shares (fTokens) | | \_amountToReturn | uint128 | The number of Asset Tokens to return | | \_shares | uint128 | The number of Asset Shares (fTokens) to burn | | \_receiver | address | The address to which the Asset Tokens will be transferred | | \_owner | address | The owner of the Asset Shares (fTokens) | ### redeem ```solidity function redeem(uint256 _shares, address _receiver, address _owner) external returns (uint256 _amountToReturn) ``` The `redeem` function allows the caller to redeem their Asset Shares for Asset Tokens | Param | Type | Description | | ---------- | ------- | ------------------------------------------------------------- | | \_shares | uint256 | The number of Asset Shares (fTokens) to burn for Asset Tokens | | \_receiver | address | The address to which the Asset Tokens will be transferred | | \_owner | address | The owner of the Asset Shares (fTokens) | | Return | Type | Description | | ---------------- | ------- | -------------------------------------------- | | \_amountToReturn | uint256 | The amount of Asset Tokens to be transferred | ### withdraw ```solidity function withdraw(uint256 _amount, address _receiver, address _owner) external returns (uint256 _shares) ``` The `withdraw` function allows a user to redeem their Asset Shares for a specified amount of Asset Tokens | Param | Type | Description | | ---------- | ------- | --------------------------------------------------------------------------------- | | \_amount | uint256 | The amount of Asset Tokens to be transferred in exchange for burning Asset Shares | | \_receiver | address | The address to which the Asset Tokens will be transferred | | \_owner | address | The owner of the Asset Shares (fTokens) | | Return | Type | Description | | -------- | ------- | ------------------------------------------- | | \_shares | uint256 | The number of Asset Shares (fTokens) burned | ### BorrowAsset ```solidity event BorrowAsset(address _borrower, address _receiver, uint256 _borrowAmount, uint256 _sharesAdded) ``` The `BorrowAsset` event is emitted when a borrower increases their position | Param | Type | Description | | -------------- | ------- | ------------------------------------------------------ | | \_borrower | address | The borrower whose account was debited | | \_receiver | address | The address to which the Asset Tokens were transferred | | \_borrowAmount | uint256 | The amount of Asset Tokens transferred | | \_sharesAdded | uint256 | The number of Borrow Shares the borrower was debited | ### \_borrowAsset ```solidity function _borrowAsset(uint128 _borrowAmount, address _receiver) internal returns (uint256 _sharesAdded) ``` The `_borrowAsset` function is the internal implementation for borrowing assets | Param | Type | Description | | -------------- | ------- | --------------------------------------- | | \_borrowAmount | uint128 | The amount of the Asset Token to borrow | | \_receiver | address | The address to receive the Asset Tokens | | Return | Type | Description | | ------------- | ------- | ---------------------------------------------------------- | | \_sharesAdded | uint256 | The amount of borrow shares the msg.sender will be debited | ### borrowAsset ```solidity function borrowAsset(uint256 _borrowAmount, uint256 _collateralAmount, address _receiver) external returns (uint256 _shares) ``` The `borrowAsset` function allows a user to open/increase a borrow position *Borrower must call `ERC20.approve` on the Collateral Token contract if applicable* | Param | Type | Description | | ------------------ | ------- | -------------------------------------------------- | | \_borrowAmount | uint256 | The amount of Asset Token to borrow | | \_collateralAmount | uint256 | The amount of Collateral Token to transfer to Pair | | \_receiver | address | The address which will receive the Asset Tokens | | Return | Type | Description | | -------- | ------- | ---------------------------------------------------------- | | \_shares | uint256 | The number of borrow Shares the msg.sender will be debited | ### \_addCollateral ```solidity function _addCollateral(address _sender, uint256 _collateralAmount, address _borrower) internal ``` The `_addCollateral` function is an internal implementation for adding collateral to a borrowers position | Param | Type | Description | | ------------------ | ------- | ---------------------------------------------------------------- | | \_sender | address | The source of funds for the new collateral | | \_collateralAmount | uint256 | The amount of Collateral Token to be transferred | | \_borrower | address | The borrower account for which the collateral should be credited | ### addCollateral ```solidity function addCollateral(uint256 _collateralAmount, address _borrower) external ``` The `addCollateral` function allows the caller to add Collateral Token to a borrowers position *msg.sender must call ERC20.approve() on the Collateral Token contract prior to invocation* | Param | Type | Description | | ------------------ | ------- | ----------------------------------------------------------------- | | \_collateralAmount | uint256 | The amount of Collateral Token to be added to borrower's position | | \_borrower | address | The account to be credited | ### RemoveCollateral ```solidity event RemoveCollateral(address _sender, uint256 _collateralAmount, address _receiver, address _borrower) ``` The `RemoveCollateral` event is emitted when collateral is removed from a borrower's position | Param | Type | Description | | ------------------ | ------- | ---------------------------------------------------------- | | \_sender | address | The account from which funds are transferred | | \_collateralAmount | uint256 | The amount of Collateral Token to be transferred | | \_receiver | address | The address to which Collateral Tokens will be transferred | | \_borrower | address | | ### \_removeCollateral ```solidity function _removeCollateral(uint256 _collateralAmount, address _receiver, address _borrower) internal ``` The `_removeCollateral` function is the internal implementation for removing collateral from a borrower's position | Param | Type | Description | | ------------------ | ------- | --------------------------------------------------------------------- | | \_collateralAmount | uint256 | The amount of Collateral Token to remove from the borrower's position | | \_receiver | address | The address to receive the Collateral Token transferred | | \_borrower | address | The borrower whose account will be debited the Collateral amount | ### removeCollateral ```solidity function removeCollateral(uint256 _collateralAmount, address _receiver) external ``` The `removeCollateral` function is used to remove collateral from msg.sender's borrow position *msg.sender must be solvent after invocation or transaction will revert* | Param | Type | Description | | ------------------ | ------- | -------------------------------------------- | | \_collateralAmount | uint256 | The amount of Collateral Token to transfer | | \_receiver | address | The address to receive the transferred funds | ### RepayAsset ```solidity event RepayAsset(address _sender, address _borrower, uint256 _amountToRepay, uint256 _shares) ``` The `RepayAsset` event is emitted whenever a debt position is repaid | Param | Type | Description | | --------------- | ------- | ----------------------------------------------------------------------------------- | | \_sender | address | The msg.sender of the transaction | | \_borrower | address | The borrower whose account will be credited | | \_amountToRepay | uint256 | The amount of Asset token to be transferred | | \_shares | uint256 | The amount of Borrow Shares which will be debited from the borrower after repayment | ### \_repayAsset ```solidity function _repayAsset(struct VaultAccount _totalBorrow, uint128 _amountToRepay, uint128 _shares, address _payer, address _borrower) internal ``` The `_repayAsset` function is the internal implementation for repaying a borrow position *The payer must have called ERC20.approve() on the Asset Token contract prior to invocation* | Param | Type | Description | | --------------- | ------------------- | -------------------------------------------------------- | | \_totalBorrow | struct VaultAccount | An in memory copy of the totalBorrow VaultAccount struct | | \_amountToRepay | uint128 | The amount of Asset Token to transfer | | \_shares | uint128 | The number of Borrow Shares the sender is repaying | | \_payer | address | The address from which funds will be transferred | | \_borrower | address | The borrower account which will be credited | ### repayAsset ```solidity function repayAsset(uint256 _shares, address _borrower) external returns (uint256 _amountToRepay) ``` The `repayAsset` function allows the caller to pay down the debt for a given borrower. *Caller must first invoke `ERC20.approve()` for the Asset Token contract* | Param | Type | Description | | ---------- | ------- | ------------------------------------------------------------ | | \_shares | uint256 | The number of Borrow Shares which will be repaid by the call | | \_borrower | address | The account for which the debt will be reduced | | Return | Type | Description | | --------------- | ------- | ------------------------------------------------------------------------------------- | | \_amountToRepay | uint256 | The amount of Asset Tokens which were transferred in order to repay the Borrow Shares | ### Liquidate ```solidity event Liquidate(address _borrower, uint256 _collateralForLiquidator, uint256 _shares) ``` The `Liquidate` event is emitted when a liquidation occurs | Param | Type | Description | | ------------------------- | ------- | --------------------------------------------------------------------------- | | \_borrower | address | The borrower account for which the liquidation occured | | \_collateralForLiquidator | uint256 | The amount of Collateral Token transferred to the liquidator | | \_shares | uint256 | The number of Borrow Shares the liquidator repaid on behalf of the borrower | ### liquidate ```solidity function liquidate(uint256 _shares, address _borrower) external returns (uint256 _collateralForLiquidator) ``` The `liquidate` function allows a third party to repay a borrower's debt if they have become insolvent *Caller must invoke `ERC20.approve` on the Asset Token contract prior to calling `Liquidate()`* | Param | Type | Description | | ---------- | ------- | -------------------------------------------------------------------------------------- | | \_shares | uint256 | The number of Borrow Shares repaid by the liquidator | | \_borrower | address | The account for which the repayment is credited and from whom collateral will be taken | | Return | Type | Description | | ------------------------- | ------- | ------------------------------------------------------------ | | \_collateralForLiquidator | uint256 | The amount of Collateral Token transferred to the liquidator | ### LeveragedPosition ```solidity event LeveragedPosition(address _borrower, address _swapperAddress, uint256 _borrowAmount, uint256 _borrowShares, uint256 _initialCollateralAmount, uint256 _amountCollateralOut) ``` The `LeveragedPosition` event is emitted when a borrower takes out a new leveraged position | Param | Type | Description | | ------------------------- | ------- | ---------------------------------------------------------------------- | | \_borrower | address | The account for which the debt is debited | | \_swapperAddress | address | The address of the swapper which conforms the FraxSwap interface | | \_borrowAmount | uint256 | The amount of Asset Token to be borrowed to be borrowed | | \_borrowShares | uint256 | The number of Borrow Shares the borrower is credited | | \_initialCollateralAmount | uint256 | The amount of initial Collateral Tokens supplied by the borrower | | \_amountCollateralOut | uint256 | The amount of Collateral Token which was received for the Asset Tokens | ### leveragedPosition ```solidity function leveragedPosition(address _swapperAddress, uint256 _borrowAmount, uint256 _initialCollateralAmount, uint256 _amountCollateralOutMin, address[] _path) external returns (uint256 _totalCollateralBalance) ``` The `leveragedPosition` function allows a user to enter a leveraged borrow position with minimal upfront Collateral *Caller must invoke `ERC20.approve()` on the Collateral Token contract prior to calling function* | Param | Type | Description | | ------------------------- | ---------- | ------------------------------------------------------------------------------------------------- | | \_swapperAddress | address | The address of the whitelisted swapper to use to swap borrowed Asset Tokens for Collateral Tokens | | \_borrowAmount | uint256 | The amount of Asset Tokens borrowed | | \_initialCollateralAmount | uint256 | The initial amount of Collateral Tokens supplied by the borrower | | \_amountCollateralOutMin | uint256 | The minimum amount of Collateral Tokens to be received in exchange for the borrowed Asset Tokens | | \_path | address\[] | An array containing the addresses of ERC20 tokens to swap. Adheres to UniV2 style path params. | | Return | Type | Description | | ------------------------ | ------- | ------------------------------------------------------------------------------- | | \_totalCollateralBalance | uint256 | The total amount of Collateral Tokens added to a users account (initial + swap) | ### RepayAssetWithCollateral ```solidity event RepayAssetWithCollateral(address _borrower, address _swapperAddress, uint256 _collateralToSwap, uint256 _amountAssetOut, uint256 _sharesRepaid) ``` The `RepayAssetWithCollateral` event is emitted whenever `repayAssetWithCollateral()` is invoked | Param | Type | Description | | ------------------ | ------- | ------------------------------------------------------------- | | \_borrower | address | The borrower account for which the repayment is taking place | | \_swapperAddress | address | The address of the whitelisted swapper to use for token swaps | | \_collateralToSwap | uint256 | The amount of Collateral Token to swap and use for repayment | | \_amountAssetOut | uint256 | The amount of Asset Token which was repaid | | \_sharesRepaid | uint256 | The number of Borrow Shares which were repaid | ### repayAssetWithCollateral ```solidity function repayAssetWithCollateral(address _swapperAddress, uint256 _collateralToSwap, uint256 _amountAssetOutMin, address[] _path) external returns (uint256 _amountAssetOut) ``` The `repayAssetWithCollateral` function allows a borrower to repay their debt using existing collateral in contract | Param | Type | Description | | ------------------- | ---------- | ---------------------------------------------------------------------------------------------- | | \_swapperAddress | address | The address of the whitelisted swapper to use for token swaps | | \_collateralToSwap | uint256 | The amount of Collateral Tokens to swap for Asset Tokens | | \_amountAssetOutMin | uint256 | The minimum amount of Asset Tokens to receive during the swap | | \_path | address\[] | An array containing the addresses of ERC20 tokens to swap. Adheres to UniV2 style path params. | | Return | Type | Description | | ---------------- | ------- | ------------------------------------------------------------------------------------------------------------ | | \_amountAssetOut | uint256 | The amount of Asset Tokens received for the Collateral Tokens, the amount the borrowers account was credited | # Fraxlend Multisigs
ChainNameAddress
EthereumComptroller0x168200cF227D4543302686124ac28aE0eaf2cA0B
EthereumCircuit Breaker0xfd3065C629ee890Fd74F43b802c2fea4B7279B8c
EthereumOperator0xa4EC124e09D6D1A092c6BD16aFac9CD83f73E3c3
# Overview Frax's liquid ETH staking derivative ## Summary Frax Ether is a liquid ETH staking derivative and stablecoin system designed to uniquely leverage the Frax Finance ecosystem to maximize staking yield and smoothen the Ethereum staking process for a simplified, secure, and DeFi-native way to earn interest on ETH. In addition, frxETH is used as the [gas token](https://docs.frax.com/fraxtal/gas-fees/frxETH) on the Fraxtal L2 chain. Lastly, 10% of the income is retained, with 8% as a protocol fee for the benefit of the Frax Ecosystem and FXS holders, and 2% for an insurance fund. The balance sheet & peg of frxETH to ETH is independent of FRAX's $1 balance sheet & peg. The Frax Ether system comprises three primary components, Frax Ether (frxETH), Staked Frax Ether (sfrxETH), and the Frax ETH Minter: 1. **frxETH** acts as a stablecoin loosely pegged to ETH, leveraging Frax's winning playbook on stablecoins and onboarding ETH into the Frax ecosystem. The frxETH peg is defined as 1% of the exchange rate on each side 1.01 to .9900. 2. **sfrxETH** is the version of frxETH which accrues staking yield. All profit generated from Frax Ether validators is distributed to sfrxETH holders. By exchanging frxETH for sfrxETH, one becomes eligible for staking yield, which is redeemed upon converting sfrxETH back to frxETH. 3. **Frax ETH Minter** (**frxETHMinter**) allows the exchange of ETH for frxETH, bringing ETH into the Frax ecosystem, spinning up new validator nodes when able, and minting new frxETH equal to the amount of ETH sent. ### Liquid Staking Solo ETH staking requires the technical knowledge and initial setup associated with running a validator node, and also that deposits be made 32 ETH at a time. By opting to use a liquid ETH staking derivative instead of staking ETH in another form, staking yield can be accrued much more simply, abstracting the need to run validators, allowing yield to be earned on any amount of ETH, allowing withdrawals at any time and of any size, and allowing far greater composability throughout DeFi. ### Income Distribution Per [FIP-122](https://gov.frax.finance/t/fip-122-frxeth-protocol-fee-structure/1894), the ETH staking income is distributed as follows: 1. **sfrxETH Rewards \[90%]**: Rewarded to sfrxETH vault stakers in the form of frxETH. This generates sfrxETH APY. 2. **Protocol fee \[8%]:** Sent to Frax ecosystem contracts (like AMOs) for the eventual benefit of FXS holders and FRAX peg backing. 3. **Insurance fund \[2%]:** Covers potential slashing events/unforeseen penalties. Backs frxETH deposits to effectively keep frxETH overcollateralized at over 100% CR to cover any possible issues/losses. ### Flowchart
### frxETH flywheel interview with Jack Corddry {% embed url="" %} # frxETH and sfrxETH ETH in the Frax ecosystem comes in two forms, frxETH (Frax Ether), and sfrxETH (Staked Frax Ether). ### frxETH frxETH acts as a stablecoin loosely pegged to ETH, so that 1 frxETH always represents 1 ETH and the amount of frxETH in circulation matches the amount of ETH in the Frax ETH system. When ETH is sent to the frxETHMinter, an equivalent amount of frxETH is minted. Holding frxETH on its own is not eligible for staking yield and should be thought of as analogous as holding ETH. frxETH peg is defined as 1% on each side of 1.00 exchange rate meaning the frxETH peg is defended to keep the exchange rate between 1.01-.9900 ETH per 1 frxETH.

frxETH

### sfrxETH sfrxETH is a ERC-4626 vault designed to accrue the staking yield of the Frax ETH validators. At any time, frxETH can be exchanged for sfrxETH by depositing it into the sfrxETH vault, which allows users to earn staking yield on their frxETH. Over time, as validators accrue staking yield, an equivalent amount of frxETH is minted and added to the vault, allowing users to redeem their sfrxETH for a greater amount of frxETH than they deposited. The exhange rate of frxETH per sfrxETH increases over time as staking rewards are added to the vault. By holding sfrxETH you hold a % claim on an increasing amount of the vault's frxETH, splitting staking rewards up among sfrxETH holders proportional to their share of the total sfrxETH. This is similar to other autocompounding tokens like Aave's aUSDC and Compound's cUSDC.

sfrxETH

# Technical Specifications ### frxETH frxETH shares much of its code with both the Frax and FPI stablecoins, and implements the ERC-2612 standard, allowing spender approvals to be made via ERC-712 signatures passed to the permit() function. ### sfrxETH sfrxETH is a ERC-4626 compliant vault. sfrxETH is obtained by first approving the sfrxETH contract as a frxETH spender, and then calling mint() (mints a specific number of sfrxETH) or deposit() (deposits a specific amount of frxETH). The approval step and the minting step can be combined with depositWithSignature() or mintWithSignature(), removing the need for two seperate transactions. As validators generate staking yield, an equivalent amount of frxETH is minted and sent to the sfrxETH contract. This means that once rewards are synced, one's sfrxETH may be redeemed for a greater amount of frxETH than it took to mint. To prevent malicious users from stealing a validator yield distribution to the vault, reward distributions are smoothed over time cycles. Whenever syncRewards() is called on the sfrxETH contract, any additional frxETH added to the contract over the contract's internal balance is queued to be distributed linearly over the remainder of a cycle window. sfrxETH is also ERC-2612 compliant, allowing the use of signature permits.\ \ For real time information and monitoring of validators, see [Frax Facts](https://facts.frax.finance/frxeth/validators). ### frxETHMinter The frxETHMinter mints frxETH when it receives ETH either through the submit() or receive() function. Whenever a submission pushes the minter balance over 32 ETH, the contract pops a validator's deposit credentials off of a stack and passes the 32 eth deposit along with the credentials to the ETH 2.0 deposit contract, automatically spinning up a new validator. As needed, new credentials are added to the stack to ensure that there are always validators ready to take deposits. If at any time the contract runs out of validators, frxETH will continue to be minted as normal (unless paused) but no new validators will be spun up until more are added to the stack. The withdrawal credential is shared by all the validators on the stack, meaning all validators share the same withdrawal address. This address is set to the Frax treasury contract at launch, so that withdrawals may be safely handled once live. In addition, when adding validators it is necessary to pass the DepositDataRoot as provided when generating the deposit data, this is to provide redundancy in ensuring a validator with misinputted parameters will not be accepted when ETH is deposited. The protocol may set a ratio of funds to withold when ETH is submitted. These funds are not counted when gathering 32 ETH deposits to spin up validators and are instead used to market make across DeFi, ensuring liquid markets for frxETH. ### Frax in-House Validators Each validator's public address and real time stats can be monitored at: \ \ Third party & community tracking of all of frxETH's validators can be found at: # Redemption Mechanism for converting frxETH to ETH 1-to-1 without fees or slippage ## Summary The Frax Ether Protocol allows for frxETH holders to redeem their tokens for ETH using the frxETH Redemption Queue Contract. Since frxETH is collateralized by ETH that are staked in validator nodes, these validators are then ejected to service 1-to-1 redemptions of frxETH for ETH through the redemption contract. Users who opt to redeem their frxETH rather than swap on secondary markets (such as AMMs like Curve) can at any time send their frxETH to the redemption contract for a redemption NFT. This NFT reserves their place in the queue and shows their redemption duration through a timestamp. Once the timestamp is reached, the NFT holder can call a function to swap their NFT for the exact amount of ETH as their redeemed frxETH (without fees or slippage). The redemption process is meant to safeguard against frontrunning, MEV, and other arbtriage externalities by guaranteeing users who have redeemed (ie: who hold the redemption NFT) their fair spot in the queue line. ### frxETH Redemption Queue The frxETH redemption queue is a specific waiting time system that redeemers must wait through to receive ETH for their frxETH. The frxETH redemption queue waiting time is calculated as: `posEntryQueue+posExitQueue+deltaFactor`. This means that the time required to wait to receive ETH is the total time of both entry and exit queue at the time of initiation and an additional amount set by governance so that node operators have a small amount of time to make preparations to eject.\ \ The queue is the sum duration of the Ethereum proof of stake entry and exit queues due to the fact that users staking sfrxETH do not bear any cost of waiting (unlike ETH stakers who must wait the entry queue). Therefore, if the Frax Ether system has no entry queue on receiving staking income, then the entry queue must be accounted for on exit by redeemers. Redeemers must wait the sum total of both entry and exit queues in order to redeem their frxETH for ETH. Otherwise, the system could be vulnerable to griefing attacks where users enter into sfrxETH during periods of long entry queue times, then specifically redeem for ETH during times when the proof of stake exit queue is long. In order to avoid this attack vector, the frxETH redemption system forces redeemers to wait the summation of both queues and a delta factor. **FraxEtherRedemptionQueue:** [`0x82bA8da44Cd5261762e629dd5c605b17715727bd`](https://etherscan.io/address/0x82bA8da44Cd5261762e629dd5c605b17715727bd#code)

Complete transaction flow through the frxETH redemption system.

# frxETH V2 V2 of Frax Ether (frxETH) ## Summary frxETH V2 allows the possibility for anonymous / external validators to enter the frxETH system. All of their ETH staking rewards will flow directly to a ValidatorPool smart contract under their control and thus no frxETH will be minted for them. They will however receive credit which can be used to borrow ETH that entered through the V1 mint mechanism. The collateral for this borrowing is an escrowed exit message, which can be executed by the frxETH protocol if their borrow position becomes unhealthy. The exited funds only go to the ValidatorPool and become "trapped" their until all loans are paid off. The amount of credit per 32 ETH deposited will depend on the validator operator pool. Anonymous pools will only receive 24 ETH borrow credit per 32 ETH. Known / community whitelisted pools can receive up to 31 ETH per 32 ETH deposited. Borrowed ETH can be used to spin up additional validators, or alternatively, withdrawn out of the system for other use by the borrower. An offchain bot, the Beacon Oracle, will constantly monitor the health of all validators / validator pools and execute exit message(s) if a liquidation scenario occurs. Additionally, the interest rate will increase if ETH becomes scarce from redemptions, heavy borrowing, or both. The frxETH protocol will earn income both from investing idle ETH (Curve AMOs) as well as receiving interest from validator pool borrow activity. Existing V1 Frax-operated validators will also earn yield from ETH staking. ### Example borrow

Example borrow chart for a 320E initial supply by the user. Assuming 24E credit per validator.

In this example, if you only put in 320E and nothing else, you can "control" 1248E which is 3.9x. Your LTV is (borrowed ETH) / (total ETH in validators). The LTV is denominated in ETH, so the market price of ETH does not matter. Larger initial amounts will converge to 4x. Max leverage (for 24E per 32E credit) is 32E / (32E - 24E) = 32E / 8E = 4x. Doing 12 rounds as in the example above however would put you dangerously close to the LTV limit and you risk some of your validators being force exited back to the validator pool contract and having the Beacon Oracle bot force repay part of the loan from there. You will also have to pay interest on 928E worth of borrow. If you became whitelisted to say, 28E per 32E, the max effective leverage would be 8x and the max LTV would be 28/32 = 87.5%. This can only be done on a case-by-case basis via a governance vote. # frxETH V2 Technical Details Smart contract and other details ## Overview Flowchart
*** ## Beacon Oracle Validators are monitored, and their exit messages stored, offchain. The Beacon Oracle service/bot will trigger validator exits if borrow positions become unhealthy and/or validators get slashed. It also monitors ValidatorPool deposits, repays, withdrawals, etc and calculates how much borrow credit said pools should have. *** ## Curve AMO Unused ETH can wind up here and be invested into various Convex farms to earn yield passively. When the ETH is needed again, either for borrowing or for frxETH -> ETH redemptions, the farming LP can be unwound back into ETH and sent away. Operated by the Protocol. *** ## Ether Router Serves as a "middleman" contract for ETH flows. ETH from frxETH minting goes here. When ETH is needed for borrowing, it is sent to a ValidatorPool via the LendingPool. When ETH is needed for redemptions, it is sent to the RedemptionQueue. Unused ETH can temporarily be invested in the Curve AMO to earn yield, then be unwound when it is needed again. Profits from ValidatorPool interest payments also collect here. ### Key Functions `getConsolidatedEthFrxEthBalance`: Looks in various places for ETH and frxETH/sfrxETH in various forms, either free or in LPs. This information is primarily used for utilization calculations. `requestEther`: LendingPool calls this when someone borrows, and RedemptionQueue when someone is redeeming. The function first looks for idle ETH in the EtherRouter, then idle ETH in Curve AMOs, then LP'd ETH in the CurveAMOs. `sweepEther`: Operator can periodically sweep idle accumulated ETH into the Curve AMO and subsequent LPs so it can passively earn yield. These LP operations are gassy and hence, this operation is bot-called vs called whenever a normal user interacts (borrow/repay/mint frxETH/etc). *** ## FraxEtherMinter Takes ETH and mints frxETH. The collected ETH flows to the Ether Router to be used for lending, passive income, or frxETH redemption requests. ### Key Functions `mintFrxEth / mintFrxEthAndGive`: Takes in ETH and gives frxETH to the sender or the specified recipient. `submitAndDeposit`: Takes in ETH, converts it to frxETH, then deposits that to generate sfrxETH. Generated sfrxETH sent to the specified recipient. *** ## Lending Pool ValidatorPool partial deposits, borrows, liquidations, and repays go through here. BeaconOracle sets credit/allowances, validator count, etc. ### Key Functions `addInterest / addInterestPrivileged`: Manually accrue interest. Called inline in many other functions. `currentRateInfo`: Gets the interest `ratePerSec` and `fullUtilizationRate`, which can be used to calculate the borrow APR as follows: $$ Borrow APR = ratePerSec \* oneYearInSecs \* 100 $$ `getUtilization`: Gets the current utilization of the ETH in the system. `setValidatorApprovals`: Beacon Oracle bot approves validators for given validator pools. `setVPoolCreditsPerValidator`: Beacon Oracle bot sets the number of credits a validator pool would get per validator deposited. `setVPoolValidatorCountsAndBorrowAllowances`: Beacon Oracle bot adjusts validator count and borrow allowances for given validator pools `wouldBeSolvent`: Used to test if adding validators and/or a borrow amount to a given validator pool would make it insolvent. *** ## RedemptionQueue Users deposit their frxETH and, after a waiting period (varies depending on average Beacon Chain exit queue length), can collect ETH 1:1. After they deposit, they receive a redemption "ticket" NFT that is freely transferable. Their time of entry is marked in the NFT so earlier redeemers have preference over later redeemers if there is an ETH shortage (first come, first served). Due to this change, users will NOT have the option to exit the NFT early for a penalty as they could do in frxETH V1. After the wait, they can burn the redemption ticket NFT and receive back ETH 1:1 to frxETH. ### Key Functions `canRedeem`: Whether a FrxETHRedemptionTicket NFT and a specified amount of ETH can be redeemed. Depends if the NFT reached maturity and if ETH is available, partially or fully. If there is an ETH shortage, earlier NFTs will have redemption preference over later NFTs, even if both are time-eligible for redemption. `ethShortageOrSurplus`: Information as to whether the Redemption Queue has enough ETH to service all outstanding redemption tickets. `enterRedemptionQueue / enterRedemptionQueueWithPermit / enterRedemptionQueueWithSfrxEthPermit / enterRedemptionQueueViaSfrxEth`: Enter the Redemption Queue with either frxETH or sfrxETH, with/without `permit`. Will receive a FrxETHRedemptionTicket NFT after completion. `fullRedeemNft / partialRedeemNft`: Fully / Partially redeem a FrxETHRedemptionTicket NFT for ETH. NFT must have reached maturity. Will revert if there is not enough ETH, or there is, but it is earmarked for earlier NFTs. *** ## Validator Pool Users will need to be able to manage their ValidatorPool (VP). VP contracts are factory generated by the LendingPool contract and deployed by the user. Users deposit their own ETH in the VP, along with the public keys, signatures, and deposit data roots for their validators. All ETH2 staking rewards and exited ETH get sent back to the VP address. MEV can technically go elsewhere (we can't control that). Escrowed exit messages serve as the "collateral" for the system; the exited ETH returns to the VP and is trapped there until all outstanding loans are paid. ### Key Functions `deposit`: Payable function that takes the validator public key, signature, deposit data roots, and msg.value ETH, and deposits it into the ETH2 deposit contract. Integer multiples of 1 ETH between 1 ETH and 32 ETH. If they deposit less than 32 ETH and have the allowance for it, they can borrow the remainder to complete the 32 ETH validator deposit. Users will also have to independently submit the secret exit message to an API endpoint for safe storage before they can receive borrow credit. After reciept, BeaconOracle bot will grant the VP borrowing credit. `requestFinalDeposit`: Completes a 32 ETH deposit to spin up a validator, borrowing any remainder from the protocol in order to do so. For anonymous validators, 24 ETH of borrowing credit is given per 32 ETH deposited. There is an ability in the future for qualified and vetted projects to have more credit, perhaps as high as 31 ETH per 32 ETH deposited. This credit/allowance tracked off-chain to make sure the validator is legitimate, the exit message is escrowed, and the user is otherwise healthy. A bot (BeaconOracle) then periodically updates the allowance amounts on-chain. A special case for the 1st deposit for a given validator pool requires only 8 ETH by the user, with the rest being supplied by the protocol. This is safe for the protocol because the escrowed exit message is still required and if the validator is slashed, there is 8 ETH of buffer before the protocol itself takes a loss. `borrow`: If the validator pool has the allowance, borrows ETH from the LendingPool, which can then be used for spinning up more validators if desired. `repayWithValue`: Payable function that repays the msg.value amount of ETH for the validator pool's loan. Use's sender's ETH. Callable only by the VP owner or the LendingPool (in the case of a liquidation) `repayAmount`: Repays the specified amount of ETH for the validator pool's loan. Uses the validator pool's own ETH. Callable only by the VP owner or the LendingPool (in the case of a liquidation). `repayShares`: Same as `repayAmount` but uses lending shares instead. `withdraw`: Withdraw specified amount of ETH from the ValidatorPool to the intended recipient. Must pay ALL outstanding loans first. Will be unable to reuse the ValidatorPool contract until the BeaconOracle bot catches up and registers the withdrawal. *** ## VariableInterestRate Interest rate math for the ETH borrowing in the LendingPool. Uses same rationale / logic as Fraxlend's [Variable Interest Rate](/fraxlend/advanced-concepts/interest-rates). # frxETH Code & V2 Addresses ## Code {% embed url="" %} ## frxETH / sfrxETH ERC20s Same as [V1](/frax-ether/frxeth-and-sfrxeth-token-addresses). ## Contracts
NameAddress (ETH Mainnet)
BeaconOracle0xA2901F3EE8f4E9F5baC5379BC0CD1F8341280AB5
CurveLsdAmo0xEcb9bBb97BD3C23e8f176075EDB3c68B9a1869Ae
CurveLsdAmoHelper0x823F92b5fF0062EDc20F0545ec88f2f3c273cCbd
EtherRouter0x5acAf61d339dd123e60ba450Ea38fbC49445007C
FraxEtherMinter (V2)0x7Bc6bad540453360F744666D625fec0ee1320cA3
FraxEtherRedemptionQueueV20xfDC69e6BE352BD5644C438302DE4E311AAD5565b
LendingPool0x24A1d1671a3Bd1C3cABb9B10724a4127d84e1Da0
VariableInterestRate0x2fA48925696EbBF1F4Fc08228dA06021f1806544
# frxETH and sfrxETH Token Addresses ## frxETH
ChainAddress
Arbitrum0x178412e79c25968a32e89b11f63B33F733770c2A
Base (LayerZero)0xF010a7c8877043681D59AD125EbF575633505942
Blast (LayerZero)0xF010a7c8877043681D59AD125EbF575633505942
BSC0x64048A7eEcF3a2F1BA9e144aAc3D7dB6e58F555e
Ethereum (native)0x5e8422345238f34275888049021821e8e08caa1f
Ethereum (LayerZero)0xF010a7c8877043681D59AD125EbF575633505942
Fantom0x9E73F99EE061C8807F69f9c6CCc44ea3d8c373ee
Fraxtal (as wfrxETH)As frxETH is the gas token, wfrxETH is the WETH equivalent
wfrxETH: 0xfc00000000000000000000000000000000000006
Fraxtal (LayerZero)0x43eDD7f3831b08FE70B7555ddD373C8bF65a9050
Metis (LayerZero)0xF010a7c8877043681D59AD125EbF575633505942
Mode (LayerZero)0x43eDD7f3831b08FE70B7555ddD373C8bF65a9050
Moonbeam0x82bbd1b6f6De2B7bb63D3e1546e6b1553508BE99
Optimism0x6806411765Af15Bddd26f8f544A34cC40cb9838B
Polygon0xEe327F889d5947c1dc1934Bb208a1E792F953E96
Sei (LayerZero)0x43eDD7f3831b08FE70B7555ddD373C8bF65a9050
X-Layer (Layer-Zero)0x43eDD7f3831b08FE70B7555ddD373C8bF65a9050
## sfrxETH
ChainAddress
Arbitrum0x95aB45875cFFdba1E5f451B950bC2E42c0053f39
Base (LayerZero)0x1f55a02A049033E3419a8E2975cF3F572F4e6E9A
Blast (LayerZero)0x1f55a02A049033E3419a8E2975cF3F572F4e6E9A
BSC0x3Cd55356433C89E50DC51aB07EE0fa0A95623D53
Ethereum (native)0xac3E018457B222d93114458476f3E3416Abbe38F
Ethereum (LayerZero)0x1f55a02A049033E3419a8E2975cF3F572F4e6E9A
Fantom0xb90CCD563918fF900928dc529aA01046795ccb4A
Fraxtal (native)0xFC00000000000000000000000000000000000005
Fraxtal (LayerZero)0x3ec3849c33291a9ef4c5db86de593eb4a37fde45
Metis (LayerZero)0x1f55a02A049033E3419a8E2975cF3F572F4e6E9A
Mode (LayerZero)0x3ec3849c33291a9ef4c5db86de593eb4a37fde45
Moonbeam0xecf91116348aF1cfFe335e9807f0051332BE128D
Optimism0x484c2D6e3cDd945a8B2DF735e079178C1036578c
Polygon0x6d1FdBB266fCc09A16a22016369210A15bb95761
Sei (LayerZero)0x3ec3849c33291a9ef4c5db86de593eb4a37fde45
X-Layer (LayerZero)0x3ec3849c33291a9ef4c5db86de593eb4a37fde45
# frxETH Multisigs
ChainNameAddress
EthereumComptroller0x8306300ffd616049FD7e4b0354a64Da835c1A81C
# Overview (Borrow-AMM) ## Summary The BAMM is a borrowing/lending module built on top of Fraxswap. Unlike other borrowing lending modules, the BAMM does not need an outside oracle or external liquidity to function safely. This is because the needed liquidity is provided by the lenders. With the BAMM we can create borrowing lending services for pairs that were previously impossible, because they did not have a solid oracles or sufficient liquidity. Borrowers rent liquidity provided by lenders to automatically leverage up and down, such that they can stay solvent even in the case of high volatility. This means borrowers can not experience sudden liquidations, so there is also no need to pay high liquidation fees to liquidators, creating a better deal for both borrowers and lenders. Each BAMM pool is build on top of a single Fraxswap pool that holds two tokens. Borrowers can safely long and short each token without fear of sudden liquidation.

Chart - 1 : BAMM Protocol Action Flow

**Lenders** Lenders lend their full range liquidity LP tokens from Fraxswap to the BAMM lending pool. The amount lent is calculated used the following formula: sqrt(X×Y) / LP total supply. Where X and Y are the number of the two tokens in the pool. Lenders earn trading fees from Fraxswap and interest rate from borrowers that rent their liquidity.

Chart - 2 : BAMM Protocol Lender's Action Flow

**Borrowers** Each borrower has its own vault where they put in their collateral, rent liquidity from the liquidity pool and withdraw tokens. Rented liquidity LP tokens are burned when rented and the underlying tokens are put in the users vault to act as collateral. The user can also withdraw tokens from their vault, but they must remain solvent. A user is solvent when the rented liquidity amount is less than 98% of the sqrt(X×Y) of their vault. Note that for both the amount of the rented LP and the assets in the vault, the sqrt(X×Y) is used to calculate solvency. These values are unchanged when there are price movements, so the borrower can not get insolvent when prices change. The borrowers debt, denominated in sqrt(XxY), slowly increases over time due to interest rate payments, so borrowers should periodically check their position to avoid liquidation. The interest rate for the rented liquidity is calculated using a dynamic interest rate model that is used in Fraxlend as well.

Chart - 3 : BAMM Protocol Borrower's Action Flow

# Frax Oracle Overview Oracles for Frax assets that use onchain prices and provide the same interface as Chainlink oracles

Frax Oracles on L1

## Motivation To increase the velocity of adoption of our assets in lending protocols, AMMs, and vault products. We believe that oracles using onchain prices sources are the most reliable and verifiable. ## Major Components ### Dual Oracle / Price Source The Dual Oracle / Price Source contract gets two prices (high and low) from two different onchain sources and returns them both. This contract then writes the prices to the Frax Oracle contract. These contracts are largely inspired by Fraxlend Dual Oracles. Anyone can call the addRoundData() function on the Dual Oracle to add a fresh price to a Frax Oracle. They just need to pay gas. The Frax Protocol calls this function once per day per supported asset. ### Frax Oracle Only the Dual Oracle contract for the proper asset can write prices to a corresponding Frax Oracle. The Frax Oracle stores prices that can be retrieved in the Chainlink style with AggregatorV3Interface or in the Fraxlend getPrices() style.\ \ When interacting with a Frax Oracle through the Chainlink style, the price data will be the average of the low price and high price. When using the Fraxlend getPrices() style, the low and high price will both be given.\ \ Prices will be considered bad / stale if an underlying Chainlink oracle signals a price is bad, or if a price is too old. ## Key Takeaways Frax Oracle prices can be consumed identically to Chainlink oracles. All onchain price sources have deep Frax protocol owned liquidity that we will not remove, which provides a high degree of safety. # How It Works ## Prior Work See for documentation on the Chainlink Oracle interface. ## Supported Frax Assets Currently frxEth/ETH and sfrxEth/ETH are supported. ## Frax Dual Oracle Price Logic ### frxEth The frxEth price is determined from two onchain price sources. The first price source is the frxEth / ETH Curve pool EMA Oracle - [0xa1f8a6807c402e4a15ef4eba36528a3fed24e577](https://etherscan.io/address/0xa1f8a6807c402e4a15ef4eba36528a3fed24e577). This price is bounded to be 0.7 at the lowest (0.7 frxEth = 1 ETH) and 1 at the highest (1 frxEth = 1 ETH). The second price source comes from the Uniswap frxEth / FRAX pool TWAP oracle - [0x36C060Cc4b088c830a561E959A679A58205D3F56](https://etherscan.io/address/0x36C060Cc4b088c830a561E959A679A58205D3F56). We then retrieve the price of ETH in USD from this chainlink oracle ([0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419](https://etherscan.io/address/0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419)) and the price of FRAX in USD from this chainlink oracle ([0xB9E1E3A9feFf48998E45Fa90847ed4D467E8BcfD](https://etherscan.io/address/0xB9E1E3A9feFf48998E45Fa90847ed4D467E8BcfD)). These chainlink prices are used to convert the frxEth / FRAX pool price into a frxEth / ETH price using the following equation: ``` ethPerFrxEth = (fraxPerFrxEthUniswapTwap * usdPerFraxChainlink) / usdPerEthChainlink; ``` This price from Uniswap is similarly bounded between 0.7 and 1, mirroring the Curve price.\ \ The lower of these prices is returned as priceLow and the higher is returned as priceHigh. These prices are then written to the frxEth / ETH Frax Oracle. ### sfrxEth Simply retrieves the pricePerShare() from the sfrxEth contract, retrieves the priceHigh and priceLow in the same manner as the frxEth Dual Oracle outlined above, and returns the following equation: 
priceLow =  (SFRXETH_ERC4626.pricePerShare() * frxEthEthPriceLow) / 1e18;
priceHigh = (SFRXETH_ERC4626.pricePerShare() * frxEthEthPriceHigh) / 1e18;
This works because pricePerShare() returns how many frxEth a single sfrxEth is worth. pricePerShare() goes up over time. These prices are then written to the sfrxEth / ETH Frax Oracle. ## How to use with Chainlink Interface - AggregatorV3Interface Simply call or on the Frax Oracle contract for the asset you want the price of. ## Frax Oracle on L2 Coming soon
# Advanced Concepts ## Getting a Fresh Price Since the Frax protocol only updates Frax Oracle prices once per day, the price may be up to 23 hours and 59 minutes old. If you need a fresher price, you can call addRoundData() on the Dual Oracle to write a fresh price, and then call latestRoundData() / getRoundData() / getPrice() on the Frax Oracle to retrieve the fresh price. ## Smart Contract Design

L1 -> L2

## Timelock Configuration Controls all configurations for all Frax Oracles on L1: [`0x8412ebf45bAC1B340BbE8F318b928C466c4E39CA`](https://etherscan.io/address/0x8412ebf45bac1b340bbe8f318b928c466c4e39ca) Controls all configurations for all Frax Oracles on Arbitrum: [`0xB426B13372B7c967C4a2371B5e95FC7dc37545Db`](https://arbiscan.io/address/0xb426b13372b7c967c4a2371b5e95fc7dc37545db) ## Attacks and Mitigations Oracle manipulation attacks are handled economically. There is too much protocol owned liquidity for manipulating the Curve / Uniswap pools to be profitable.\ \ Bounding prices ensures that frxEth/sfrxEth will never be overvalued and will never be undervalued by more than 30%. frxEth is fully backed with ETH in validators, so the only risk that exists with it is time duration risk. ## Contract Addresses ### L1 #### Dual Oracles / Price Sources FrxEthEthDualOracle: [`0x350a9841956D8B0212EAdF5E14a449CA85FAE1C0`](https://etherscan.io/address/0x350a9841956D8B0212EAdF5E14a449CA85FAE1C0) SfrxEthEthDualOracle: [`0x584902BCe4282003E420Cf5b7ae5063D6C1c182a`](https://etherscan.io/address/0x584902bce4282003e420cf5b7ae5063d6c1c182a) #### Frax Oracles SfrxEthFraxOracle: [`0x3d3D868522b5a4035ADcb67BF0846D61597A6a6F`](https://etherscan.io/address//0x3d3d868522b5a4035adcb67bf0846d61597a6a6f) #### Crosschain ArbitrumBlockHashRelay: [`0x784906554d44d33c2764c86e8848a2bd71c2e3a7`](https://etherscan.io/address/0x784906554d44d33c2764c86e8848a2bd71c2e3a7) ### L2 (Arbitrum) ArbitrumBlockHashProvider: [`0x240ff0894c584d39f992de5fdb603e03fc7e8a98`](https://arbiscan.io/address/0x240ff0894c584d39f992de5fdb603e03fc7e8a98) StateRootOracle: [`0x11afa1d35f246fdc00d789e4a06f682b206f88c9`](https://arbiscan.io/address/0x11afa1d35f246fdc00d789e4a06f682b206f88c9) #### Price Source MerkleProofPriceSource: [`0xb032b46f835fa9e3d95d1e3f46fd307429505f9a`](https://arbiscan.io/address/0xb032b46f835fa9e3d95d1e3f46fd307429505f9a) **Dual Oracles / Price Sources** FrxEthEthDualOracle: TBD SfrxEthEthDualOracle: TBD #### Frax Oracles SfrxEthFraxOracle: TBD
# Fraxtal Merkle Proof Oracles Fraxtal Merkle Oracles (Fraxtal-MOs) are a class of oracles that utilize the [`eth_getProof`](https://docs.alchemy.com/reference/eth-getproof) rpc method to proof L1 State on Ethereum L2s such as Fraxtal. #### Overview Fraxtal-MOs utilize 4 Key contracts in order to verify and transport state. [**FraxchainL1Block**](https://fraxscan.com/address/0x4200000000000000000000000000000000000015#code) Predeploy contract which serves as a registry of L1 block hashes on the L2. [**StateRootOracle**](https://fraxscan.com/address/0xeD403d48e2bC946438B5686AA1AD65056Ccf9512) Contract which verifies a given blockheader against the L1 Blockhash relayed via the `FraxchainL1Block` contract. This contract is responsible for storing the stateroot hash as well as the L1 timestamp. [**MerkleProofPriceSource**](https://fraxscan.com/address/0xe25d8aaa6df41b94a415ee39ccee0df6673b9bdb#code) Contract which performs the state root verification. Given a merkle proof, constructed off chain via the `eth_getProof` rpc method. This contract will verify the and extract the storage slot values "proofed" onto the L2 blockchain. These "proofed" values are then relayed to the oracle itself. The process of relaying these "proofed" values is trustless in the sense that anyone may submit a valid merkle proof corresponding to the pre-approved slots for a given Ethereum L1 address. [**FraxtalERC4626TransportOracle**](https://fraxscan.com/address/0x1b680f4385f24420d264d78cab7c58365ed3f1ff#readContract) Contract which accepts "proofed" L1 data from the `MerkleProofPriceSoure` contract. In the case of `sFrax` and other ERC4626 vaults. These "proofed" values define the current slope of the value accrual function of the vault token on the L1. These oracles expose the following funtions in order to allow the user to query the price of the asset in question: ```solidity /// @dev Adheres to chainlink's AggregatorV3Interface `latestRoundData()` /// @return _roundId The l1Block corresponding to the last time the oracle was proofed /// @return _answer The price of Sfrax in frax /// @return _startedAt The L1 timestamp corresponding to most recent proof /// @return _updatedAt Equivalent to `_startedAt` /// @return _answeredInRound Equivalent to `_roundId` function latestRoundData() external view returns ( uint80 _roundId, int256 _answer, uint256 _startedAt, uint256 _updatedAt, uint80 _answeredInRound ) ``` ```solidity /// @return _pricePerShare The current exchange rate of the vault token /// denominated in the underlying vault asset function pricePerShare() public view returns (uint256 _pricePerShare); ``` #### Architecture The Process of transporting/proving the L1 data onto the L2: Step 1: `Prove the L1 blockHeader on the L2` ![Screenshot 2024-09-23 at 11.04.48 AM](https://hackmd.io/_uploads/HkR4EZyAR.png) Step 2: `Submit the Storage proof for a predefined L1 address and Slots` ![Screenshot 2024-09-23 at 11.05.00 AM](https://hackmd.io/_uploads/H1ih4-J0C.png) #### Demo Client The following code should serve as an example of how to generate the function arguments that are accepted by the fraxtal smart contracts detailed above. Documentation surrounding the RPC methods: [`eth_getBlockByNumber`](https://docs.alchemy.com/reference/eth-getblockbynumber) && [`eth_getProof`](https://docs.alchemy.com/reference/eth-getproof) **To generate the L1 Block Header** ```typescript async function getHeaderFromBlock(provider, blockL1) { let block = await provider.send("eth_getBlockByNumber", [blockL1, false]) let headerFields = []; headerFields.push(block.parentHash); headerFields.push(block.sha3Uncles); headerFields.push(block.miner); headerFields.push(block.stateRoot); headerFields.push(block.transactionsRoot); headerFields.push(block.receiptsRoot); headerFields.push(block.logsBloom); headerFields.push(block.difficulty); headerFields.push(block.number); headerFields.push(block.gasLimit); headerFields.push(block.gasUsed); headerFields.push(block.timestamp); headerFields.push(block.extraData); headerFields.push(block.mixHash); headerFields.push(block.nonce); headerFields.push(block.baseFeePerGas); if (block.withdrawalsRoot) { headerFields.push(block.withdrawalsRoot); } if (block.blobGasUsed) { headerFields.push(block.blobGasUsed); } if (block.excessBlobGas) { headerFields.push(block.excessBlobGas); } if (block.parentBeaconBlockRoot) { headerFields.push(block.parentBeaconBlockRoot); } convertHeaderFields(headerFields); let header = ethers.utils.RLP.encode(headerFields); return header } ``` **To generate a storage proof** ```typescript let blockToProof = "0x"+blockL1.toHexString().substring(2).replace(/^0+/, ""); let sfrax_proof = await mainnetProvider.send("eth_getProof", [ // L1 address to generate proofs for SFRAX_MAINNET, // Slots to proof [ "0x0000000000000000000000000000000000000000000000000000000000000002", "0x0000000000000000000000000000000000000000000000000000000000000009", "0x0000000000000000000000000000000000000000000000000000000000000008", "0x0000000000000000000000000000000000000000000000000000000000000006", "0x0000000000000000000000000000000000000000000000000000000000000007" ], blockToProof ]); // Format the proof info returned from `eth_getProof` let proof: Proof = {} as Proof; proof._accountProofSfrax = sfrax_proof.accountProof; proof._storageProofTotalSupply = sfrax_proof.storageProof[0].proof; proof._storageProofTotalAssets = sfrax_proof.storageProof[1].proof; proof._storageProofLastDist = sfrax_proof.storageProof[2].proof; proof._storageProofRewardsPacked = sfrax_proof.storageProof[3].proof; proof._storageProofRewardsCycleAmount = sfrax_proof.storageProof[4].proof; let txn = await proover.addRoundDataSfrax( SFRAX_L2_ORACLE, blockL1.toString(), proof ) ``` #### Deployed Contracts | Description | Oracle | MerkleProofPriceSource | | -------------- | ---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | sFrax/Frax | [`0x1b680f4385f24420d264d78cab7c58365ed3f1ff`](https://fraxscan.com/address/0x1b680f4385f24420d264d78cab7c58365ed3f1ff#code) | [`0xe25d8aaa6df41b94a415ee39ccee0df6673b9bdb`](https://fraxscan.com/address/0xe25d8aaa6df41b94a415ee39ccee0df6673b9bdb#code) | | sfrxEth/frxEth | [`0xEE095b7d9191603126Da584a1179BB403a027c3A`](https://fraxscan.com/address/0xEE095b7d9191603126Da584a1179BB403a027c3A#code) | [`0xabca0b314d15B3e28F24AC0ee84A63001d1b44Db`](https://fraxscan.com/address/0xabca0b314d15B3e28F24AC0ee84A63001d1b44Db#code) | | FPI/USD | [`0x0f50beeE2d2506634b1e6230F3867e30763CbB02`](https://fraxscan.com/address/0x0f50beeE2d2506634b1e6230F3867e30763CbB02#code) | [`0x8fc7425Cd36D7e4605650198099e4539238e9c37`](https://fraxscan.com/address/0x8fc7425Cd36D7e4605650198099e4539238e9c37#code) | # FAQ ### Why use a fractional stablecoin? {% embed url="" %} **TLDR**: capital efficiency, as well as decentralization. ### How many chains is FRAX on? FRAX the stablecoin is on over 20 different [chains](/frax-v1-original/frax). Ethereum, Fraxtal, and Arbitrum are the largest. FXS, FPI, frxETH, sfrxETH, and sFRAX are also on many of these chains. ### When was FRAX launched? The FRAX token was launched December 20th, 2020 by [Sam Kazemian](https://iq.wiki/wiki/sam-kazemian/), [Travis Moore](https://iq.wiki/wiki/travis-moore/), and [Jason Huan](https://www.linkedin.com/in/jason-huan/). ### What is the relationship between FRAX and Everipedia / IQ.wiki? Frax founders Sam Kazemian and Travis Moore (along with [Theodor "Ted" Forselius](https://iq.wiki/wiki/theodor-forselius/) and [Mahbod Moghadam](https://en.wikipedia.org/wiki/Mahbod_Moghadam)) created [Everipedia](https://iq.wiki/wiki/iqwiki/) (now IQ.wiki) in December 2014. Sam and Travis remain as advisors, but the company is now primarily led by Ted Forselius, [Navin Vethanayagam](https://iq.wiki/wiki/navin-vethanayagam/), and [Cesar Rodriguez](https://iq.wiki/wiki/navin-vethanayagam/). ### How big is the Frax Team? As of 11/8/2024, 13 team members. ### Why does the Frax ecosystem have so many tokens and sub-projects? The purpose of sub-projects like Fraxlend and Fraxswap is to ultimately generate utility for FRAX ecosystem tokens (like FXS, sFRAX, frxETH/sfrxETH) and stabilize / collateralize the FRAX peg. The goal was never to compete with larger competitors (e.g. Aave for Fraxlend, Uniswap for Fraxswap). # Staking Guides for how to stake in various opportunities in the Frax ecosystem # Uniswap Migration / Uniswap V3 Migrating from Uniswap V2 to Uniswap V3 ### How to add liquidity to the FRAX-USDC pool on UNISWAP V3 {% embed url="" %} # Fraxswap / FPI ## Fraxswap {% embed url="" %} ## FPI {% embed url="" %} # All Contract Addresses 1\) \ 2\) Search for "CONTRACT\_ADDRESSES" # Bug Bounty Frax Finance provides one of the largest bounties in the industry for exploits where user funds are at risk or protocol controlled funds/collateral are at risk. \ \ The bounty is simply calculated as the lower value of 10% of the total possible exploit or $10m worth paid in FRAX+FXS (breakdown at team's discretion). Both tokens are immediately liquid. The bounty will be delivered immediately or a maximum turnaround time of 5 days due to timelock+mitigation. This bounty is a "no questions asked" policy for disclosures and/or immediate return of funds after any incident. \ \ Slow arbitrage opportunities or value exchange over a prolonged period is not applicable to this bounty and will receive a base compensation bounty of 50,000 FRAX (prev FXS) or frxUSD (at team discretion). **Note**: This bounty does not cover any front-end bugs/visual bugs or any type of server-side code of any web application that interacts with the Frax Protocol. The above bug bounty is **only** for smart contract code. Smart contract code on any chain that manages Frax Protocol value and/or user deposited value is included in this bounty.\ \ This bounty applies to all smart contracts deployed by the Frax Deployer addresses including Fraxswap AMM, Fraxlend, and frxETH.\ \ **Submission format**: Please submit your disclosure as a private GitHub gist (gist.github.com) containing your proof-of-concept, write-up, and any relevant code. Share the **private** gist link with the team via the contact channels below — do not send raw zip files or executable attachments. Private gists keep the disclosure confidential while making it easy for our engineers to review the code with proper syntax highlighting, version history, and inline comments. If your PoC requires a full repository structure, you may instead share a private GitHub repo and grant access to the Frax security team upon request. \ **Contacts**: you can reach out anonymously through any communication channel including Twitter, Telegram, Discord, or Signal. # Miscellaneous & Bot Addresses Investor Custodian (team hot wallet): `0x5180db0237291A6449DdA9ed33aD90a38787621c` Oracle updater bot (misc on-chain tasks): `0xBB437059584e30598b3AF0154472E47E6e2a45B9` Utility / helper contract deployer (another team hot wallet): `0x36a87d1e3200225f881488e4aeedf25303febcae` # API Subgraphs: Swagger Documentation (V1): Swagger Documentation (V2): Combined Data: Pool APRs and Farm Info: # Audits ## 2020 [Nov 2020 - Certik](https://www.certik.com/projects/fraxfinance) ## 2021 [June 2021 - Trail of Bits](https://github.com/trailofbits/publications/blob/master/reviews/FraxFinance.pdf)\ [Dec 2021 - Trail of Bits](https://github.com/trailofbits/publications/blob/master/reviews/FraxQ42021.pdf) ## 2022 April 2022 - Shipyard / Macro\ [August 2022 - Fraxswap & FPI Trail of Bits](https://github.com/trailofbits/publications/blob/master/reviews/FraxQ22022.pdf)\ [September 2022 - frxETH - Code4rena](https://code4rena.com/reports/2022-09-frax)\ [November 2022 - Fraxlend & Fraxferry - Trail of Bits](https://github.com/trailofbits/publications/blob/master/reviews/2022-10-fraxfinance-fraxlend-fraxferry-securityreview.pdf) ## 2023 Jan 2023 - Fraxlend & veFPIS - Trail of Bits\ [July 2023 - FrxGov - Trail of Bits](https://github.com/trailofbits/publications/blob/master/reviews/2023-05-fraxgov-securityreview.pdf)\ [Oct 2023 - FXB, sFRAX, frxETH Redemption Queue, Frax Oracles - Trail of Bits](https://github.com/FraxFinance/frax-solidity/blob/master/src/audits/FXB%2C%20sFRAX%2C%20frxETH%20Redemption%20Queue%2C%20Frax%20Oracles%20-%20Trail%20of%20Bits%20-%20Oct%202023.pdf) ## 2024 [Jan 2024 - Fraxchain (Fraxtal) - Trail of Bits](https://github.com/FraxFinance/frax-solidity/blob/master/src/audits/Fraxchain%20\(Fraxtal\)%20-%20Trail%20of%20Bits%20-%20Jan%202024.pdf)\ [March 2024 - frxETH V2 - Frax Security Cartel](https://github.com/FraxFinance/frax-solidity/blob/master/src/audits/frxETH%20V2%20Audit%20Report%20-%20Frax%20Security%20Cartel%20-%20March%202024.pdf)\ [April 2024 - Fraxtal, VestedFXS, and Flox - Frax Security Cartel](https://github.com/FraxFinance/frax-solidity/blob/master/src/audits/Fraxtal%20Audit%20-%20April%202024%20-%20Frax%20Security%20Cartel.pdf)\ [May 2024 - FPISLocker & FraxtalERC4626MintRedeemer - Frax Security Cartel](https://github.com/FraxFinance/frax-solidity/blob/master/src/audits/FPISLocker%20%2B%20FraxtalERC4626MintRedeemer%20\(Fraxtal%20sFRAX\)%20-%20May%202024%20-%20Frax%20Security%20Cartel.pdf)\ [May 2024 - Curve AMO for frxETH V2 - Frax Security Cartel](https://github.com/FraxFinance/frax-solidity/blob/master/src/audits/Curve%20AMO%20Audit%20Report%20-%20Frax%20Security%20Cartel%20-%20May%202024.pdf)\ [October 2024 - BAMM - Certora](https://github.com/FraxFinance/frax-solidity/blob/master/src/audits/Frax-Certora%20\(Bamm\)%20report%20-%20%20Final.pdf) ### 2025 [March 2025 - Fraxtal North Star - Frax Security Cartel](https://github.com/FraxFinance/frax-solidity/blob/master/src/audits/Fraxtal%20North%20Star%20Audit%20Report.pdf) # Media Kit / Logos {% file src="/files/SfMi9QEcDXYXuSMgRiQw" %} # Frax : Fractional-Algorithmic Stablecoin 프로토콜 새로운 메커니즘을 가진 분산형 스테이블 코인의 새로운 카테고리 Frax는 최초의 분수 알고리즘 스테이블 코인 프로토콜이다. Frax는 오픈 소스이며, 권한이 없으며 완전히 온체인이며, 현재 이더리움과 12개의 다른 체인에 구현되어 있다. Frax 프로토콜의 최종 목표는 BTC와 같은 고정 공급 디지털 자산 대신 확장성이 높고 분산된 알고리즘 화폐를 제공하는 것이다. 프락스 생태계는 2개의 안정 동전이 있다: FRAX (미국 달러에 고정됨)와 FPI (소비자 물가지수에 고정됨). Frax는 스테이블 코인 디자인의 새로운 패러다임이다. 이것은 친숙한 개념을 지금까지 본 적이 없는 프로토콜로 통합합니다. 프랙셔널 알고리즘 – 프랙스는 공급의 일부가 담보로 뒷받침되는 최초이자 유일한 안정 코인이다. 이는 FRAX가 공급물량의 일부를 부동/무배포한 최초의 스테이블 코인이라는 것을 의미한다. 스테이블 코인(FRAX)은 "분수 알고리즘" 안정 메커니즘의 이름을 따서 명명되었다. 담보화 및 알고리즘의 비율은 시장의 FRAX 스테이블 코인 가격에 따라 달라진다. FRAX가 $1 이상에서 거래되는 경우 프로토콜은 담보 비율을 감소시킨다. FRAX가 1달러 미만으로 거래되는 경우, 프로토콜은 담보 비율을 증가시킨다. 분산 및 거버넌스 최소화 – 커뮤니티가 관리하며 능동적인 관리가 없는 고도로 자율적이고 알고리즘적인 접근 방식을 강조합니다. 완전한 온체인 오라클 – Frax v1은 유니스왑(ETH, USDT, USDC 시간 가중 평균 가격) 및 체인링크(USD 가격) 오라클을 사용합니다. Two Token – FRAX는 코인 당 약 $1 정도의 타이트한 밴드를 목표로 하는 안정적인 코인이다. Frax Share(FXS)은 수수료, 나이 수입, 초과 담보 가치를 발생시키는 지배구조 토큰이다. 암호화폐 네이티브 CPI – FRAX의 최종 비전은 FXS 보유자(및 기타 프로토콜 토큰)가 관리하는 FRAX 가격 지수(FPI)라고 불리는 최초의 암호화 네이티브 CPI 버전을 구축하는 것이다. FRAX는 현재 USD에 고정되어 있지만, 생활수준을 안정적으로 유지하는 최초의 분산형에 허가가 필요 없는 순수 계정 단위가 되기를 열망하고 있다.\ \ 4개의 토큰디자인 – FRAX는 $1/코인 정도의 타이트한 밴드를 목표로 하는 스테이블 코인입니다. Frax Share(FXS)는 수수료, 주조 수익 및 초과 담보 가치를 발생시키는 스마트 계약의 전체 Frax 생태계의 거버넌스 토큰입니다. FPI는 인플레이션에 저항하는 CPI 고정식 스테이블 코인입니다. FPIS는 Frax Price Index의 거버넌스 토큰이며 가치 캡처를 FXS 보유자와 분할합니다. 게이지 보상 시스템 – 커뮤니티는 FRAX 스테이블 코인을 통합하는 전략에 대한 새로운 게이지 보상을 제안할 수 있습니다. FXS 배출량은 고정되어 있고, 매년 반감되며, veFXS 스테이커의 투표에 따라 완전히 다른 게이지로 흐릅니다. 웹사이트: [https://app.\[frax.finance](https://docs.frax.finance/ko/https:/app.\[frax.finance)]\( 텔레그램:[ https://t.me/fraxfinance](https://t.me/fraxfinance)\ 텔레그램 뉴스 (announcements / news):[ https://t.me/fraxfinancenews](https://t.me/fraxfinancenews)\ 트위터:[ https://twitter.com/fraxfinance](https://twitter.com/fraxfinance)\ 미디엄/블로그: (ENG)[ https://fraxfinancecommunity.medium.com/](https://fraxfinancecommunity.medium.com/) (KR) \ 거버넌스 (토론):[ https://gov.frax.finance/](https://gov.frax.finance/)\ 거버넌스 (투표):[ https://snapshot.org/#/frax.eth](https://snapshot.org/#/frax.eth) # 백서(핵심 내용) - FRAX v1 1. 서론 대부분 스테이블 코인 프로토콜은 완전 담보형부터 순수 알고리즘에 의존하는 무담보형(순수 알고리즘형)까지의 스펙트럼이 존재합니다. 담보화 스테이블 코인은 보관 위험이 있거나 실제 대출한 스테이블 코인보다 더 많은 가치의 담보 화폐를 요구하는 초과 담보의 문제가 존재합니다. 하지만 이러한 담보형은 순수 알고리즘형보다 신뢰도가 높은 엄격한 페그를 가진 안정적인 코인을 제공합니다. Basis, Empty Set Dollar, Seignorage Shares와 같은 순수 알고리즘형은 신뢰할 수 없지만 확장성\[1]이 보장된 모델로 비트코인의 초기 비전인 유용한 안정성을 가진 탈중앙화된 화폐에 부합하는 면이 있다. 순수 알고리즘형의 문제는 부트스트랩\[2]에 적용이 어렵고 성장이 느리며 (2020년 4분기에는 어느 것도 중요한 트랙션을 가지고 있지 않다), 스테이블 코인으로서의 유용성을 가지기에는 극단적인 변동을 보인다는 단점을 가지고 있습니다. 그들은 주로 담보형에 대한 진지한 대안보다는 일종의 게임/실험으로 보여집니다. Frax는 담보형, 알고리즘형 두 가지 설계 원칙을 구현하여 확장성을 높이고, 신뢰성을 낮지만 매우 안정적이며 순수한 온체인 화폐의 역할을 하는 첫 번째 스테이블 코인 프로토콜을 목표로 하고 있습니다. Frax 프로토콜은 스테이블 코인인 Frax(FRAX)와 거버넌스 토큰인 Frax Shares(FXS)를 포함하는 두 개의 토큰 시스템입니다. 이 프로토콜에는 USDC 담보를 보유한 풀 계약도 있습니다. 풀은 거버넌스에 인해 추가하거나 삭제할 수 있습니다. 담보의 양이 얼마나 빨리 변화하는지에 대해서는 미리 정해진 시간 프레임은 없지만, FRAX의 사용이 늘어남에 따라, 사용자는 담보보다 알고리즘에 의해 안정화되는 FRAX 공급의 비율이 높아진다는 것에 이 프로젝트에 대한 믿음이 높아질 것입니다. 프로토콜의 담보 비율 새로고침(refresh) 기능은 모든 사용자가 한시간 마다 한 번 호출할 수 있습니다. 이 함수는 FRAX 가격이 1달러를 초과하거나 낮을 경우 담보 비율을 .25% 단위로 변경할 수 있습니다. FRAX가 $1을 초과하면, 함수는 담보 비율을 1단계 낮추고, FRAX의 가격이 $1을 밑돌면 함수는 담보 비율을 1단계 올립니다. 새로 고침 속도와 단계 매개 변수는 모두 거버넌스를 통해 조정할 수 있습니다. 프로토콜의 향후 업데이트에서는 PID 컨트롤러 설계를 사용하여 동적으로 조정할 수도 있습니다. FRAX, FXS 및 담보 가격은 모두 유니스왑\[3]으로 형성된 가격과 ETH:USD 체인 링크 오라클의 시간 가중 평균을 사용하여 계산합니다. 체인 링크 오라클을 사용하면 유니스왑에 의해 형성된 스테이블 코인 풀의 평균이 아닌 실제 미국 달러 가격을 얻을 수 있습니다. 이를 통해 FRAX는 달러 자체에 대해 안정적인 상태를 유지할 수 있으며 기존 스테이블 코인만의 가중 평균을 사용하는 대신 더 높은 탄력성을 제공합니다. "FRAX 스테이블 코인은 시스템에 적절한 양의 구성 부품을 배치함으로써 민팅 될 수 있습니다. 처음 만들 때는 FRAX 스테이블 코인은 100% 담보가 되는데, 달리 말하면 FRAX 스테이블 코인을 민팅할 때 담보가 있어야 합니다. 분할 단계에서 FRAX를 발행하려면 적절한 담보 비율을 배치하고 Frax 쉐어를 소각 시켜야 합니다. 이 프로토콜은 어떤 유형의 암호화폐도 담보로 받아들이도록 설계되었지만, FRAX 프로토콜의 이번 구현은 FRAX가 보다 알고리즘적인 비율로 원활하게 전환될 수 있도록 담보의 변동성을 완화하기 위해 온체인 스테이블 코인을 주로 담보로 받아들일 것입니다. 시스템 속도가 빨라질수록 ETH와 랩핑된 BTC 등 변동성이 큰 암호화폐를 거버넌스를 통해 미래 풀에 포함시키는 것이 더욱 쉽고 안전해집니다. ![](/files/-MVOto8ShadT0JJ-IQLy)
# 가격의 안정성 차익 거래가 FRAX 가격을 안정적으로 유지하는 방법 FRAX는 언제든지 시스템에서 민팅될 수 있고 1달러의 가치로 청산(redeem)할 수 있습니다. 이를 통해 차익 거래자들은(arbitragers) 공개 시장에서 FRAX 수요와 공급의 균형을 잡을 수 있습니다. FRAX의 시장가격이 목표가격인 1달러를 초과하는 경우 FRAX당 1달러의 가치를 시스템에 투입하고 민팅된 FRAX를 공개시장에서 1달러 이상으로 판매함으로써 FRAX 토큰을 또 다시 민팅할 거래 기회가 있습니다. FRAX를 민팅하려면 항상 1달러의 가치를 시스템에 넣어야 합니다. 차이점은 담보와 FXS의 어느 비율이 1달러의 가치를 구성하는가 하는 것입니다. FRAX가 100% 담보 단계에 있는 경우 FRAX를 민팅하기 위해 시스템에 입력되는 값의 100%가 담보화됩니다. 프로토콜이 분수(fractional) 단계로 전환되면 민팅 중에 시스템에 입력되는 값의 일부가 FXS가 됩니다(이후 순환에서 연소됩니다). 예를 들어, 담보 비율이 98%일 경우, FRAX 민팅할 때 $0.98의 담보가 필요하고 $0.02의 FXS가 연소 되야 합니다. 담보 비율이 97%일 경우, FRAX 민팅할 때 $0.97의 담보가 필요하고 $0.03의 FXS가 연소 되야 합니다. FRAX의 시장가격이 1달러의 가격 범위를 밑도는 경우 공개 시장에서 저렴하게 구매하고 시스템에서 1달러의 가치로 FRAX를 청산하여 FRAX 토큰을 교환하는 재정 거래 기회가 있습니다. 사용자는 언제든지 시스템에서 1달러 상당한 가치의 FRAX를 청산할 수 있습니다. 차이점은 담보와 FXS의 어느 비율이 청산자에게 반환되지 않다. FRAX가 100% 담보 단계에 있는 경우 FRAX의 청산에서 반환되는 가치의 100%가 담보화됩니다. 프로토콜이 소수 단계로 전환되면, 청산하는 동안 시스템을 떠나는 값의 일부가 FXS가 된다(청산 사용자에게 제공하기 위해 작성됨). 예를 들어, 담보 비율이 98%일 경우, 한 FRAX를 $0.98의 담보와 $0.02의 민팅된 FXS로 청산할 수 있다. 담보 비율이 98%일 경우, 한FRAX를 $0.97의 담보와 $0.03의 민팅된 FXS로 청산할 수 있다. FRAX의 청산 과정은 원활하고 이해하기 쉬우며 경제적으로 건전합니다. 100% 단계에서는 간단합니다. 분수 알고리즘(fractional algorithmic) 단계에서 FRAX가 민팅되면 FXS가 연소됩니다. FRAX가 교환되면 FXS가 민팅됩니다. FRAX의 수요가 있는 한, 담보와 FXS로 청산하는 행위는 FRAX 민팅을 일으키며 비슷한 양이 순환하게 됩니다(동량의 FXS가 소비됩니다). 따라서 FXS 토큰의 값은 FRAX의 수요에 의해 결정됩니다. FXS 시가총액에 발생하는 가치는 FRAX 시가총액의 무담보 가치의 합계입니다. 이것은 다음과 같이 표시된 곡선 아래의 모든 과거 및 미래 음영 영역의 합계입니다.
![](/files/-MLDNWbCUXuZ8xDMIlCn) 수급 곡선은 FRAX의 민팅과 청산으로 가격이 어떻게 안정되는지를 보여줍니다 (q는 수량, p는 가격). CD0에서 FRAX의 가격은 q0에서 p0 = $1입니다. FRAX의 수요가 증가함에 따라 곡선은 CD1로 오른쪽으로 이동하여 같은 수량 q0에 새로운 가격 p1이됩니다. 가격을 $1로 회복하려면 q1에 도달하고 p0의 가격이 회복될 때까지 새로운 FRAX를 만들어야 합니다. 시가총액은 가격과 수량의 곱으로 계산되므로 q0에서 FRAX의 시가총액은 파란색 사각형입니다. q1에서 FRAX의 시가총액은 푸른 사각형과 녹색 사각형의 면적의 합계입니다. 이 예에서는 수요 증가가 가격 p1에 단순히 반영되기 때문에 수량이 증가하지 않으면 FRAX의 새로운 시가 총액은 동일합니다. 수요가 증가함에 따라 시가총액은 가격 상승 또는 수량 증가(안정된 가격)에 따라 증가합니다. 빨간색 사각형과 녹색 사각형은 같은 면적이며 시가총액에 같은 양의 가치를 추가하기 때문에 이것은 분명합니다. 참고: 녹색 사각형의 반영 부분은 가상 담보 비율 66%에서 새로운 양의 FRAX가 생성될 때 연소되는 FXS의 합계 값을 보여줍니다. FXS 시가총액은 본질적으로 FRAX 수요와 관련이 있기 때문에 이를 시각화하는 것이 중요합니다. 마지막으로, Frax는 불가지론적인 프로토콜이라는 점에 유의해야 합니다. 시장이 장기적으로 어떤 담보 비율에 진정하는지에 대해서는 상정할 수 없습니다. 왜냐하면, 사용자들은 담보가 0%로 떨어지면 이 코인은 완전히 알고리즘적인 것을 인식하며, 이 프로토콜에 대한 신뢰가 떨어질 수도 있기 때문이다. 프로토콜은 담보와 알고리즘 비율에 대한 가정을 하지 않으며, 대신 FRAX의 가격을 1달러로 하기 위해 시장이 요구하는 비율을 유지합니다. 예를 들어, 프로토콜은 60%의 담보 비율에만 도달할 수 있다라고 기정하면 FRAX 공급의 40%만 알고리즘적으로 안정화되고 그 절반 이상이 담보에 의해 뒷받침될 수 있도록 한다. 프로토콜은 FRAX 수요와 FRAX 가격 변경의 결과로 담보 비율을 조정하는 것입니다. FRAX의 가격이 1달러 미만인 경우, 프로토콜은 담보를 재설정하고 신뢰가 회복되고 원 가격인 1달러로 돌아갈 때까지 담보 비율을 올립니다. FRAX의 수요가 다시 증가하지 않는 한 담보 비율을 줄이지 않습니다. 시장 상황에 따라 FRAX가 완전히 알고리즘화될 수도 있지만, 실질적인 담보 비율을 유지하기 위해 재담보화할 것입니다. 우리는 Frax라는 결정론적이고 반사적인 프로토콜이 담보가 뒷받침되지 않는 스테이블 코인에 대한 시장 신뢰를 측정하는 가장 우아한 방법이라고 믿습니다. 이전 알고리즘적 스테이블 코인의 실험에서는 시작부터 시스템에 담보 비율이 없었습니다. 이러한 이전의 시도는 첫날 알고리즘적 스테이블 코인에 대한 시장 신뢰의 부족을 고려하지 않았습니다. Frax가 페그된 USD조차도 세계적으로 유명해질 때까지 법정 통화가 아니었습니다. ## **담보비율** 이 프로토콜은 FRAX의 확장이나 철회 시 담보 비율을 조정합니다. 확장 시 프로토콜은 시스템의 담보의 비율을 낮춤으로서 담보를 줄이고 FXS를 늘리게 되어 FRAX를 민팅하기 원활하게 합니다. 이것은 모든 FRAX를 뒷받침하는 담보의 양을 줄입니다. 철회 기간에 프로토콜의 담보 비율을 높입니다. 이를 통해 시스템 내 담보 비율이 FRAX 공급 비율로 증가하고 FRAX 뒷받침이 증가함에 따라 시장 신뢰가 높아집니다. 초기에는 프로토콜은 담보 비율을 시간당 0.25%씩 조정합니다. FRAX가 1달러 이상이면 함수는 담보 비율을 시간당 1단계 낮추고, FRAX 가격이 1달러 미만인 경우 함수는 담보 비율을 시간당 1단계 올립니다. 이는 FRAX의 가격이 대부분 1달러 이상에 머무르는 경우 담보 비율의 순 움직임이 감소하고 있음을 의미합니다. FRAX의 가격이 대부분 1달러 미만인 경우, 담보 비율은 평균 100%를 향해 증가하고 있습니다. 향후 프로토콜 업데이트에서 가격 유지를 위한 담보 비율 조정은 더 이상 사용되지 않을 것이며 대신 민팅 과정은 경매 기반 시스템으로 이동하여 가격 데이터에 대한 종속성을 제한하고 프로토콜을 추가로 분산시킬 수 있습니다. 이러한 업데이트에서 프로토콜은 FRAX 및 FXS를 포함한 자산에 필요한 가격 데이터 없이 실행될 것입니다. 민팅과 청산은 입찰자가 FRAX를 민팅/청산할 의사가 있는 담보와 FXS의 최고/최저 비율을 게시하는 오픈 경매 블록을 통해 이루어집니다. 이 경매 계약은 시스템 자체의 내부에서 담보 가격을 발견하고 오라클을 통한 가격 정보를 필요로 하지 않습니다. 경매를 대신할 수 있는 또 다른 설계는 PID 컨트롤러를 사용하여 유니스왑 거래 쌍이 풀 자산에 인센티브를 제공하고 공개 시장의 목표 가격에 수렴하는 일정 비율을 유지하는 것과 마찬가지로, FRAX의 재정 거래와 청산 기회를 제공하는 것입니다. ## PIDController (update) 2021년 2월부터 시스템은 PIDController를 사용하여 성장률 변화에 따라 담보 비율을 제어합니다. 이것은 다음과 같이 정의됩니다: $$G\_r = \cfrac{\sum\_{a\_i}^{a\_n} Z\_i \*P\_z}{F}$$ $$G\_r$$ is the growth ratio $$Z\_i$$is the supply of FXS provided as liquidity to a pair on a decentralized AMM (Uniswap, Sushiswap, etc.) $$a\_i$$to $$a\_n$$are the FXS pairs on the AMMs $$P\_z$$is the price of FXS $$F$$is the total supply of FRAX 성장률은 FRAX의 전체 공급에 대해 FXS 코인의 유동성이 얼마나 있는지를 측정하는 것입니다. 성장률이 높을수록 FXS 코인 공급의 전체적인 비율 변화도 덜하면서 상환할 수 있는 FRAX가 많아진다는 사실이 그 측정의 이유입니다. 상환자가 상환된 FRAX에서 발행된 FXS 코인을 판매할 경우, 성장률이 높을수록 FXS의 가격 변동이 적어지므로 바람직하지 않은 부정적인 피드백 루프가 발생할 가능성이 낮아집니다. 성장률 변화에 따라 담보비율이 변화하기 때문에 전체 CR가 낮다는 것은 순 증가율 변화 이전 기간이 순 증가율 변화보다 많다는 것을 의미합니다. 이는 FXS 가격의 지속적인 플러스 상승, 새로 발행된 FXS의 FXS 가격에 영향을 미치지 않는 FRAX의 상환, 또는 AMM으로 유입되는 FXS의 유동성의 증가로 인해 발생할 수 있습니다. $$G\_r = \cfrac{($15M + $12M + $5M)}{(50M)} = 0.54$$ 이전 모델에서는 담보 비율을 변경하기 위해 FRAX 스테이블 코인의 가격만 살펴보는 것이 프로토콜의 부트스트랩 단계에 충분했지만, 최근 시스템의 성장과 현재 크기는 모델을 변경하여 더 정확한 피드백을 가능하게 할 필요가 있습니다. 새로운 시스템은 여전히 가격대를 정하여 FRAX의 가격이 목표대역을 벗어날 때만 담보 비율을 상향 또는 하향 조정합니다. # 민팅 및 상환 FRAX의 발행 및 상환 과정 설명 ## **민팅** ![](/files/-MUy9OgBINzU3XmdFLqw) 모든 FRAX 토큰은 서로 대체 가능하며 어느 담보 비율로 담보되었는지에 관계없이 동일한 비율의 담보를 받을 권리가 있습니다. 이 연립 방정식은 Flex 프로토콜의 민팅 기능을 설명합니다. F 는 새로 민팅된 FRAX의 수: $$F = \overbrace{(Y*P\_y)}^{\text{collateral value}} + \overbrace{(Z*P\_z)}^{\text{FXS value}}$$ $$(1-C\_r)(Y*P\_y) = C\_r(Z*P\_z)$$ $$F$$ 는 새로 민팅 된 FRAX의 단위입니다.\ $$C\_r$$ 는 담보 비율입니다.\ $$Y$$ 는 시스템으로 이전 된 담보 단위입니다.\ $$P\_y$$ 는 Y담보의 USD 가격입니다.\ $$Z$$ 는 소각 된 FXS의 단위입니다.\ $$P\_z$$ 는 FXS의 USD 가격입니다. **예 A: 100% 담보 비율에서 200 USDC($1/USDC)로 FRAX 민팅하기** 명시적으로 말하자면, 1.00의 담보 비율로 FRAX를 200 USDC(1/USDC)로 민팅하는 데 필요한 FXS를 찾는 것부터 시작할 수 있습니다. $$(1-1.00)(100*1.00) = 1.00(Z*P\_z)$$ $$0 = (Z \* P\_z)$$ 따라서, 우리는 프로토콜 담보 비율이 100%(완전 담보)일 때 FRAX를 민팅하기 위해 FXS가 필요하지 않음을 보여준다. 다음으로, 우리는 200 USDC로 FRAX를 얼마나 받을지 계산해야 합니다. $$F = (200\*1.00) + (0)$$ $$F = 200$$ 이 시나리오에서는 200 FRAX가 발행된다. 비율이 100%일 때 FRAX의 전체 가치가 담보물의 달러 가치로 나타내는 것이 보이죠. 방정식의 두 번째 부분이 0으로 취소되기(cancels out) 때문에 Z 및 P z 값과 관계없이 FRAX를 민팅하기 위해 연소하려는 FXS의 양은 사용자에게 반환됩니다. **예 B: 80% 담보 비율과 FXS 가격이 $2/FXS일 때 120 USDC($1/USDC)로, FRAX 민팅하기** 우선 USDC의 해당 수량에 맞춰 FXS가 얼마나 필요한지 파악해야 합니다 $$(1 - 0.8)(120 \* 1.00) = 0.8(Z\*2.00)$$ $$Z = 15$$ 따라서, 우리는 이러한 조건에서 120 USDC와 함께 15개의 FXS를 입금해야 합니다. 다음으로, 우리는 FRAX를 얼마나 받을지 계산합니다. $$F = (120*1.00) + (15*2.00)$$ $$F = 150$$ 이 시나리오에서는 150 FRAX가 발행됩니다. 120 FRAX는 USDC의 담보로 보장되며, 나머지 30 FRAX는 어떠한 보장도 받지 않습니다. 대신, FXS는 알고리즘적으로 민팅듼 FRAX의 값에 비례하여 연소하고 순환에서 제거됩니다. **예 C: 50% 담보 비율과 FXS 가격이 $3.50/FXS일 때 220 USDC($0.09995/USDC)로, FRAX 민팅하기** 필요한 FXS의 양을 찾는 것부터 시작합니다. $$(1-.50)(220\*.9995) = .50(Z\*3.50)$$ $$Z = 62.54$$ 다음으로, 우리는 FRAX를 얼마나 받을지 계산합니다. $$F = (220\*.9995) + (62.54\*3.50)$$ $$F = 437.78$$ 이 시나리오에서 437.78 FRAX 발행됩니다. 이에 비례하여, 새로 민팅된 FRAX의 절반은 담보로 USDC의 가치 담보에 의해 보장되고 나머지 50%는 보장되지 않습니다. 62.54 FXS는 연소되고 유통에서 제거되는데, 이는 새로 민팅된 FRAX의 절반 값입니다. 담보물의 가격은 얼마나 많은 FRAX를 민팅할 수 있는지에 영향을 미칩니다. FRAX는 USDC의 1단위가 아닌 1USD로 고정됩니다. 담보물과 함께 충분한 FXS가 주조 기능에 투입되지 않으면 subtraction underflow 오류로 인해 트랜잭션이 실패합니다. ## 청산(Redeeming) FRAX는 단순성을 위해 이전의 방정식 체계를 재정렬하고, 담보 양 Y와 FXS 양 Z에 대해 풀어서 이루어집니다. F 는 청산된 FRAX의 수 $$Y = \dfrac{F\*(C\_r)}{P\_y}$$ $$Z = \dfrac{F\*(1-C\_r)}{P\_z}$$ $$F$$는 상환된 된 FRAX의 단위입니다.\ $$C\_r$$는 담보 비율\ $$Y$$는 사용자에게 이전 된 담보 단위입니다.\ $$P\_y$$는 Y 담보의 USD 가격입니다.\ $$Z$$는 사용자에게 민팅 된 FXS의 단위입니다.\ $$P\_z$$는 FXS의 USD 가격입니다. **예 D: 65% 담보 비율에서 FRAX 청산하기. 오라클(Oracle)의 가격은 $1.00/USDC 그리고 FXS는 $3.50/FXS.** $$Y = \dfrac{170\*(.65)}{1.00}$$ $$Z = \dfrac{170\*(.35)}{3.75}$$ 이럼으로써, Y = 110.5 그리고 Z =15.867 170 FRAX를 청산하면 현재 FXS 시장 가격으로 170달러의 가치인 110.5 USDC의 상환자에게 반환되고 새로 민팅된 FXS 토큰 15.867개가 반환됩니다. 또한 플래시 대출(flash loans)에 대한 보호를 위해 청산된 담보의 인출에 대한 2블록 지연 매개 변수(지배구조(governance)로 조정 가능)가 있습니다. **참고: 이러한 예는 0.20%와 0.45% 사이에 설정된 민팅 및 청산 수수료를 고려하지 않습니다.**
# Frax Shares (FXS) (FXS 토큰은 전체 FRAX 생태계의 가치 발생을 시키는 거버넌스 토큰입니다. 모든 유틸리티는 FXS에 집중됩니다.) FRAX 공유 토큰(FXS)은 스테이블 코인이 아닌 유틸리티 토큰입니다. FXS는 변덕스러우며 의결권과 시스템의 모든 효용에 대한 권리를 보유하도록 의도되었습니다. FXS는 비트코인과 같은 정신으로 신용이 필요 없는 화폐를 설계하기 위해 고도의 거버넌스 최소화 접근 방식을 취하고 있습니다. 우리는 MakerDAO가 하는 것과 달리 DAO 같은 적극적인 경영을 피합니다. 적극적으로 관리해야 하는 매개 변수가 적을수록 이견이 줄어 들기 때문입니다. FXS를 통해 거버넌스를 위한 파라미터에는 담보 풀 추가 및 조정, 다양한 수수료 조정(민팅 또는 리딤잉 등), 담보 비율 갱신 등이 포함됩니다. 완전히 새로운 구현으로 자발적으로 이동해야 하는 하드포크 이외에는 담보물의 능동적 관리 또는 인간 수정 가능한 매개 변수의 추가와 같은 다른 어떤 조치도 가능하지 않습니다 FXS 토큰은 가치의 델타 변화\[1]가 항상 FRAX 토큰 자체에서 벗어나 안정되는 시스템의 상향 유틸리티와 하향 유틸리티의 잠재력을 가지고 있습니다. FXS 공급은 초기에는 1억 토큰으로 설정되지만 FRAX가 더 높은 알고리즘 비율로 민팅되기 때문에 유통량은 디플레이션적일 것으로 보입니다. 이 프로토콜의 디자인은 FRAX 수요가 증가하는 한 FXS가 공급에서 크게 디플레이션적으로 될 수 있도록 설계되었습니다. FXS 토큰의 시가총액은 영속적인 FRAX 토큰의 시뇨리지(seigniorage)\[2], 민팅 및 청산 수수료에서 발생하는 화폐의 흐름, 사용되지 않은 담보물의 활용에서 발생하는 미래 예상 순 가치 창출로 계산해야 합니다. 또한, FXS의 시가총액이 증가함에 따라 FRAX를 안정적으로 유지하는 시스템의 능력도 향상합니다. 따라서 FRAX를 안정적인 통화로 유지하면서 FXS 토큰에 최대 가치를 부여하는 것이 중요합니다. 클리어메틱스의 CEO인 Robert Sam이 시뇨리지 쉐어 화이트페이퍼(Seigniorage shares whitepaper)에서 설명한 바와 같이, "쉐어 토큰(share token)은 중앙은행의 대차대조표의 자산 측면과 같습니다. 어느 시점에서든 주식의 시가총액은 코인 공급을 얼마나 줄일 수 있는지에 대한 상한선을 정합니다." 마찬가지로 Frax가 시뇨리지 쉐어 모델(seignorage share model)의 일종이기 때문에 Sam의 제안에서 영감을 얻습니다. \ **veFXS & 장기간 스테이킹** 2020년 5월, 이 프로토콜은 현재 FXS 보유자들이 veFXS를 생성하기 위해 FXS 토큰을 잠글 수 있도록 허용하고 있으며, 특별한 부스트(special boosts), 특별한 지배권, AMO 이익을 얻을 수 있습니다. 모든 veFXS 기능이 작동하는 방식에 대한 자세한 내용은 \ 항목에서 확인하십시오.
![FXS의 현재 유틸리티 도식 (Frax v2에 더 많은 가치 발생 메커니즘이 추가됨)](/files/-MVG9W_8fJNC_D62V0Gr) # 결론 Frax 프로토콜을 시각화하기 위한 목표 및 기능적 방법 마무리 생각 및 프락스 프로토콜을 기능적으로 이해하고 보는 방법
Frax는 유니스왑과 같은 AMM\[1]을 활용해 지금까지 볼 수 없었던 참신한 하이브리드 스테이블 코인 디자인을 만들었습니다. 유니스왑 풀에서 자산 A와 B의 비율은 일정한 곱 함수로 인해 비례해야 합니다. 유동성 풀(LP) 토큰은 풀 + 수수료에 대한 비례적 청구이므로 일반적으로 가치가 증가하거나(수수료가 영구 손실보다 높은 경우) 가치를 줄어듭니다(수수료보다 영구 손실이 큰 경우). LP 토큰은 풀에 대한 수동 클레임일 뿐입니다. Frax는 이 아이디어를 받아들여 독특한 스테이블 코인을 디자인하는데 사용했습니다. LP 토큰은 스테이블 코인인 FRAX입니다. 안정화의 대상이며 항상 1달러 상당의 담보와 담보 비율의 거버넌스(FXS) 토큰에 대해 민팅되거나 청산될 수 있습니다. 이 두 자산(담보 및 FXS)의 비율은 스테이블 코인의 가격에 따라 동적으로 변경됩니다. 안정적인 코인 가격이 하락하고 있다면, 프로토콜은 FXS의 담보에 유리하게, FXS 토큰에 덜 유리한 비율로 조정하여 FRAX에 대한 신뢰를 회복합니다. 이 "재담보 스왑"(recollateralization swap)을 위해 프로토콜이 결정하는 할인된 FXS에 대한 새로운 비율로 담보물을 풀에 넣기를 원하는 사람들에게 차익 거래 기회가 발생합니다. 이것은 프로토콜을 보다 높고 새로운 담보 비율에 재담보화합니다. FRAX가 $1 이상이면 프로토콜은 FXS의 담보 비율을 조정하여 알고리즘적으로 안정화되는 FRAX의 더 많은 공급에 대한 시장의 신뢰를 측정합니다. FRAX가 더욱더 알고리즘화되면서 초과 담보물은 누구나 부를 수 있는 환매 기능을 통해 FXS 보유자에게 돌아갈 수 있습니다. "환매 스왑" 기능은 시스템에 과도한 수수료/담보/가치가 있을 때마다 항상 거버넌스 토큰에 가치를 부여합니다. 이러한 Frax의 움직임은 항상 일어나며 AMM을 사용하여 담보의 비율을 테스트하고, 차익거래 스왑을 통해 담보화를 장려하며, 환매를 통해 초과 가치를 FXS 보유자에게 다시 재분배합니다. Frax 프로토콜은 처음에는 100% 부수적인 비율로 시작하며 순수 알고리즘에 도달할 수도 있고 그렇지 않을 수도 있습니다. 새로운 통찰은 시장력 자체를 이용해 자체 시니어 나이 토큰으로 얼마나 안정적인 코인이 알고리즘적으로 안정될 수 있는지 살펴 ‘명목 코인’ 처럼 1달러 안팎의 가격대를 유지하는 것입니다. Basis, ESD 및 시뇨리제 쉐어와 같은 순수 알고리즘형 코인은 가격이 1달러 전후로 +-40%까지 크게 변동하며, 다른 사이클을 거치기 전에 안정화하는 데 며칠/주가 소요됩니다. 이는 비생산적이며 시장이 원하거나 필요한 0% 담보로 스테이블 코인과는 맞지 않습니다. Frax는 이런 낭비를 하지 않습니다. 대신 시장의 선호도를 측정해 1달러 안팎의 스테이블 코인을 소유하는 실제 담보비율을 찾아 FRAX 가격이 소폭 오르내릴 때 비율의 작은 차이를 주기적으로 테스트합니다. Frax는 AMM 기술을 사용하여 가격 회복 속도가 유니스와프 만큼 빠른 실시간 분수적인 알고리즘 스테이블 코인을 만듭니다. 이 시스템이 더 효율화되고 시스템의 속도가 빨라지면서 담보 풀은 ETH와 같은 휘발성 암호화폐와 랩된(wrapped) BTC와 같은 스테이블 코인 대신 다른 자산을 포함할 수 있습니다. 변동성 자산의 가격이 상승함에 따라 사용자는 환매(Buyback) 기능을 사용하여 초과 가치를 FXS 보유자에게 분배하게 됩니다. 변동성 담보물 가격이 떨어지면 즉시 할인된 FXS에 더 많은 암호화폐를 넣어 담보 비율을 목표치로 유지할 수 있는 차익 거래 기회가 생깁니다. 지속적인 제품 기능을 균형 있게 유지하는 유니 스와프 거래 쌍처럼 Frax 프로토콜은 목표 담보비율을 FRAX가 1달러가 되도록 시장이 필요로 하는 금액에 맞춰 균형 있게 유지합니다. 위의 예에서는 프로토콜 내의 "담보형"과 "FXS"에 두 자산을 사용하지만, 실제로 Frax는 Balancer와 유사하게 가중치를 갖는 여러 개의 알고리즘 토큰 풀을 가질 수 있습니다. 프로토콜에는 현재 USDC 담보 풀과 단 하나의 알고리즘 토큰, FXS가 있습니다. 하지만 v2에서는 금리가 부착된 순수 부채를 나타내는 두 번째 알고리즘 토큰인 Frax 본드 토큰(FXB, 영어로 Frax Bond Token)을 출시할 예정입니다. 우리는 Frax의 분수 알고리즘 디자인이 스테이블 코인 세계의 패러다임을 바꾸고 있다고 믿습니다. Frax는 빠르고, 알고리즘적이며, 실시간 조정이 가능하고, 거버넌스 최소화 및 복원력이 뛰어납니다. 우리는 Frax 프로토콜이 모든 암호화폐 커뮤니티가 포용할 수 있는 신용이 필요없는 스테이블 코인을 만들기 위한 알고리즘적인 통화 정책을 입증함으로써 비트코인의 '하드머니 ' 서술의 구현이 될 수 있다고 굳게 믿습니다. # AMO 개괄 구성 가능하고 자율적인 중앙 은행 블럭을 위한 프레임워크 Frax v2는 "알고리즘 시장 운영 컨트롤러"(AMO, 영어로 Algorithmic Market Operations controller)의 아이디어를 도입함으로써 분수 알고리즘 안정성의 개념을 확장합니다. AMO 모듈은 FRAX 가격을 페그에 유지하면서 독단적인 통화 정책을 제정하는 자율 계약입니다. 이것은 AMO 컨트롤러가 (이름와 같이) 오픈 마켓 연산을 알고리즘적으로 수행할 수 있지만, 임의로 FRAX를 민팅하여 페그를 깨뜨릴 수는 없다는 것을 의미합니다. 이것은 FRAX의 기본 계층 안정성 메커니즘을 손대지 않은 상태로 유지하며, 이것은 우리 프로토콜을 돋보이게 하며 다른 작은 프로젝트에 영감을 주는 것의 핵심이 되었습니다. **Frax v1: 배경** Frax v1에서는 분수 알고리즘 안정성 메커니즘인 단일 AMO만 있었습니다. 이를 기본 안정성 메커니즘이라고 합니다. 이전 문서들에서 이 문제에 대해 읽을 수 있습니다. Frax v1에서, 프로토콜의 담보 비율은 Frax 스테이블 코인의 시장가격을 기준으로 동적으로 재조정됩니다. FRAX의 가격이 1달러 이상이면, 담보 비율(CR)이 감소합니다. FRAX의 가격이 $1 미만이면 CR가 증가합니다("재담보화"). 이 프로토콜은 항상 $1 페그에서 FRAX의 상환을 존중하지만, CR는 동적이기 때문에, 나머지 금액에 대해 Frax 공유 토큰(FXS)을 발행하여 FRAX의 상환을 지원해야 합니다. 예를 들어, 85% CR에서 모든 상환된 FRAX는 사용자에게 USDC $.85와 FXS $.15를 제공합니다. 프로토콜이 상환자 $.15 가치의 FXS에 직접 반환되는지, 아니면 담보로 1달러의 완전한 가치를 반환하기 위해 FXS를 체인에서 원자적으로 판매하는지는 사소한 구현 세부 사항일 뿐 경제적 구현은 같습니다. **이 기본 메커니즘은 다음과 같이 추상화할 수 있습니다.** 1\. 무담보화(decollateralise) - FRAX가 $1을 초과할 경우 CR를 약간씩 낮춥니다. 2\. 균형 - FRAX = $1인 경우 CR는 유지됩니다. 3\. 반복 - FRAX가 $1 미만인 경우 CR를 약간 증가시킵니다. 4\. FXS 가치 발생 메커니즘(value accrual mechanism) - FXS를 지지가 되지 않은 FRAX, CR을 조과하는 담보 및 수수료로 연소합니다. Frax 프로토콜은 시장의 FRAX 가격에 기초하여 대차대조표 비율을 조정하는 은행적인 알고리즘입니다. 담보 비율은 단순히 프로토콜 자본(담보) 대 부채(FRAX 테이블코인) 의 비율입니다. 시장은 이 비율이 어떤 기준에 유지돼야 하는지 대해서 투표를 합니다. 비율이 너무 낮을 경우 FRAX를 매각 및 종료, 즉 가격을 1달러 이하로 조금 낮추고, 비율이 너무 높을 FRAX를 계속 요구하며 가격을 1달러 이상으로 조금 높입니다. 이 무담보화와 재담보화는 프로토콜이 매우 엄격한 페그를 유지하고 자금 창출의 자본 효율을 최대화하기 위한 정확한 준비금의 양을 찾는 데 도움이 됩니다. **정의에 따르면 프로토콜은 시장이 요구하는 FRAX 스테블코인의 정확한 양을, 요구하는 정확한 담보비율로 1달러의 FRAX를 민트합니다.** **Frax v2: AMOs** 따라서 우리는 안정성 메커니즘의 완전히 맞춘 디자인 공간을 만들기 위해 임의의 복잡한 시장 조작에 이전의 메커니즘을 일반화할 수 있습니다. 따라서 각 AMO는 중앙은행의 화폐 블록으로 볼 수 있습니다. 각 AMO는 4개의 속성이 있습니다: 1\. 담보해제 - CR을 낮추는 전략부분 2\. 시장운용 - 전략 중 CR를 변경하지 않는 부분적으로 CR를 변경하지 않는 부분 3\. 재담보화 - CR을 증가시키는 전략부분 4\. FXS1559 - AMO의 대차대조표의 형식화된 회계처리. 목표 CR 이상의 이익으로 FXS를 얼마나 연소할 수 있는지를 정확하게 정의합니다. 상기의 메커니즘이 명확하게 정의되어 있어서 Frax v1이 AMO의 가장 단순한 형식임을 쉽게 알 수 있습니다. 즉 Frax 1이 기본적으로 가능한 AMO의 기본적인 케이스입니다. v1에서는 담보 해제로 자금 공급의 확대와 과잉 담보가 FXS 연소의 유입이 가능하게 합니다. 재담보화는 FXS를 민트하고 담보 비율을 높여 부채를 줄이는데 이를 FRAX 상환이라 부릅니다.. 기본적인 분수 알고리즘 메커니즘은 항상 이전과 같이 실행되고 있습니다. FRAX 가격이 페그 초과된 경우, CR를 낮추고 FRAX의 공급이 정상적으로 확대되며 AMO 컨트롤러도 계속 가동합니다. 페그를 유지할 수 없을 정도로 CR를 내리면 AMO는 사전에 재담보화 조작을 실시하여 CR를 증가시킵니다. 프로토콜 부채(스테이블 코인들)가 상환되고 CR가 상승하여 페그로 돌아오면 시스템은 이전과 같이 담보로 재설정됩니다. 이로써 모든 AMO가 시장의 힘에 의해 조작되며 v1 기반 케이스의 완전한 설계 사양이 유지됩니다. AMO는 기반 안정 메커니즘을 변경하지 않고 최대한의 유연성과 기회를 창출하며 FRAX가 가장 강력한 스테이블 코인 프로토콜의 하나가 되게 하며 분수 알고리즘 스테이블 코인 공간(fractional algorithmic space)의 리더로 만듭니다. AMO 모듈은 모듈러 디자인 공간을 제공하여 설계의 우아함, 컴포지빌리티(compositability), 기술적인 복잡성(complexity)을 해치지 않고 지속적인 업그레이드와 개량을 가능하게 합니다. 마지막으로 AMO는 완전한 '박스 내의 메커니즘(mechanism-in-a-box)'이기 때문에 상기 사양에 준거하고 있는 한 누구나 AMO를 제안, 구축 및 작성할 수 있습니다. 인용 링크 1\. [원문](https://samkazemian.medium.com/frax-v2-algorithmic-market-operations-b84521ed7133) 2\. [트위터 요약글](https://twitter.com/samkazemian/status/1380022644280414212) \
# FXS1559 FXS 토큰을 위한 가장 강력한 효용 증가 메커니즘 **참고: 거버넌스는 이 투표 후 프로토콜 이익의 100%를 veFXS 수익률로 옮기기로 결정했습니다. 아래의 이 문서 페이지는 모든 FXS를 다시 사들인 FXS1559 사양을 설명합니다. 현재 메커니즘은 해당 금액의 FXS를 veFXS 수익률 컨트렉트로 보냅니다.** FXS1559는 시스템에 담보 비율 초과하는 자본의 양을 계산하여 이 과잉 값을 사용하여 FXS를 구입하고 연소 시킵니다. 모든 AMO 제안에는 담보 비율(CR)에 대한 누적 가치를 계산하는 FXS1559 함수가 포함되어야 합니다. 이 값은 FXS 연소할 때 사용됩니다. FXS1559는 특정 가스 가격/사용량 분석을 고려할 때 블록 생산 중에 ETH를 연소하는 이더리움 개선 제안인 EIP1559를 따라서 명명되었습니다. EIP1559는 ETH 네이티브 자산의 가치 제안을 완전히 변경하고 프로토콜 수준에서 가치 포착을 공식화했습니다. EIP1559는 프로토콜 수준에서 ETH의 경제적 가치를 단단히 묶습니다. 마찬가지로 FXS1559는 AMO 수준에서 실시간 FXS 값을 연결하여 결정하게 만듭니다. AMO는 모든 시장 운영 전략을 수행하기 위한 무한하고 튜링 완전\[1]한 설계 공간을 가지고 있기 때문에, FXS가 가능한 모든 AMO 설계에서 가치를 포착하는 방법을 공식화하는 것이 중요합니다. 특히, 시간 간격 t마다 FXS1559는 CR 위의 초과 값을 계산하고 값에 대한 담보 비율에 비례하여 FRAX를 민트합니다. 그런 다음 새로 민트된 통화를 사용하여 FRAX-FXSAMM 쌍에 FXS를 구입하고 연소합니다. 예: 프로토콜에서 86% CR에서 8600만 달러의 부가 가치를 지닌 100m FRAX가 유통되고 있습니다. 그 시스템은 FRAX의 1.00달러 거래와 균형을 이루고 있습니다. 담보물은 담보 투자자에게 AMO 및 Curve AMO와 같은 여러 AMO를 통해 배치됩니다. 프로토콜의 다양한 시장 운영은 수익률, 거래 수수료 및 이자를 통해 이루어집니다. 매일 다양한 AMO로부터 2만 달러 상당의 수익이 발생합니다. 이것은 담보 가치의 20,000달러의 잉여금이므로 CR이 매일 0.023%씩 증가할 것입니다. t = 24시간 후 CR은 86.023%임으로써 목표값인 86%보다 높습니다. CR이 86%인 경우 프로토콜은 두 가지 방법으로 CR에 균형을 맞출 수 있습니다. 20,000달러의 부수 이익을 AMM들로부터 FXS를 구입하는 데 사용할 수 있지만, 보다 효율적이고 유리한 방법은 20,000/(.86) = 23,255.814 FRAX를 주조하는 것입니다. 이후 새로 주조된 23,255.814 FRAX를 가져가고 가장 유동적인 온체인 시장(현재의 FRAX-FXS 유니스와프 쌍)에서 FXS를 구입합니다. 다음, FXS가 즉시 연소됩니다. 이 두 번째 방법은 FRAX 공급을 확장하고, FXS 토큰 홀더에 가치를 부여하며, CR 재조정으로 인해 프로토콜 전체를 벨런스할 수 있는 뚜렷한 이점을 가지고 있습니다. 이후 새로 주조된 23,255.814 FRAX를 가져가고 가장 유동적인 온체인 시장(현재의 FRAX-FXS 유니스와프 쌍)에서 FXS를 구입한다. 그런 다음 FXS가 즉시 연소됩니다. 이 두 번째 방법은 FRAX 공급을 확장하고, FXS 토큰 홀더에 가치를 부여하며, CR로 프로토콜을 재조정할 수 있는 뚜렷한 이점을 가지고 있습니다. 본질적으로, FXS1559는 모든 AMO가 현재 목표 담보 비율보다 초과 값을 나타내면 FXS의 가치를 쌓는 보유자들 위한 프로토콜 내 메커니즘입니다.
# 담보 투자자 (Collateral Investor) 유휴 담보를 다양한 DeFi 볼트/프로토콜에 투자하기 담보 투자자의 AMO는 유휴 USDC 담보를 이동하여 안정적인 수익률을 제공하는 DeFi 프로토콜을 선택합니다. 현재 통합된 프로토콜은 Aave, Compound, Yearn입니다. 하지만 거버넌스를 통해 더 많은 프로토콜을 추가할 수 있습니다. 이 AMO의 주요 임무는 대규모 FRAX 상환시 대기기간 없이 즉시 투자된 담보를 찾을 수 있도록 하는 것입니다. 즉각적인 인출 능력이 투자된 담보물을 프로토콜에 항상 자발적으로 이용할 수 있게 하므로 프로토콜의 CR을 낮추는 것으로 간주하지 않습니다. 그럼에도 불구하고, 규격의 담보 해제 기능은 시간 지연된 인출부터 투자된 담보물을 철회합니다. 프로토콜이 CR을 초과하게 하는 투자 수익은 어차피 FXS1559로 연소됩니다. \ **AMO 활용 분야** 1\. 무담보화 - 다양한 수익률 생성하는 프로토콜에 유휴 담보물을 배치합니다. 즉시 인출할 수 없는 투자는 계산된 CR 값을 낮춥니다. Yearn USDC v2 및 Compound와 같이 항상 1 대 1의 비율로 인출할 수 있는 투자는 CR를 낮추는 것으로 간주하지 않습니다. 2\. 시장 운영 - CR에 대한 투자를 복합화합니다. 3\. 담보물 환수 - 금고의 투자를 회수하여 상환을 위한 담보물을 확보합니다. 4\. FXS1559 - CR에 대한 투자로 발생하는 일일 수익을 창출합니다. \
# 커브 (Curve) 프로토콜에 의해 주로 제어되고 소유되는 유동성을 갖춘 안정적인 스왑 풀 커브 AMO는 FRAX와 USDC 담보를 사용해 프로토콜의 유동성을 높히며 페그를 조입니다. Frax는 자신만의 FRAX3CRV 메타풀을 구축했습니다. 즉, Frax 배포자 주소가 자체 커브 풀에 대한 관리자 권한을 소유합니다. 이를 통해 커브 AMO 컨트롤러는 FXS 홀더와 다양한 미래 기능에 대한 관리 수수료를 설정하고 징수할 수 있습니다. 이 프로토콜은 유휴 USDC 담보물 또는 새로운 FRAX를 자체 커브 풀로 이동하여 훨씬 더 많은 유동성을 창출하고 페그를 조이면서 거래 수익을 올릴 수 있습니다. **AMO 활용 분야** 1\. 담보 해제 - 유휴 담보물과 새로 주조된 FRAX를 FRAX3CRV 풀에 배치합니다. 2\. 시장 운영 - 거래 수수료, CRV 보상을 획득하고 주기적으로 풀의 균형을 재조정합니다. FRAX3CRV LP 토큰은 추가 수율을 위해 Yearn crvFRAX 볼트(vault), Stake DAO 및 Convex finance에 입금됩니다. 3\. 재담보화 - 초과된 FRAX를 풀에서 먼저 인출한 후 USDC를 회수하여 CR를 증가시킵니다. 4\. FXS1559 - CR에 대해 발생한 일일 거래 수수료 및 LP 가치(현재 개발 중) ![](/files/-MXlBvpx9J_DbZMer2NU) 커브의 스태블스왑 불변량(invariant)은 비축량이 극도로 불균형하지 않을 때 스테이블코인 스왑 간의 가격 변동성을 감소시키고, 그럴 때 선형 스왑 곡선을 근사하게 만듭니다. ![N 코인에 대한 일반화 선형 스왑 곡선](/files/-MWWwLwnlO4C_nvU8Ges) 불균형이 심한 경우 불변량은 Uniswap 상수 곱 곡선에 접근한다. ![N 코인에 대한 일반화 상수-곱 스왑 곡선](/files/-MWWwODZ3ZC9_0O6oety) \ 이러한 두 곡선의 조합은 계수에 따라 풀의 균형 비율에 따라 하나 또는 다른 곡선을 표현할 수 있게 합니다. 무 차원 매개 변수 (insert)을 계수로 사용하면 두 곡선의 조합을 N 코인으로 일반화할 수 있습니다. ![완벽한 수식](/files/-MWWwb84FHwdPmjHYla7) \\ ## **커브** **AMO** 이 프로토콜은 FRAX 가격이 CR로 떨어질 경우 인출할 수 있는 USDC의 잔액을 찾아 AMO가 사용할 수 있는 기본 담보의 양을 계산합니다. FRAX는 항상 CR의 가치로 담보에 의해 뒷받침되기 때문에 담보 자체의 가치 아래로 내려가서는 안 됩니다. 예를 들어, FRAX는 85% CR에서 $.85 이하로 내려가지 않아야 합니다. 이 계산은 곡선 AMO가 접근할 수 있는 담보의 양을 계산하는 가장 안전하고 보수적인 방법입니다. 이를 통해 커브 AMO는 USDC 담보를 포함하여 풀 내부에 배치할 FRAX를 민팅할 수 있으며, FRAX가 페그를 없앨 경우 얼마나 많은 담보를 이용할 수 있는지 정확히 알 수 있습니다. 또한, AMO의 전반적인 전략은 최소 FRAX 공급량을 최적화하여 모든 Y를 Z TVL과 A 증폭 계수가 있는 곡선 풀로 한 번에 판매하면 X% 미만으로 FRAX 가격에 영향을 미치는데, 여기서 X는 CR의 대역 민감도입니다. 다른 말로 하면, Curve AMO는 FRAX+USDC를 자체 Curve 풀에 넣고 TVL을 제어할 수 있습니다. CR은 FRAX 가격이 1달러 이하로 1센트 이상 하락할 때 환매하기 때문에 FRAX 가격이 1% 하락하기 전에 커브 풀로 직접 팔 수 있는 FRAX의 가치가 있다는 것을 의미합니다. 이 프로토콜은 적어도 그 양의 알고리즘 FRAX가 공개 시장에 유통되도록 할 수 있습니다. 왜냐하면, 그 전체 금액을 커브 풀의 TVL로 한 번에 판매해도 CR이 이동하도록 충분히 가격에 영향을 미치지 않기 때문입니다. 커브의 스테이블 코인 최적화 곡선을 고려할 때 이 금액은 상당히 크고 인상적입니다. 예를 들어, 330m TVL FRAX3Pool(기본 3Pool의 균형을 유지한다고 가정)은 가격을 1센트 이상 이동하지 않고도 최소 3920만 달러 이상의 FRAX 판매 주문을 지원할 수 있습니다. CR 대역이 1%인 경우 프로토콜은 최소한 오픈 마켓에서 최소 39.2m의 알고리즘 FRAX를 가져야 합니다. 위의 전략은 페그를 깨뜨릴 위험 없이 순환할 수 있는 알고리즘 FRAX의 바닥을 수학적으로 만들 수 있는 매우 강력한 시장 운영입니다. 또한 Curve는 유동성 공급자를 위한 보상으로 CRV 토큰을 할당하여 풀(게이지 보상이라고 함)을 선택합니다. Frax 프로토콜은 FRAX3CRV 풀의 최대 유동성 공급자가 될 가능성이 크기 때문에 모든 FRAX3CRV LP 토큰을 커브 게이지에 할당하여 상당한 이익을 얻을 수 있습니다. 커브 AMO 내에서 보유하고 있는 CRV 토큰은 향후 FXS 보유자에 의해 제어되는 커브 DAO 거버넌스에 투표하는 데 사용될 수 있습니다. 이것은 본질에서 프로토콜이 자체의 커브 풀에 더 많은 유동성을 사용할수록, 더 많은 커브 프로토콜을 소유하고 획득된 CRV 보상을 통해 통제하게 된다는 것을 의미합니다. 커브 AMO의 장기적인 효과는 Frax가 커브 자체의 큰 지배구조 참여자가 될 수 있다는 것입니다. 커브 AMO 계약은 다음 위치에서 전개됩니다: `0xbd061885260F176e05699fED9C5a4604fc7F2BDC` # 유니스왑 v3 유휴 담보를 유니스왑 최적의 안정적 짝으로 배치시키기 LP가 특정 가격 범위 사이에 유동성을 배치할 수 있는 유니스왑 v3의 AMM 알고리즘의 핵심 은 FRAX와 USDC쌍과 같이 스테이블 코인 쌍이 페그 내에서 유동성을 첨가할 수 있게 하는 것입니다. Uniswap v2와 비교했을 때 Uniswap v3의 범위 주문은 무한한 가격 범위로 퍼지는 대신 유동성을 집중시키는 것이다.
유니스왑 v3 유동성 AMO는 FRAX와 다른 스테이블 코인 쌍에 유동성을 첨가시킵니다. AMO는 유니스왑의 어디든 사용하며 FRAX를 민팅하는데 사용될 수 있기에, 다른 스테이블 코인을 확장시키고 유니스왑 3의 담보를 태울 수 있다. 또한, AMO 이익을 초과 담보의 시장 운영에 할당하기 위해 `collectFees()` 함수를 주기적으로 사용할 수 있다. **AMO 활용 분야** 1\. 비담보화 - 유휴 담보물과 새로 주조된 FRAX를 Univer3 쌍에 예치합니다. 2\. 시장 운영 - Univer3 거래 수수료 및 담보 유형 간 스왑을 획득합니다. 3\. 재상호화 - Univercalize 3 쌍에서 철수하고 FRAX를 태운 다음 USDC를 반환하여 CR를 증가시킵니다. 4\. FXS1559 - CR에서 발생한 일일 거래 수수료 **파생상품**
모든 가격은 여러 개체 사이에 비율로 존재합니다. 일반적으로, 우리는 일상 상품과 서비스의 가격을 비교하기 위해 분모(예: USD)에서 통화를 공유 계정 단위로 선택합니다. 유니스왑에서 가격은 풀의 Y에 대한 X의 매장량 비율로 정의됩니다. 유니스왑 v3의 범위 내 메카닉은 예약금을 특정 가격(Tick)으로 "가상화"하여 기존 x\*y=k CPM(Constant-Product Market Making Invariant)에 적합합니다. 유동성 위치가 어떤 가격에 의해 제한되는지를 지정함으로써, 특정 자산에 대해 전체 범위에 유동성을 분산시킬 필요 없이 상수 생성물 불변량을 따르는 범위 순서가 생성됩니다. 유니스왑 v3의 가격은 특정 가격 값 "I"에 대한 값 1.0001로 정의됩니다. 가격에 대한 경계는 대부분 G = {g^iI i∈ Z,g=1.0001}으로 나타낼 수 있습니다. 이 메커니즘은 정수를 가격 경계로 쉽게 변환할 수 있으며, 각 눈금 가격 경계를 다른 값에서 하나의 기준점(0.01%)으로 이산화할 수 있는 편리함을 가지고 있습니다.
가상 준비금은 각 위치의 유동성과 틱 경계를 추적하여 추적됩니다. 틱 경계를 넘어서면 해당 틱에 사용할 수 있는 유동성은 각각의 가격 범위에 들어가고 나오는 위치를 반영하여 변경될 수 있다. 틱 경계 내에서 스왑은 가상 예약에 따라 가격 √P를 변경한다. 가상 매장량 x와 y는 유동성과 가격에서 계산할 수 있습니다.
실제 구현에서는 값의 제곱근을 사용하는데, 이는 제곱근 연산이 틱 내 스왑 계산에서 절약되기 때문에 반올림 오류를 방지하는 데 도움이 되기 때문이다.
유동성은 'x \* y = k' CPM에서 가상의 'k'로 생각할 수 있으며, dY는 자산 Y의 양에 해당하며 P는 눈금 내 가격 하락을 나타낸다.
L은 인트라-틱 스왑에 고정되므로 dX와 dY는 가격의 유동성과 제곱근에서 계산할 수 있다. 체크 표시를 넘어갈 때 스왑은 P 경계까지만 미끄러져야 하며 다음 체크 표시에 사용할 수 있는 유동성을 다시 조정해야 합니다. **유동성AMO** Uniswap v3 유동성 AMO(안정적) 계약은 0x3814307b86b54b1d8e7B2Ac34662De9125F8f4E6에서 배포됩니다.
# FRAX Lending FRAX를 DeFi 플랫폼에 대여하여 APY 수익 창출 이 컨트롤러는 FRAX를 Compound나 CREAM 과 같은 머니마켓에 발행하여 누구나 기본 발행 메커니즘 대신 이자를 지불하여 FRAX를 빌릴 수 있도록 합니다. 머니마켓에 투입되는 FRAX는 머니마켓을 통해 차입자가 과다 담보화하지 않으면 유통에 들어가지 않기 때문에 이 AMO는 직접담보비율(CR)을 낮추지는 않습니다. 대신 이 컨트롤러는 프로토콜이 FRAX를 직접 빌려주고 기존 금융시장을 통해 대출자의 이자를 받을 수 있도록 합니다. 사실상, 이 AMO는 MakerDAO의 단일 시장 운영 계약에서 전체 프로토콜입니다. 대출로 인한 현금 흐름은 FXS를 다시 사서 태우는 데 사용될 수 있습니다(MakerDao가 안정성 수수료에서 MKR을 태우는 방식과 유사하다). 본질적으로 대출 AMO는 FRAX가 화폐 시장에 의해 설정된 이자율을 지불함으로써 유통될 수 있는 새로운 길을 만듭니다. **AMO 활용 방안** 1\. 탈담보화 - FRAX를 금융시장에 투입한다. 빌린 모든 FRAX가 초과담보화되기 때문에 CR는 직접 발행된 FRAX의 양만큼 낮아지지 않는다. 2\. 시장 운영 - 대출자로부터 이자 수익을 창출합니다. 3\. 재담보화 - 화폐 시장에서 발행된 FRAX를 회수합니다. 4\. FXS1559 - CR에서 발생한 일일 이자 지급액(현재 개발 중) **금리 및 자본효율성 조정** AMO는 FRAX를 더 발행하거나 FRAX를 제거하고 태움으로써 FRAX를 빌리는 이자율을 높이거나 낮출 수 있습니다. 이것은 모든 대출 기관들의 FRAX 차입 비용을 변화시키기 때문에 강력한 경제적 지렛대입니다. AMO는 특정 비율을 목표로 FRAX를 민팅 및 제거할 수 있기 때문에 이는 모든 시장에 침투합니다. 이는 또한 프로토콜이 어느 방향을 목표로 하느냐에 따라 FRAX 단락 비용이 더 비싸거나 덜 비싸게 만듭니다. 또한 프로토콜의 분수 알고리즘 설계는 다른 안정 동전과 비교하여 일치하지 않는 차입 비율을 허용합니다. 프로토콜은 시장이 FRAX를 9.99달러로 가격을 매기고 프로토콜을 재담보화해 반응할 때까지 FRAX 안정코인을 마음대로 민팅할 수 있기 때문에 다른 프로토콜에 비해 화폐창출비용이 미미하다는 뜻입니다. 이것은 프로토콜이 다른 모든 안정적인 코인 이율을 능가하기로 결정할 경우 동급 최고의 대출 이율을 생성합니다. 따라서 AMO 전략은 언제 금리를 낮출 것인지(그리고 다른 안정적인 코인 환율로 가져올 것인지)에 대한 조건을 최적화하고 반대 조건에서도 금리를 올릴 수 있습니다. 아이러니하게도 자체 토큰의 대출금리는 다른 스테이블코인 프로젝트들이 통제하기 어려운 부분이다. 프락스는 이 AMO를 통해 이 자산을 완전히 통제합니다. # 분산 비율(Decentralized Ratio -DR) 중앙 통제 자산에 대한 의존 감소 Frax의 분산 비율(DR)은 자산에 대해 담보/청산할 수 있는 전체 안정적 코인 공급 대비 분산된 담보 가치의 비율입니다. 과도한 오프 체인 위험을 가진 담보물(즉, 명시코인(fiatcoin), 증권 및 금/석유 등과 같은 보관 자산)은 0% 분산된 것으로 계산됩니다. DR은 시스템 계약 내부에 있는 것뿐만 아니라 프로토콜이 주장하는 기본적인 구성 요소인 담보를 거칩니다. DR은 모든 자산의 기본 값을 찾는 재귀 함수입니다. 예를 들어, FRAX3CRV LP는 50% FRAX이므로 자신의 코인으로 자신을 지지할 수 없기 때문에 이 부분은 제외합니다. 나머지 절반은 USDC 33%, USDT 33%, DAI 33%인 3CRV입니다. DAI 자체는 약 60%의 피아트코인입니다. 따라서 FRAX3CRV LP의 각 $1은 분산된 소스에서 나오는 약 $066(1 x 0.5 \* 0.33 \* 0.4)의 가치만 가집니다. 반대로, CVX, CRV와 같은 보상 토큰뿐만 아니라 이더리움은 100% 분산된 것으로 계산된다. 대출 AMO를 통해 발행된 FRAX는 또한 대출자들이 암호화폐 OHM, RGT 등을 통해 대출을 과도하게 담보로 하기 때문에 분산된 것으로 간주됩니다. 이는 DAI의 볼트가 높은 DR을 제공하는 이유와 동일합니다. DR은 모든 스테이블 코인의 과도한 오프 체인 위험을 계산하는 데 사용할 수 있는 일반화된 알고리즘이다. LUSD와 같은 다른 안정 동전은 계산하기가 훨씬 쉽습니다: DR은 100%입니다. FEI는 약 90%의 DR입니다. 2021년 11월 2일 기준으로 FRAX는 약 40%이다. 매일 추적되며 볼 수 있습니다. # veFXS 락업된 FXS 코인은 여러분에게 여러 가지 이득을 가져다 줄 수 있습니다. ## 배경 veFXS는 Curve Finance 코인 거래소의 veCRV 메커니즘에 기반을 한 락업 코인 시스템입니다. Frax 코인의 고객들은 최대 4년 동안 자신이 보유한 FXS 토큰을 락업해여 4배의 veFXS 토큰을 받을 수 있습니다. (예를 들어 4년 동안 락업된 100 FXS은 400 veFXS으로 반환됩니다). veFXS는 교환이 불가능하며 유동성 시장에서 거래할 수 없습니다. 이 토큰은 개인의 지갑 내에 FXS 토큰의 락업한 기간을 나타내는 포인트 시스템에 가깝습니다. 토큰이 락업 만기에 가까워질수록 veFXS의 교환 벨런스는 선형적으로 감소하며, 락업 만료 되었을 때 1 veFXS당 1 FXS에 교환 될 수 있습니다. 이런 시스템은 장기적인 스테이킹과 활발한 커뮤니티를 장려합니다. Sushiswap거래소에서 최근 발표한 oSushi 토큰의 락업 샘플 그래프(Curve의 veCRV 메커니즘에 기반한)에서도 이와 비슷한 감소의 양상을 볼 수 있습니다. **veFXS 거버넌스의 화이트리스팅.** 스마트 계약 및 DAO는 vFXS에 대한 지분을 보유하기 위해 거버넌스별 화이트리스트가 필요합니다. 외부 소유 계정과 일반 사용자 지갑만 veFXS 락업을 직접 사용할 수 있습니다. 프로토콜에 vFXS 기능을 구축하려면 화이트리스트 제안서를 제출하여 Govern.frax.finance의 FRAX 커뮤니티에서 거버넌스 프로세스를 시작하십시오. **투표권** 각 veFXS는 거버넌스 제안에서 1표를 갖게 됩니다. 최대 시간인 4년 동안 1 FXS를 걸면 4 vFXS가 생성됩니다. 이 vFXS 잔액 자체는 4년 후에 1 vFXS로 서서히 감소하며, 이때 사용자는 FXS를 위해 vFXS를 다시 사용할 수 있습니다. 한편, 사용자는 FXS를 잠그거나, 잠금 종료 날짜를 연장하거나, 둘 다 함으로써 vFXS 밸런스를 높일 수 있습니다. vFXS는 전송이 불가능하며 각 계정은 하나의 잠금 기간만 가질 수 있으며, 이는 단일 주소가 특정 FXS 토큰을 2년 동안 잠글 수 없고 다른 FXS 토큰 세트도 3년 동안 잠글 수 없다는 것을 의미한다. 계정당 모든 FXS는 잠금 시간이 균일해야 합니다. **게이지 파밍 장려** veFXS를 보유하면 특정 토큰에 대한 파밍 보상을 수집할 때 사용자에게 더 많은 가중치를 부여할 것입니다. 프로토콜을 통해 직접 분배되는 모든 파밍 보상은 veFXS 승급 자격이 있다. 다른 프로토콜(예: Sushi Onsen)에 의해 촉진되는 외부 파밍은 일반적으로 프락스 프로토콜 자체와 독립적이기 때문에 veFXS 부스트에 사용할 수 없습니다. 사용자의 veFXS 부스트는 보상의 전반적인 배출량을 증가시키지 않습니다. 이러한 상승은 각 농가의 수확량에 그들의 veFXS 균형에 비례하여 추가될 추가적 상승이 될 것입다. veFXS 부스트는 파트너십 계약과 거버넌스 투표에 기초한 커뮤니티와 팀의 재량에 따라 LP 쌍마다 다를 수 있습니다. 농사 부스트는 LP의 1 FRAX 당 veFXS 비율로 주어집니다. 예를 들어 FRAX 1개당 10개의 veFXS의 2배 부스트 비율을 갖는 FRAX-IQ 쌍은 50,000개의 veFXS를 가진 사용자가 10,000달러의 LP 포지션에 대해 2배의 부스트를 받는다는 것을 의미합니다. 현재 FRAX당 veFXS 요구 사항은 4 veFXS \~ 1 FRAX입니다. **veFXS 수익률** veFXS의 사용 후, 보유자들은 주기적으로 보상을 수집할 수 있습니다. 그 양은 FXS의 수익률 및 시장 가격에 따라 달라질 수 있습니다. 현재, veFXS 보유에 대한 FXS 보상은 담보 비율 이상의 프로토콜의 AMO 이익에서 나옵니다. 수익금의 50%는 FXS를 다시 사서 개인키가 없는 암호화폐 지갑 주소로 암호화폐를 전송하여 다시는 사용할 수 없도록 만드는 코인 소각을 해버리는데 쓰이고, 나머지 50%는 VEFXS 보유자에게 분배하기 위해 쓰입니다. **veFXS의 미래 활용** veFXS 시스템은 모듈식이며 다목적입니다. 향후 AMO 가중치에 대한 투표로 확대되어 새로운 장소/특징에서 추가 수익률을 얻고 일종의 지배구조 토큰 채권 금리로 취급될 수 있다. 이는 프락스 전체에 다음과 같은 **이점**을 제공합니다: * veFXS를 통해 FXS 토큰 장기 보유자에게 투표권 할당을 하는 것 * 파밍하는 사람들에게 FXS를 스테이킹 하도록 장려하기 * DAO 및 기타 프로젝트가 크고 장기적인 veFXS 포지을를 구축하고 Frax 거버넌스에 참여할 수 있도록 합니다. * FXS에 대한 채권형 유틸리티 및 스테이킹된 FXS에 대한 벤치마크 APR 비율 생성 * [스테이킹 가이드](https://fraxfinancecommunity.medium.com/guide-how-to-stake-your-fxs-and-earn-vefxs-yield-dc684ffdd1ed) # 게이지 게이지FXS 토큰의 배출과 확대를 통제하기 위한 게이지 가중 시스템 Curve Finance 코인 거래소는 CRV 토큰 배출에 게이지 시스템을 도입했다. 사용자는 다양한 커브 유동성 풀의 "weights"에 투표하기 위해 veCRV를 락업합니다. FRAX는 다양한 프로토콜에 걸쳐 모든 FRAX 쌍에 대해 유사한 시스템을 도입하고 있다 FRAX 게이지 시스템은 FXS 보유자가 최대 4년간 스테이킹하여 veFXS를 생성하고 향후 FXS 배출 방향을 결정할 수 있도록 합니다. 사용자는 veFXS 밸런스로 FRAX 게이지 가중치에 투표할 수 있습니다. 그들은 투표권을 여러 게이지 또는 단일 게이지에 분산시킬 수 있다. 이를 통해 프로토콜의 가장 장기적인 사용자인 veFXS 보유자들이 향후 FXS 배출을 완전히 제어할 수 있도록 합니다. 또한, 게이지 시스템은 대부분의 보상이 판매되는 FRAX 쌍의 영향력을 낮추는 자정 작용을 하는데 이는 유동성 공급자들(LPs), 즉 FXS 보유자는 그들의 쌍에 대한 투표를 계속하기 위해 veFXS를 보유하지 않기 때문입니다. 이 시스템은 veFXS에 지속적으로 스테이킹하여 풀의 게이지 가중을 높이는 FXS 보유자에게 도움이 됩니다. 기본적으로 FRAX 게이지는 전체 커뮤니티 FXS 할당이 분배될 때까지 가장 장기 지향적인 FXS 보유자가 FXS 배출이 어디로 가는지 제어하도록 veFXS 보유자의 인센티브를 조정합니다. **게이지 가중은 매주 수요일 오후 5시(PST)에 한 번씩 업데이트됩니다. 즉, 각 쌍의 FXS 배출률은 1주일간 일정하게 유지된 후 매주 수요일에 새 배출량으로 업데이트됩니다. 모든 사용자는 10일마다 가중치 할당을 변경할 수 있습니다.** 모든 FXS가 배포된 후, FXS 보유자에 대한 보상으로 게이지 시스템은 FRAX 스테이블 코인의 확장을 제어하는 것으로 전환될 것입니다. FXS에서 FRAX 리워드로의 이러한 전환은 FXS 배출이 거의 완료되기 전까지 몇 년 동안 일어나지 않을 것이며, 안정적인 코인이 먼저 신뢰와 성공에 대한 자신감, 퇴색되지 않은 가치(린디효과)를 쌓을 수 있도록 할 것입니다. 또한, veFXS 보유자들은 게이지 프로그램이 일시적이지 않으며 FXS 보상이 종료될 때 폐지되지 않을 것임을 알고 최대 4년의 기간을 스테이킹할 수 있는 신뢰을 가질 수 있습니다. 게이지 가중치는 보상으로 FRAX 스테이블 코인을 영구적으로 분배하는 것으로 전환될 것이다.
**현재 게이지 유형** **LP 게이지:** LP 게이지는 ERC20 LP 토큰을 예치금으로 받는 가장 일반적인 유형의 게이지 계약입니다. 대부분의 게이지는 Fraxswap, Curve, Uniswap v2 등의 LP 위치에 인센티브를 제공합니다. 일반적으로 이러한 게이지는 LP 위치에서 1FRAX당 4개의 veFXS의 2배 veFXS 부스트와 추가 1년 2배 타임록 부스트를 제공합니다(달리 지정되지 않는 한). \ \ **Lending 게이지:** Lending 게이지는 일반적으로 Aave, Fraxlend, Compound 등과 같은 자금 시장에서 FRAX 대출 활동을 장려하기 위해 배포됩니다. 예금 토큰은 aFRAX, fFRAX, cFRAX 등입니다. Lending 게이지는 일반적으로 타임록 부스트를 제공하지 않지만 4개의 veFXS당 빌려준 1개의 FRAX에 대해 2배의 veFXS 부스트 제공.\ \ **Uniswap V3 게이지:** Uniswap v3 게이지는 NFT LP 포지션을 예치금으로 사용합니다. 이 게이지는 출시 시 특정 틱 범위에서 NFT LP를 허용하도록 사전 구성되어 거버넌스가 쌍에 대해 승인한 정확한 집중 유동성 위치에만 인센티브를 제공합니다. 이 게이지는 LP 위치에서 1FRAX당 4개의 veFXS의 2배 veFXS 부스트와 1-3년 잠금에 대해 2x-3x의 추가 타임록 부스트를 제공합니다(해당 스테이킹 페이지의 각 게이지에 대해 지정됨). \ \ **Vault 게이지:** Vauult 게이지는 Stake DAO 또는 Yearn Finance Vault 토큰과 같은 보증금으로 Vault 전략 토큰을 사용합니다. Vault 게이지는 일반적으로 Vault 위치에서 1FRAX당 4개의 veFXS의 2배 veFXS 부스트와 1-3년 동안 2-3배의 타임록 부스트를 제공합니다(각 게이지에 지정됨).
**veFXS과 락업된 유동성 풀의 상승** 게이지 가중치에 유동성 풀(LP) 토큰을 스테이킹하는 사용자는 보유한 veFXS의 양에 따라 APR(단리: 원금에 대한 이자)에의 추가 상승 효과를 얻습니다. 또한, 특정 기간 동안 스테이킹 계약 내에서 유동성 풀 토큰을 락업하는 사용자는 추가 상승을 얻으므로 두 상승을 모두 얻어 최대 APR을 획득할 수 있다. 게이지 가중치는 매주 변경되므로 한 게이지에 락업된 LP는 게이지 중량이 변경되어도 LP의 잠금이 해제되지 않습니다. 부스트 계산 방법에 대한 설명은 [veFXS 스펙 페이지](https://docs.frax.finance/vefxs/vefxs)를 참조하십시오 **게이지에 구애 받지 않는 페어** FRAX 게이지는 veFXS를 스테이킹하는 보유자가 FXS 배출을 투표(pool)를 통해 직접 제어할 수 있도록 합니다. FRAX 스테이블 코인을 사용하고 게이지 거버넌스 투표를 통과시키는 것 외에는 어떤 프로토콜 또는 쌍이 게이지 가중을 가질 수 있는지에 대한 한계는 없습니다. 현재는 Uniswap V3 스테이블 코인의 게이지가 데뷔 게이지(나 Curve Finace의 FRAX3CRV pool)가 될 것이지만, 향후에는 모든 FRAX 풀(크로스 체인 풀 포함)을 게이지로 추가될 수 있을 겁니다. veFXS 게이지 시스템은 전략 내에서 FRAX 스테이블 코인이 사용되는 한 게이지 내의 예금 토큰과는 완전히 무관합니다. 기본적으로, veFXS 게이지는 DeFi의 화폐층 게이지 가중치이며, 다른 게이지(커브 게이지 가중치 등)는 DEX 레이어 가중치입니다(향후에는 Curve Finace가 범위를 넓힐 수 있음). veFXS 스테이킹 보유자들은 FRAX를 통합하는 모든 프로토콜로 배출을 제어할 수 있기 때문에, 많은 프로토콜과 커뮤니티는 알고리즘 스테이블 코인 프로토콜의 미래 현금 흐름을 제어하기 위해 경쟁할 수 있을 겁니다 모든 스마트 계약(비 EOA 지갑)이 FXS에 투자하려면 거버넌스 투표에 의해 화이트리스트가 되어야 합니다. AMO 수익 및 파밍 증대와 같은 veFXS 보유의 전체 혜택 목록은 [veFXS 전체 사양](https://docs.frax.finance/vefxs/vefxs)을 참조하십시오.
# 브릿지 메커니즘 여러 네트워크에서 호환 가능한 멀티체인 FRAX+FXS Frax 프로토콜은 모든 네트워크에서 일관된 글로벌 상태를 갖는 다중 체인 프로토콜입니다. FRAX+FXS 토큰은 모든 네트워크에 걸쳐 단일 코인입니다. 각 체인에 대한 독립적인 Frax 구현은 없습니다. 이러한 이유로, 프로토콜은 독특하고 새로운 방식으로 엄격한 추종 자산와 교환성을 유지할 수 있는 브릿지 시스템을 가지고 있습니다. 프로토콜은 각각의 개별 브릿지의 FRAX/FXS를 해당 브릿지 시스템의 고유한 코인\[1]으로 취급하며, 다른 체인에서 이동된 FRAX/FXS의 이름을 해당 브리지의 식별자로 변환시킵니다. 예를 들어 AnySwap 코인에 브릿지된 FRAX를 anyFrax라고 변환시키고, Wormhole 브릿지로 연결된 FRAX를 wormFRAX라고 부릅니다. 각 체인은 하나의 표준 FRAX와 표준 FXS 계약을 가지고 있으며, 이를 단순히 "FRAX"와 "FXS"(prexis 값이 없는)라고 부릅니다. 이러한 토큰은 AMO가 확장/수축하고 사용자 자신이 신뢰할 수 없는 토큰을 주조/환불할 수 있는 것입니다. **Canonical (원래의) FRAX/FXS**: 프로토콜 및 AMO에 의해 기본적으로 발행/분광/재구현되는 고유한 프로토콜의 코인입니다. 표준 FRAX는 특정 네트워크의 기본 색상과 네트워크의 로고가 중앙에 있습니다. 고유 FXS는 체인의 네이티브 색상과 로고가 오른쪽 아래에 있습니다. 따라서 모든 표준/고유 FRAX/FXS는 항상 코인의 어딘가에 네트워크 로고를 표시합니다. **브릿지된 FRAX/FXS**: 지원되는 브릿지 프로토콜을 사용하여 다른 네트워크에서 현재 체인으로 가져오는 토큰. 브릿지 토큰에 대한 명명 규칙은 현재 네트워크에 토큰을 가져오는 데 사용되는 브리지의 접두사 지정을 유지합니다. (예: ETH에서 AVAX로 전환된 Anyswap 브리지 FRAX를 anyFrax라고 합니다. AVAX의 FRAX는 단순히 ETH의 표준 FRAX이다. 브리지 프로토콜의 색상과 로고는 FRAX/FXS 토큰에 두드러지게 표시되어 현재 네트워크 내에서 어떤 브리지에서 유래했는지 명확하게 구분할 수 있습니다.) **체인 간 Frax/FXS 토큰 교환과 추종자산의 차익 거래** 각 표준 FRAX/FXS ERC20 토큰 계약에는 지원되는 각 브릿지의 FRAX/FXS에 대한 표준 FRAX/FXS와의 안정적인 1대 1 교환을 가능하게 하는 AMM이 토큰에 내장되어 있습니다. 이것은 FRAX 추종 자산의 엄격한 재정 거래를 가능하게 하고 또한 모든 체인에 걸쳐 FXS의 단일 분포를 유지하게 합니다. 예를 들어, Fantom의 표준 FRAX가 $.990이라고 가정해보자. 차익 거래를 하려는 주체는 ERC20 계약 내의 안정적인 교환 풀에 있는 AnyFRAX와 1 대 1로 교환할 수 있으며, FRAX를 다시 ETH 메인넷(또는 다른 체인)에 연결하여 수익을 낼 수 있다는 것을 알고 가능한 한 많은 표준 FRAX를 $990에 구입할 수 있습니다. 따라서 한 체인에 표준 FRAX/FXS를 구입하는 것은 다른 체인에 FRAX/FXS를 구입하는 것과 별반 다를 것이 없습니다. 지원되는 브리지 중 하나를 사용하여 FRAX/FXS를 브릿지하는 경우(조만간 브릿지될 곳들이 늘어날 예정입니다.) 해당 체인의 고유의 FRAX/FXS에 브리지된 토큰을 팜/LP/홀드 등으로 교환할 수 있습니다. 또한, 표준 FRAX/FXS가 어떤 체인의 AMO와 함께 주조될 때, 프로토콜은 추종 자산가 항상 글로벌하고 재정될 수 있도록 토큰 계약을 통해 사용할 수 있는 충분한 교환 유동성이 있는지 확인합니다. 교환은 언제든지 () 에서 수행되거나 어떤 체인에서든 고유 토큰의 스마트 계약과 직접 상호 작용할 수 있습니다. 교환 메커니즘은 모든 체인의 기본 ERC20 FRAX/FXS 토큰에 내장되어 있습니다(Ethereum L1 제외).
### Canonical 토큰 주소 **FRAX**: **FXS**: # CPI(소비자 물가지수) 추종자산과 인플레이션을 막기 위한 헷지(방비) Frax의 가격 지수는 Frax 내의 새롭고 독특한 프로토콜입니다. 고유의 스테이블코인(FPI)과 거버넌스 토큰(FPIS)을 중심으로 한 이 시스템은 CPI와 연결된 오라클에 따라 매월 조정돼 FPI 보유자들이 CPI 상승에 따라 달러 표시 가치가 상승하도록 할 예정입니다. 이는 사용자가 FPI를 FRAX로 조폐하거나 상환함으로써 만들어진 기본 FPI 재무에서 수익률을 얻음으로써 이루어집니다. Frax 물가 지수 쉐어(FPIS) 토큰은 시스템의 거버넌스 토큰으로 프로토콜로부터 분리할 수 있는 자격이 있습니다. 초과 수익률은 FXS 구조와 유사하게 금고에서 FPIS 토큰 보유자로 향할 것입니다. FPI 금고가 인플레이션으로 인해 FPI 당 늘어난 재원을 유지할 수 있을 만큼 충분한 수익률을 창출하지 못하는 기간 동안, 새로운 FPIS를 주조하고 판매하여 금고를 증가시킬 수 있을 겁니다. 프로토콜은 Frax 생태계 내에서 시작되므로, FPIS 토큰은 수익의 가변적인 부분을 FXS 토큰 보유자에게 전달할 것입니다 **인플레이션 계산** FPI는 미국 연방 정부가 보고한 CPI-U 미조정 12개월 인플레이션율을 사용합니다. () 이 링크에 완전히 연결된 오라클은 인플레이션율 공개 즉시 데이터를 프로토콜에 적용합니다. Frax 물가 지수 추종 자산은 위의 12개월 물가상승률을 추적하고 FPI 상환 계약으로부터 항상 FPI에 추정 적용한다. 따라서 거래자는 다른 자산(ETH 등)에 대한 Frax 물가 지수 안정 토큰을 구매할 때 CPI 구매력이 판매 ETH보다 시간이 지남에 따라 빠르게 증가하고 있다는 입장을 취하고 있습니다. ETH를 구매하기 위해 FPI를 팔면, 구매자는 ETH 성장이 미국 달러의 CPI 인플레이션율을 앞지르고 있다고 생각하게 된다.
**회계 단위로서의 FPI** FPI는 암호화 및 비암호화 상품 바구니에서 파생된 자체 계정 단위를 갖는 최초의 온체인 스테이블코인이 되는 것을 목표로 합니다. FPI는 인플레이션 저항 수익률 자산으로 간주될 수 있지만 주요 동기는 거래, 가치 및 부채를 표시하는 새로운 스테이블 코인을 만드는 것입니다. DAO 국고를 지정하고 FPI에서 수익을 측정하는 것은 물론 FPI 거래 쌍에 대한 벤치마킹 성과를 통해 실제 인플레이션에 대해 가치 발생이 적극적으로 증가하고 있는지 더 잘 측정할 수 있습니다. 또한 온체인 경제학을 실제 자산 바구니에 적용하는 데 도움이 됩니다. 처음에는 자금이 $FRAX로만 구성되지만 브리지된 BTC, ETH, 비암호화 소비재 및 서비스와 같은 다른 암호화 네이티브 자산을 포함하도록 확장될 것입니다. **FPI 안정성 메커니즘**\ \ FPI는 FRAX 스테이블 코인과 동일한 유형의 AMO를 사용하지만 항상 100% 담보 비율(CR)을 유지하도록 모델링됩니다. 이는 담보 비율이 100%로 유지되려면 프로토콜 대차대조표가 최소한 CPI 인플레이션 비율로 증가해야 함을 의미합니다. 따라서 AMO 전략 계약은 CPI에 비례하는 수익률을 얻어야 합니다. 그렇지 않으면 CR이 100% 미만으로 감소합니다. AMO 수율이 CPI 비율 미만인 시간 동안 TWAMM AMO는 CR을 항상 100%로 유지하기 위해 FRAX 스테이블 코인에 대한 FPIS 토큰을 판매합니다. CR이 100%로 돌아오면 FPIS TWAMM이 제거됩니다.
# Frax 물가 지수 쉐어(FPIS) Frax 물가 지수 쉐어(FPIS)는 Frax 물가 지수(FPI) 스테이블 코인의 거버넌스 토큰입니다. FPIS는 프락스 쉐어(FXS) 토큰에 상호 연결되어 있으므로 "링크된 거버넌스 토큰"이라고 합니다. FXS와 FPIS는 레이어 1 토큰이 네트워크의 dapp 토큰에 연결되는 것과 유사한 방식으로 경제적으로 연결되어 있습니다. FXS는 Frax 프로토콜의 기본 토큰이기 때문에 FXS는 어떤 일이 있어도 Frax와 FPI 스테이블 코인이 모두 성장함에 따라 항상 가치를 창출할 것입니다. FXS는 ETH 코인이 이더리움 접근에 가스를 지불하는 모든 디앱 활동의 총합에서 가치를 축적하는 방식과 유사하게 전체 Frax 성장에 비례하는 가치를 창출합니다.\[1] FPIS는 특정 ERC20(Ethereum Request for Comments 20) 토큰과 유사하게 FPI 증가를 추적하며 L1의 전체 경제 성장보다는 자체 프로토콜의 성장에 주목합니다. Frax 경제가 저평가되어 있다고 생각하신다면, FXS를 더 소유하셔야 합니다. 사람들이 FPI 성장을 과소평가하고 있다고 생각한다면 FPIS에 대한 노출을 늘려야 합니다. 이것은 이더리움의 특정 프로젝트에 투자할 것인지 아니면 ETH 전체에 투자할 것 인지와 정확히 같은 역학관계입니다. 이더리움이 전체적으로 저평가되어 있다고 생각하신다면, ETH를 더 구매하시면 됩니다. 하지만 특정 프로젝트가 Frax 경제 총량보다 빠르게 성장할 것이라고 생각한다면 L1 토큰이 아닌 특정 토큰을 소유하고자 할 것입니다.\* Frax Collateral Ratio(FCR: Frax 담보 비율)은 FPI 토큰을 직접 지원하는 토큰 중 Frax 스테이블 코인의 비율이다. FCR 값은 FPIS 및 veFPIS 토큰 보유자에게 분배되기 전에 미리 직접 계산됩니다. FCR은 특히 시스템의 FXS 값 계산에 사용됩니다. 초과 FPI 대차대조표 값이 FPIS 토큰 보유자에게 다시 분배될 때마다 'FRAX 담보 FPI 사용액'을 계산하는 'FCR 계약'이나 함수 호출을 거치게 된다. 본질적으로 인플레이션율 이상의 경제적 생산성은 FPIS 보유자에게 돌아갑니다. FPI는 소비재 바구니에 고정되어 있으므로 바구니 가치에 대한 청구를 나타냅니다. 해당 바스켓을 초과하여 프로토콜이 생성하는 가치는 FPIS 보유자가 포착합니다. **FPIS 토큰 분배 (100,000,000 FPIS 총 공급량)** FPI 페그를 CPI 비율로 유지하고 CR을 100%로 일정하게 유지하는 경우를 제외하고는 100m 제네시스 공급에 대해 FPIS 토큰을 발행할 수 없습니다. **35% Frax 금융 재무부 35,000,000** \ FXS 유권자는 거버넌스를 통해 이러한 토큰을 배포하는 방법에 대한 투표를 완전히 제어할 수 있습니다. 30% FPI 프로토콜 재무부 30,000,000 FPIS \ **유권자는 이러한 토큰을 배포하는 방법을 완전히 제어할 수 있습니다.** **25% 핵심 개발자 및 기여자 자금 25,000,000**\ 6개월 벼랑으로 에어드랍 제네시스와 동시에 2022년 2월 20일부터 시작하는 4년 백베스팅. 배포는 매월 20일경에 이루어집니다. 이 자금은 veFPIS가 출시될 때 월별 분배 사이의 4주 간격으로 veFPIS 시스템에 스테이킹됩니다. **10% 2022년 2월 FXS 보유자 에어드랍 10,000,000**\ 2022년 2월 20일 11:59:59 UTC 스냅샷 및 2022년 8월 20일 11:59:59 UTC까지 청구 가능 \*이 문서에서 가치 획득에 대한 논의는 투자 조언이 아닙니다. 거버넌스 토큰 메커니즘은 단지 프락스/FPI 시스템이 어떻게 작동하는지를 설명하기 위한 것입니다.
# 오라클 **개요** 오라클은 2021년 12월 블록 체인 기술 개발 스토어 Fiews에서 제공된 체인링크의 CPI-U 데이터 포인트를 페깅\[2] 가격 결정을 위한 '기준' 지수로 사용한다. 매달 지수의 변화/델타값\[3]을 전월의 데이터 포인트에 적용하여 페깅된 가격을 결정합니다. 오라클 계약에는 두 개의 초기 시간 데이터 점이 필요하기 때문에 2021년 12월이 선택되었다. 예: 2021년 12월 CPI-U : 280.126 2022년 1월 CPI-U: 281.933 Delta는 (281.933 / 280.196) - 1 = 0.64506686% 2021년 12월을 1달러라고 가정하면 델타 비율을 적용하면 다음과 같다. $1 x (1.0064506686) = $1.0064506686(페그 가격)입니다. 2022년 2월 CPI-U 데이터가 284.182라면, 델타(284.182 / 281.933) - 1 = 0.79770726%가 될 것이다. 이를 이전 페그 가격에 적용하면 $1.0064506686\*(1 + 0.0079770726) = $1.0144791987이 새 페그 가격으로 제공됩니다. 다시 말해, 2021년 12월 한 달러를 사려면 2022년 2월 한 달러가 많이 필요할 것입니다. Raw data source:[ https://data.bls.gov/timeseries/CUSR0000SA0](https://data.bls.gov/timeseries/CUSR0000SA0) Chainlink / Fiews Job: \ [**Code Link**](https://github.com/FraxFinance/frax-solidity/blob/master/src/hardhat/contracts/Oracle/CPITrackerOracle.sol) # FPI 컨트롤러 풀 **개요** FPI 컨트롤러 풀에는 FPI나 페깅을 다양하게 도와주는 기능을 합니다. **채굴 / 상환** 사용자는 FPI를 FRAX을 가지고 채굴하거나 FPI를 FRAX로 상환할 수 있습니다. 이와 관련된 작은 수수료가 있는데, 처음에는 0.30%이다. **twamToPeg** twamToPeg 기능은 프로토콜이 FPI의 시장 가격을 목표된 페깅 가격으로 올리거나 낮추기 위한 시장 압력을 주기 위해 사용된다. **giveFRAXToAMO / receiveFRAXFromAMO** 계약은 수익을 얻는 다양한 AMO\[2]에 FRAX 담보를 빌려줄 수 있다. [**Code Link**](https://github.com/FraxFinance/frax-solidity/blob/master/src/hardhat/contracts/FPI/FPIControllerPool.sol)
# veFPIS 업데이트된 모듈식 veFPIS veFPIS는 FPIS 거버넌스 토큰을 위한 업데이트된 베스팅+수익률 시스템입니다. veFXS와 마찬가지로 사용자는 veFPIS 양의 4배에 대해 최대 4년 동안 FPIS를 잠글 수 있습니다(예: 4년 동안 잠긴 100개의 FPIS는 400개의 veFPIS를 반환함). veFPIS는 양도 가능한 토큰이 아니며 유동 시장에서 거래되지 않습니다. 프로토콜 내에서 지갑의 잠긴 FXS 토큰의 베스팅 기간을 나타내는 계정 기반 포인트 시스템과 유사합니다. veFPIS 잔액은 토큰이 잠금 만료에 가까워짐에 따라 선형적으로 감소하여 남은 잠금 시간이 0일 때 1FPIS당 1veFPIS에 접근합니다. **이중 화이트리스트 및 모듈식 기능** veFPIS에는 스테이킹 시스템에 모듈식 기능을 추가하는 스마트 계약을 위한 추가 "DeFi 화이트리스트"가 있습니다. 거버넌스는 각각의 새로운 화이트리스트 DeFi 기능을 승인할 수 있습니다. 예를 들어, 청산 계약은 veFPIS 잔액에 대해 빌릴 경우 스테이커의 기본 FPIS 토큰을 청산할 수 있는 거버넌스에 의해 화이트리스트에 추가될 수 있습니다. 사용자는 각 사용자에 대해 새로운 기능을 잠금 해제하기 전에 FPIS 토큰을 사용하기 위해 각 DeFi 화이트리스트 계약을 승인해야 합니다. 이를 통해 스테이킹 시스템은 완전히 신뢰할 수 없는 상태를 유지하여 추가 로직이 스테이커의 승인 없이 스테이커의 veFPIS 잔액에 액세스할 수 없으므로 지갑 주소당 모듈 옵트인을 유지할 수 있습니다. 이 시스템을 통해 거버넌스는 veFPIS 보유자가 CPI 게이지 가중치에 투표할 수 있는 스마트 계약을 추가하여 "절감 조건"과 같은 veFPIS 스테이킹에 새로운 반복 기능을 추가하고 더 높은 수익을 얻을 수 있는 새로운 방법(사용자가 선택하면 잠재적으로 삭감됨)을 추가할 수 있습니다. , FPI 차용 또는 유동성 배포 제어. --- [Next Page](/llms-full.txt/1)