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:

  • • frxETH V2 is expected to allow anonymous validator pools that can use escrowed exit messages as collateral to borrow additional ETH.

Summary

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)

Current Model (V2 onwards)

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

Deployments

State Variables

ERC-20 (Inherited)

AccessControl (Inherited)

FXS-Specific

address public FRAXStablecoinAdd

Address of the FRAX contract.

uint256 genesis_supply

Genesis supply of FXS.

uint256 public maximum_supply

Maximum supply of FXS.

uint256 public FXS_DAO_min

Minimum FXS required to join DAO groups.

address public owner_address

Address of the contract owner.

address public oracle_address

Address of the oracle.

address public timelock_address

Address of the timelock.

FRAXStablecoin private FRAX

The FRAX contract instance.

struct Checkpoint {
    uint32 fromBlock;
    uint96 votes;
}

From Compound Finance. Used for governance voting.

mapping (address => mapping (uint32 => Checkpoint)) public checkpoints

List of voting power for a given address, at a given block.

mapping (address => uint32) public numCheckpoints

Checkpoint count for an address.

Restricted Functions

setOracle

setOracle(address new_oracle) external onlyByOracle

Change the address of the price oracle.

setFRAXAddress

setFRAXAddress(address frax_contract_address) external onlyByOracle

Set the address of the FRAX contract.

setFXSMinDAO

setFXSMinDAO(uint256 min_FXS) external onlyByOracle

Set minimum FXS required to join DAO groups.

mint

mint(address to, uint256 amount) public onlyPools

Mint new FXS tokens.

pool_mint

pool_mint(address m_address, uint256 m_amount) external onlyPools

This function is what other FRAX pools will call to mint new FXS (similar to the FRAX mint).

pool_burn_from

pool_burn_from(address b_address, uint256 b_amount) external onlyPools

This function is what other FRAX pools will call to burn FXS.

Overridden Public Functions

transfer

transfer(address recipient, uint256 amount) public virtual override returns (bool)

Transfer FXS tokens.

transferFrom

transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool)

Transfer FXS tokens from another account. Must have an allowance set beforehand.

Public Functions

getCurrentVotes

getCurrentVotes(address account) external view returns (uint96)

Gets the current votes balance for account.

getPriorVotes

getPriorVotes(address account, uint blockNumber) public view returns (uint96)

Determine the prior number of votes for an account as of a block number. Block number must be a finalized block or else this function will revert to prevent misinformation.

Internal Functions

_moveDelegates

_moveDelegates(address srcRep, address dstRep, uint96 amount) internal

Misnomer, from Compound Finance's _moveDelegates. Helps keep track of available voting power for FXS holders.

_writeCheckpoint

_writeCheckpoint(address voter, uint32 nCheckpoints, uint96 oldVotes, uint96 newVotes) internal

From Compound Finance's governance scheme. Helps keep track of available voting power for FXS holders at a specific block. Called when a FXS token transfer, mint, or burn occurs.

safe32

safe32(uint n, string memory errorMessage) internal pure returns (uint32)

Make sure the provided int is 32 bits or less, and convert it to a uint32.

safe96

safe96(uint n, string memory errorMessage) internal pure returns (uint96)

Make sure the provided int is 96 bits or less, and convert it to a uint96.

add96

add96(uint96 a, uint96 b, string memory errorMessage) internal pure returns (uint96)

Add two uint96 integers safely.

sub96

sub96(uint96 a, uint96 b, string memory errorMessage) internal pure returns (uint96) 

Subtract two uint96 integers safely.

getChainId

getChainId() internal pure returns (uint)

Return the Ethereum chain ID the contract is deployed on

Events

VoterVotesChanged

VoterVotesChanged(address indexed voter, uint previousBalance, uint newBalance)

Emitted when a voters account's vote balance changes

FXSBurned

FXSBurned(address indexed from, address indexed to, uint256 amount)

Emitted when FXS is burned, usually from a redemption by the pool

Modifiers

onlyPools

onlyPools()

Restrict actions to pool contracts, e.g. minting new FXS.

onlyByOracle

onlyByOracle()

Restrict actions to the oracle, such as setting the FRAX and oracle addresses

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.

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

Prior Work

Frax Governance

Frax Governance is a dual Governor system consisting of FraxGovernorAlpha and FraxGovernorOmega. Alpha and Omega have different uses and configurations.

FraxGovernorOmega

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

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

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.

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

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

Deployments

State Variables

ERC-20 (Inherited)

AccessControl (Inherited)

FRAX-Specific

An enum declaring FRAX and FXS. Used with oracles.

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.

Decimals for the Chainlink ETH / USD trading pair price.

Instance for the FRAX / WETH Uniswap pair price oracle.

Instance for the FXS / WETH Uniswap pair price oracle.

Array of owner address, who have privileged actions.

Address of the governance contract.

Address of the contract creator.

Address of the timelock contract.

Address of the FXS contract

Address for the fraxEthOracle .

Address for the fxsEthOracle .

Address for the canonical wrapped-Ethereum (WETH) contract. Should be 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 for the mainnet.

Address for the ChainlinkETHUSDPriceConsumer .

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.

Array of all the FraxPool contract addresses.

Essentially the same as frax_pools_array , but in mapping form. Useful for gas savings in various functions like globalCollateralValue() .

The current ratio of FRAX to collateral, over all FraxPool s.

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.

The fee for minting FRAX from FXS and/or collateral. See the FraxPool contract for usage.

Set in the constructor. Used in AccessControl .

A constant used in the pausing of the collateral ratio.

Whether or not the collateral ratio is paused.

View Functions

oracle_price

Get the FRAX or FXS price, in USD.

frax_price

Returns the price for FRAX from the FRAX-ETH Chainlink price oracle.

fxs_price

Returns the price for FXS from the FXS-ETH Chainlink price oracle.

frax_info

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

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

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

Public implementation of internal _mint().

pool_burn_from

Used by pools when user redeems.

pool_mint

This function is what other frax pools will call to mint new FRAX.

addPool

Adds collateral addresses supported, such as tether and busd, must be ERC20.

removePool

Remove a pool.

setOwner

Sets the admin of the contract

setFraxStep

Sets the amount that the collateral ratio will change by upon an execution of refreshCollateralRatio(),

setPriceTarget

Set the price target to be used for refreshCollateralRatio() (does not affect minting/redeeming).

setRefreshCooldown

Set refresh cooldown for refreshCollateralRatio().

setRedemptionFee

Set the redemption fee.

setMintingFee

Set the minting fee.

setFXSAddress

Set the FXS address.

setETHUSDOracle

Set the ETH / USD oracle address.

setFRAXEthOracle

Sets the FRAX / ETH Uniswap oracle address

setFXSEthOracle

Sets the FXS / ETH Uniswap oracle address

toggleCollateralRatio

Toggle pausing / unpausing the collateral ratio.

Events

FRAXBurned

Emitted when FRAX is burned, usually from a redemption by the pool.

Modifiers

onlyCollateralRatioPauser

Restrict actions to the designated collateral ratio pauser.

onlyPools

Restrict actions to pool contracts, e.g. minting new FRAX.

onlyByGovernance

Restrict actions to the governance contract, e.g. setting the minting and redemption fees, as well as the oracle and pool addresses.

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

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.

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

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.

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

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.

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

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:

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.

The combination of two such curves allows for the expression of one or another, depending on what the ratio of the balances in the pool are, according to a coefficient. Using a dimensionless parameter $XD^{n-1}$ as the coefficient, one may generalize the combination of the two curves to N coins.

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.

⚠️ This page only applies to very early farms, though many newer farms share features and function names ⚠️

Based on Synthetix's staking contract:

Description

Frax users are able to stake in select Uniswap liquidity pool tokens in exchange for FXS rewards. Future pools and incentives can be added by governance.

Deployment

Liquidity Pool Tokens (LP)

Uniswap FRAX/WETH LP: 0xFD0A40Bc83C5faE4203DEc7e5929B446b07d1C76

Uniswap FRAX/USDC LP: 0x97C4adc5d28A86f9470C70DD91Dc6CC2f20d2d4D

Uniswap FRAX/FXS LP: 0xE1573B9D29e2183B1AF0e743Dc2754979A40D237

Uniswap FXS/WETH LP: 0xecBa967D84fCF0405F6b32Bc45F4d36BfDBB2E81

Staking Contracts

Uniswap FRAX/WETH staking: 0xD875628B942f8970De3CcEaf6417005F68540d4f

Uniswap FRAX/USDC staking: 0xa29367a3f057F3191b62bd4055845a33411892b6

Uniswap FRAX/FXS staking: 0xda2c338350a0E59Ce71CDCED9679A3A590Dd9BEC

Uniswap FXS/WETH staking (deprecated): 0xDc65f3514725206Dd83A8843AAE2aC3D99771C88

State Variables

FRAXStablecoin private FRAX

Instance of the FRAX contract.

ERC20 public rewardsToken

Instance for the reward token.

ERC20 public stakingToken

Instance for the staking token.

uint256 public periodFinish

Block when the staking period will finish.

uint256 public rewardRate

Maximum reward per second.

uint256 public rewardsDuration

Reward period, in seconds.

uint256 public lastUpdateTime

Last timestamp where the contract was updated / state change.

uint256 public rewardPerTokenStored

Actual reward per token in the current period.

uint256 public locked_stake_max_multiplier

Maximum boost / weight multiplier for locked stakes.

uint256 public locked_stake_time_for_max_multiplier

The time, in seconds, to reach locked_stake_max_multiplier .

uint256 public locked_stake_min_time

Minimum staking time for a locked staked, in seconds.

string public locked_stake_min_time_str

String version is locked_stake_min_time_str .

uint256 public cr_boost_max_multiplier

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

mapping(address => uint256) public userRewardPerTokenPaid

Keeps track of when an address last collected a reward. If they collect it some time later, they will get the correct amount because rewardPerTokenStored is constantly varying.

mapping(address => uint256) public rewards

Current rewards balance for a given address.

uint256 private _staking_token_supply

Total amount of pool tokens staked .

uint256 private _staking_token_boosted_supply

_staking_token_supply with the time and CR boosts accounted for. This is not an actual amount of pool tokens, but rather a 'weighed denominator'.

mapping(address => uint256) private _balances

Balance of pool tokens staked for a given address.

mapping(address => uint256) private _boosted_balances

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

mapping(address => LockedStake[]) private lockedStakes

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

struct LockedStake {
        bytes32 kek_id;
        uint256 start_timestamp;
        uint256 amount;
        uint256 ending_timestamp;
        uint256 multiplier; // 6 decimals of precision. 1x = 1000000
    }

A locked stake 'lot'.

View Functions

totalSupply

totalSupply() external override view returns (uint256)

Get the total number of staked liquidity pool tokens.

stakingMultiplier

stakingMultiplier(uint256 secs) public view returns (uint256)

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

crBoostMultiplier

crBoostMultiplier() public view returns (uint256)

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

stakingTokenSupply

stakingTokenSupply() external view returns (uint256)

same as totalSupply().

balanceOf

balanceOf(address account) external override view returns (uint256)

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

boostedBalanceOf

boostedBalanceOf(address account) external view returns (uint256)

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

lockedBalanceOf

lockedBalanceOf(address account) public view returns (uint256)

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

unlockedBalanceOf

unlockedBalanceOf(address account) external view returns (uint256)

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

lockedStakesOf

lockedStakesOf(address account) external view returns (LockedStake[] memory)

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

stakingDecimals

stakingDecimals() external view returns (uint256)

Returns the decimals() for stakingToken .

rewardsFor

rewardsFor(address account) external view returns (uint256)

Get the amount of FXS rewards for a given account .

lastTimeRewardApplicable

lastTimeRewardApplicable() public override view returns (uint256)

Used internally to keep track of rewardPerTokenStored .

rewardPerToken

rewardPerToken() public override view returns (uint256)

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

earned

earned(address account) public override view returns (uint256)

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

getRewardForDuration

getRewardForDuration() external override view returns (uint256)

Calculates the FXS reward for a given rewardsDuration period.

Mutative Functions

stake

stake(uint256 amount) external override nonReentrant notPaused updateReward(msg.sender)

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

stakeLocked

stakeLocked(uint256 amount, uint256 secs) external nonReentrant notPaused updateReward(msg.sender)

Stakes some Uniswap liquidity pool tokens and also locks them for the specified secs . In return for having their tokens locked, the staker's base amount will be multiplied by a linear time-based multiplier, which ranges from 1 at secs = 0 to locked_stake_max_multiplier at locked_stake_time_for_max_multiplier. The staked value is also multiplied by the crBoostMultiplier() . This multiplied value is added to _boosted_balances and acts as a weighted amount when calculating the staker's share of a given period reward.

withdraw

withdraw(uint256 amount) public override nonReentrant updateReward(msg.sender)

Withdraw unlocked Uniswap liquidity pool tokens.

withdrawLocked

withdrawLocked(bytes32 kek_id) public nonReentrant updateReward(msg.sender)

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

getReward

getReward() public override nonReentrant updateReward(msg.sender)

Claim FXS rewards.

exit

exit() external override

Withdraw all unlocked pool tokens and also collect rewards.

renewIfApplicable

renewIfApplicable() external

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

retroCatchUp

retroCatchUp() internal

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

Restricted Functions

notifyRewardAmount

notifyRewardAmount(uint256 reward) external override onlyRewardsDistribution updateReward(address(0))

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

recoverERC20

recoverERC20(address tokenAddress, uint256 tokenAmount) external onlyOwner

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

setRewardsDuration

setRewardsDuration(uint256 _rewardsDuration) external onlyOwner

Set the duration of the rewards period.

setLockedStakeMaxMultiplierUpdated

setLockedStakeMaxMultiplierUpdated(uint256 _locked_stake_max_multiplier) external onlyOwner

Set the maximum multiplier for locked stakes.

setLockedStakeTimeForMaxMultiplier

setLockedStakeTimeForMaxMultiplier(uint256 _locked_stake_time_for_max_multiplier) external onlyOwner

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

setLockedStakeMinTime

setLockedStakeMinTime(uint256 _locked_stake_min_time) external onlyOwner

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

setMaxCRBoostMultiplier

setMaxCRBoostMultiplier(uint256 _max_boost_multiplier) external onlyOwner

aaa

initializeDefault

initializeDefault() external onlyOwner

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

Modifiers

updateReward

updateReward(address account)

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

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

All prices exist as ratios between one entity and another. Conventially, we select a currency as the shared unit-of-account in the denominator (e.g. USD) to compare prices for everyday goods and services. In Uniswap, prices are defined by the ratio of the amounts of reserves of $x$ to reserves of $y$ in the pool.

Uniswap v3's range-order mechanic fits into the existing $x*y = k$ constant-product market-making invariant (CPMM) by "virtualizing" the reserves at a specific price point, or tick. Through specifying which ticks a liquidity position is bounded by, range-orders are created that follow the constant-product invariant without having to spread the liquidity across the entire range$(0, \infty)$for a specific asset.

A price in Uniswap v3 is defined by the value 1.0001 to the power of the tick value $i$. The boundaries for the prices of ticks can be represented by the algebraic group $G = \{ g^i \mid i \in \mathbb{Z}, g = 1.0001\}$. This mechanism allows for easy conversion of integers to price boundaries, and has the convenience of discretiating each tick-price-boundary as one basis point (0.01%) in price from another.

Virtual reserves are tracked by tracking the liquidity and tick bounds of each position. Crossing a tick boundary, the liquidity $L$ available for that tick may change to reflect positions entering and leaving their respective price ranges. Within the tick boundaries, swaps change the price $\sqrt{P}$ according to the virtual reserves, i.e. it acts like the constant-product ($x*y=k$) invariant. The virtual reserves x and y can be calculated from the liquidity and price:

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.

Liquidity can be thought of as a virtual $k$ in the $x*y=k$ CPMM, while $\Delta Y$ corresponds to amount of asset $Y$ and $\Delta\sqrt P$ represents the intra-tick price slippage.

Since $L$ is fixed for intra-tick swaps, $\Delta X$ and $\Delta Y$ can be calculated from the liquidity and square root of the price. When crossing over a tick, the swap must only slip until the $\sqrt P$ boundary, and then re-adjust the liquidity available for the next tick.

Summary

Details

Summary

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

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.

Contracts

Operations Contracts

Core Contracts

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.

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.

sFRAX

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

npm install @fraxfinance/layerzero-v2-upgradeable

import { OptionsBuilder } from "@fraxfinance/layerzero-v2-upgradeable/oapp/contracts/oapp/libs/OptionsBuilder.sol";
import { SendParam, MessagingFee, IOFT } from "@fraxfinance/layerzero-v2-upgradeable/oapp/contracts/oft/interfaces/IOFT.sol";

uint256 amount = 1e18;
// Upgradeable FRAX - Bridging FROM Mode
address oft = 0x80eede496655fb9047dd39d9f418d5483ed600df; 
// Ethereum - choose destination EID from https://github.com/FraxFinance/frax-oft-upgradeable/blob/master/scripts/L0Config.json
uint32 dstEid = 30101;

bytes memory options = OptionsBuilder.newOptions();
SendParam memory sendParam = SendParam({
        dstEid: dstEid,
        to: bytes32(uint256(uint160(msg.sender))),
        amountLD: amount,
        minAmountLD: amount,
        extraOptions: options,
        composeMsg: '',
        oftCmd: ''
});
MessagingFee memory fee = IOFT(_oft).quoteSend(sendParam, false);
IOFT(_oft).send{value: fee.nativeFee}(
    sendParam,
    fee,
    payable(msg.sender)
);

Contracts & Addresses

Admin

• ProxyAdmin: 0x223a681fc5c5522c85c96157c0efa18cd6c5405c

• Msigs (links to gnosis safe)

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.

FPI

FPIS

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

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.

Ethereum -> Fraxtal (~ a few minutes)

Fraxtal -> Ethereum (7 days)

Summary

Many of these AMOs also earn income for the protocol.

AMOs (new for V3)

Aave AMO

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.

Fraxlend AMO

The Fraxlend AMO contract addresses:

Fraxswap TWAMM AMO

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.

Miscellaneous

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.

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

Description

The oracle uses Chainlink's December 2021 CPI-U data point (provided by Fiews) as the 'base' index for determining the peg price. Each month, the change / delta percent of the index is applied to the previous month's data point to determine the peg price. December 2021 was chosen because the oracle contract requires two initial 'historical' data points.

Example:

December 2021 CPI-U: 280.126

January 2022 CPI-U: 281.933

Delta is (281.933 / 280.126) - 1 = 0.64506686%

Assuming December 2021 is $1, applying the delta percentage gives

$1 x (1.0064506686) = $1.0064506686 as the peg price.

If February 2022 CPI-U data was 284.182, the delta would be (284.182 / 281.933) - 1 = 0.79770726%.

Applying this to the previous peg price would give $1.0064506686 * (1 + 0.0079770726) = $1.0144791987 as the new peg price. In other words, you would need this many Feb 2022 dollars to buy one Dec 2021 dollar.

Code

FPI

FPIS