FIP 58 - Deprecate Buybacks/Recollateralizations for Fraxswap TWAMMs


Deprecate the buyback() and recollateralize() functions and instead use TWAMMs to expand/contract the FRAX supply and/or burn FXS through a TWAMM AMO.


Since FRAX v1, the protocol has had 2 functions (buyback() & recollateralize()) to hit the target CR by either buying back and burning FXS for USDC or minting FXS for USDC. These functions allow anyone to swap collateral (USDC) to/from the protocol at the Chainlink oracle price of FXS. These functions serve to make sure the amount of collateral the protocol has match the target collateral ratio either by using excess collateral to burn FXS and matching the CR or by minting FXS to taken in USDC to raise the CR to target.

Documentation can be seen here:

These functions essentially serve the purpose of either increasing or decreasing the collateral held on the balance sheet to make sure the CR is properly on target.

With the advent of Fraxswap and TWAMMs, these swaps can be done in as decentralized and permissionless of a manner through an AMO contract that sets up TWAMMs for the appropriate assets. This is one of the main use cases that Fraxswap was in fact built for.

Documentation for Fraxswap TWAMMs can be found at: Technical Specifications - Frax Finance ¤


Permanently deprecate the above functions to perform the same monetary policy through a TWAMM AMO and Fraxswap buy/sell orders of TWAMMs. This has the same trust assumptions and monetary policy effects but is more capital efficient, useful, and helps bring more trading activity+usage of Fraxswap, our native AMM.


Deprecate buyback() and recollateralize() functions and deploy a TWAMM AMO contract to set buy/sell orders of FRAX, collateral, and/or FXS directly on Fraxswap


Do nothing.


This is a big step forward for Frax. Frax has come so far from the v1 that launched in 2020.

100% full support.

i see no reason why this would not be a good thing but will there be any extra/new risks or will any current risks be reduced ?

Have any security audits of the FraxSwap code been carried out? I’m very much for this proposal as it should benefit the protocol, but may be hesitant to fully adopt FraxSwap this early, if it has not been audited.

Travis mentioned these two audits

Also hugely in support of this proposal!


Thanks for the info. Very good to see.