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) 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). 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.

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 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: “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.

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). However, FXS is no longer needed to mint FRAX. That functionality is delegated to AMOs.

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

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.

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, 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.

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.

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.

Deployments

State Variables

ERC-20 (Inherited)

https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#ERC20

AccessControl (Inherited)

https://docs.openzeppelin.com/contracts/3.x/api/access#AccessControl

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 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 – a USD pegged asset.

  • FPI – 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) – a Liquid Staking Derivative (LSD) 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 – 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) – 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 – 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) – 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 – A modular L2 chain, based on Optimism technology, that uses frxETH as the gas token.

  • Fraxtal Points FXTL – Users earn FXTL for useful activities on Fraxtal, such as spending gas, creating heavily-used contracts, and farming in specific pools.

• Frax Bonds (FXB) – 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) – ERC4626 staking vault that distributes part of the Frax Protocol yield weekly to stakers. Denominated in FRAX stablecoins.

• Fraxferry – Optimistic transfer protocol for Frax-based tokens. Fraxferry transfers natively issued Frax Protocol tokens across many blockchains.

• Frax Share (FXS) – The base-layer governance token for the entire Frax ecosystem of smart contracts. It accrues fees, revenue, and excess collateral value.

• veFXS – Users lock FXS for a variable amount of time and receive voting power and farming weight boosts. Inspired by Curve's veCRV.

• Gauge Rewards System – 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.

Website: https://app.frax.finance Telegram: https://t.me/fraxfinance Telegram (announcements / news): https://t.me/fraxfinancenews Discord: https://discord.com/invite/fraxfinance Twitter: https://twitter.com/fraxfinance Medium / Blog: https://fraxfinancecommunity.medium.com/ Governance (discussion): https://gov.frax.finance/ Governance (voting): https://snapshot.org/#/frax.eth

After a proposal is discussed in the Governance Forum, it can be voted on using Snapshot. 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). 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

cast calldata "nominateDelegateeCrossChain(address)" "<delegatee address on Fraxtal>"

2) Call the following on Ethereum with your delegator address:

L1CrossDomainMessenger.sendMessage(0x9D269188b741277fF316862B537bd4fce14637b3, <hex message>, 500000)

This calls DoubleOptInVeFXSDelegation.nominateDelegateeCrossChain on Fraxtal

3) Wait a few minutes

4) With your delegatee address on Fraxtal, call:

DoubleOptInVeFXSDelegation.acceptDelegation(<delegator address>)

If delegator is on Fraxtal

1) With the delegator, call:

DoubleOptInVeFXSDelegation.nominateDelegatee(<delegatee address>)

2) With the delegatee, call:

DoubleOptInVeFXSDelegation.acceptDelegation(<delegator address>)

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:

L1CrossDomainMessenger.sendMessage(0x9D269188b741277fF316862B537bd4fce14637b3, 0x617075fe, 500000)

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()

Background

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

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

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

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.

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).

veFXS Boosts & Timelock Boosts

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.

⚠️ The original mint/redeem model explained here has been retired in favor of later (V2 onwards) mechanisms and is for historic / information purposes only ⚠️

This base mechanism can be abstracted down to the following:

2. Equilibrium - Don't change the CR 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.

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.

Major Components

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.

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

2. Click Propose

3. Make sure your voting weight is above the proposal threshold
4. Fill out your transaction data

5. Submit

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)

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

⚠️ 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.

⚠️ This AMO has been deprecated. Many of its functions have been moved to V3 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

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.

Prior Work

Frax Governance is based largely on Compound/OpenZeppelin Governor contracts. The lifecycle of a Governor proposal is covered here: https://docs.openzeppelin.com/contracts/4.x/governance#proposal_lifecycle.

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 (https://docs.safe.global/safe-core-protocol/hooks).

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 (https://docs.safe.global/safe-core-protocol/plugins) 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

Deployments

State Variables

ERC-20 (Inherited)

https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#ERC20

AccessControl (Inherited)

https://docs.openzeppelin.com/contracts/3.x/api/access#AccessControl 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.

Ethereum Mainnet

Frax Comptrollers

Other Multisigs

Layer Zero

Comptrollers

⚠️ 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

Instance of the FRAX contract.

Instance for the reward token.

Instance for the staking token.

Block when the staking period will finish.

Maximum reward per second.

Reward period, in seconds.

Last timestamp where the contract was updated / state change.

Actual reward per token in the current period.

Maximum boost / weight multiplier for locked stakes.

The time, in seconds, to reach locked_stake_max_multiplier .

Minimum staking time for a locked staked, in seconds.

String version is locked_stake_min_time_str .

Maximum boost / weight multiplier from the collateral ratio (CR). This is applied to both locked and unlocked stakes.

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.

Current rewards balance for a given address.

Total amount of pool tokens staked .

_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'.

Balance of pool tokens staked for a given address.

_balances , but with the time and CR boosts accounted for, like _staking_token_boosted_supply.

Gives a list of locked stake lots for a given address.

A locked stake 'lot'.

View Functions

totalSupply

Get the total number of staked liquidity pool tokens.

stakingMultiplier

Get the time-based staking multiplier, given the secs length of the stake.

crBoostMultiplier

Get the collateral ratio (CR) - based staking multiplier.

stakingTokenSupply

same as totalSupply().

balanceOf

Get the amount of staked liquidity pool tokens for a given account.

boostedBalanceOf

Get the boosted amount of staked liquidity pool tokens for a given account. Boosted accounts for the CR and time-based multipliers.

lockedBalanceOf

Get the amount of locked staked liquidity pool tokens for a given account .

unlockedBalanceOf

Get the amount of unlocked / free staked liquidity pool tokens for a given account .

lockedStakesOf

Return an array of all the locked stake 'lots' for

stakingDecimals

Returns the decimals() for stakingToken .

rewardsFor

Get the amount of FXS rewards for a given account .

lastTimeRewardApplicable

Used internally to keep track of rewardPerTokenStored .

rewardPerToken

The current amount of FXS rewards for staking a liquidity pool token.

earned

Returns the amount of unclaimed FXS rewards for a given account .

getRewardForDuration

Calculates the FXS reward for a given rewardsDuration period.

Mutative Functions

stake

Stakes some Uniswap liquidity pool tokens. These tokens are freely withdrawable and are only boosted by the crBoostMultiplier().

stakeLocked

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 unlocked Uniswap liquidity pool tokens.

withdrawLocked

Withdraw locked Uniswap liquidity pool tokens. Will fail if the staking time for the specific kek_id staking lot has not elapsed yet.

getReward

Claim FXS rewards.

exit

Withdraw all unlocked pool tokens and also collect rewards.

renewIfApplicable

Renew a reward period if the period's finish time has completed. Calls retroCatchUp() .

retroCatchUp

Renews the period and updates periodFinish , rewardPerTokenStored , and lastUpdateTime .

Restricted Functions

notifyRewardAmount

This notifies people (via the event RewardAdded ) that the reward is being changed.

recoverERC20

Added to support recovering LP Rewards from other systems to be distributed to holders.

setRewardsDuration

Set the duration of the rewards period.

setLockedStakeMaxMultiplierUpdated

Set the maximum multiplier for locked stakes.

setLockedStakeTimeForMaxMultiplier

Set the time, in seconds, when the locked stake multiplier reaches locked_stake_max_multiplier .

setLockedStakeMinTime

Set the minimum time, in seconds, of a locked stake.

setMaxCRBoostMultiplier

aaa

initializeDefault

Intended to only be called once in the lifetime of the contract. Initializes lastUpdateTime and periodFinish .

Modifiers

updateReward

Calls retroCatchUp() , if applicable, and otherwise syncs rewardPerTokenStored and lastUpdateTime . Also, syncs the rewards and userRewardPerTokenPaid for the provided account .

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)

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.

In cases of extreme imbalance, the invariant approaches the Uniswap constant-product curve.

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

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.

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.

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.

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

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.

Overview

What is the point of Fraxtal? Aren't there so many L2 chains already?

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:

⚠️ 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.

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

Instance for the collateral token in the pool.

Address of the collateral token.

List of the pool owners.

Address of the oracle contract.

Address of the FRAX contract.

Address of the FXS contract.

Address of the timelock contract.

Instance of the FXS contract.

Instance of the FRAX contract.

Instance of the oracle contract.

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.

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.

Sum of the redeemCollateralBalances.

Sum of the redeemFXSBalances.

Keeps track of the last block a given address redeemed.

Maximum amount of collateral the pool can take.

AccessControl role for the mint pauser.

AccessControl role for the redeem pauser.

AccessControl role for the buyback pauser.

Whether or not minting is paused.

Whether or not redeem is paused.

Whether or not buyback is paused.

View Functions

unclaimedFXS

Return the total amount of unclaimed FXS.

unclaimedCollateral

Return the total amount of unclaimed collateral.

collatDollarBalance

Return the pool's total balance of the collateral token, in USD.

availableExcessCollatDV

Return the pool's excess balance of the collateral token (over that required by the collateral ratio), in USD.

getCollateralPrice

Return the price of the pool's collateral in USD.

Public Functions

mint1t1FRAX

Mint FRAX from collateral. Valid only when the collateral ratio is 1.

mintFractionalFRAX

Mint FRAX from collateral and FXS. Valid only when the collateral ratio is between 0 and 1.

mintAlgorithmicFRAX

Mint FRAX from FXS. Valid only when the collateral ratio is 0.

redeem1t1FRAX

Redeem collateral from FRAX. Valid only when the collateral ratio is 1. Must call collectionRedemption() later to collect.

redeemFractionalFRAX

Redeem collateral and FXS from FRAX. Valid only when the collateral ratio is between 0 and 1. Must call collectionRedemption() later to collect.

redeemAlgorithmicFRAX

Redeem FXS from FRAX. Valid only when the collateral ratio is 0. Must call collectionRedemption() later to collect.

collectRedemption

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

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

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

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

Toggle the ability to mint.

toggleRedeeming

Toggle the ability to redeem.

toggleBuyBack

Toggle the ability to buyback.

setPoolCeiling

Set the pool_ceiling, which is the total units of collateral that the pool contract can hold.

setOracle

Set the oracle_address.

setCollateralAdd

Set the collateral_address.

addOwner

Add an address to the array of owners.

removeOwner

Remove an owner from the owners array.

Modifiers

onlyByOwnerOrGovernance

Restrict actions to the governance contract or the owner(s).

notRedeemPaused

Ensure redemption is not paused.

notMintPaused

Ensure minting is not paused.

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

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

⚠️ This AMO is deprecated. Most lending activities are now conducted via the 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

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.

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.

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 process: 1.) Short-dated United States treasury bills 2.) Federal Reserve Overnight Repurchase Agreements 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 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.

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). 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.

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, 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

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 but the goals are the same): 0x49ee75278820f409ecd67063D8D717B38d66bd71

Fraxlend AMO

Fraxlend 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 to lenders. The Fraxlend AMO lends newly created FRAX into Fraxlend pairs that are approved by the frxGov process and earns interest from borrowers.

The Fraxlend AMO live stats are displayed on Frax Facts.

The Fraxlend AMO contract addresses:

Ethereum Mainnet - Fraxlend AMO V1: 0x0Ed8fA7FC63A8eb5487E7F87CAF1aB3914eA4eCaEthereum Mainnet - Fraxlend AMO V3: 0xf6E697e95D4008f81044337A749ECF4d15C30Ea6Arbitrum One - Fraxlend AMO V3: 0xCDeE1B853AD2E96921250775b7A60D6ff78fD8B4 Fraxtal - Fraxlend AMO V3: 0x58C433482d74ABd15f4f8E7201DC4004c06CB611

Fraxswap TWAMM AMO

The Fraxswap TWAMM AMO loads time-weighted average market maker orders 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

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 (TODO: make repo public).

Ethereum Mainnet FXB AMO: 0x452420df4AC1e3db5429b5FD629f3047482C543C Fraxtal FXB AMO: 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) is on Ethereum. You can see a full list of positions here.

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 (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.

Details

The sFRAX vault APY is based on a utilization function that can be set by the frxGov governance module. 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 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 employed by Frax Protocol partner custodians including, but not limited to, FinresPBC. sFRAX: 0xA663B02CF0a4b149d2aD41910CB81e23e1c41c32

Summary

FXB tokens are simple, trustless tokens that resemble a zero-coupon bond 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.

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.

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 and Fraxtal AMO Operator, initiated through the FXB AMO.

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. This origin FXB contains the code to mint and burn. Once the FXB is bridged, the destination chain creates the FXB from the bridge ERC20Factory. This bridged version can only be minted and burned (redeemed) by the bridge.

Contracts

To trustfully import contracts to your local repository, refer to the frax-template.

Operations Contracts

Core Contracts

sFRAX

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 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.

FPIS

⚠️ FPIS is set to be phased out 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.

Inflation & Peg Calculation

FPI uses the CPI-U unadjusted 12 month inflation rate reported by the US Federal Government: https://www.bls.gov/news.release/cpi.nr0.htm. 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. 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.

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. Users can also buy/sell FPI in various markets such as Curve or Fraxswap.

FPI Controller Pool: 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

Ethereum -> Fraxtal (~ a few minutes)

Fraxtal -> Ethereum (7 days)

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).

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.

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.

*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 Token Distribution (100,000,000 FPIS total supply)

30% Frax Finance Treasury 30,000,000 FXS voters have total control in voting how to distribute these tokens through governance.

25% FPI Protocol Treasury 25,000,000 FPIS voters themselves have total control in how to distribute these tokens.

⚠️ 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.

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.

Description

The FPI Controller Pool has various helper functions related to FPI and its peg, such as minting and redeeming FPI.

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

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

Available Frax OFTs

• FRAX

• sFRAX

• frxETH

• sfrxETH

• FXS

• FPI

Legacy vs. Upgradeable OFTs

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 directly with LayerZero

Contracts & Addresses

Admin

• ProxyAdmin: 0x223a681fc5c5522c85c96157c0efa18cd6c5405c

• Msigs (links to gnosis safe)

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

Security Considerations

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.

Ethereum

Other Chains

FPI

FPIS