[FIP - 377] Change veFXS Reward Distribution Token

Governance Proposals FIPs
1

Authors

C2tP
Sam Kazemian

Summary

There has been long discussions on how veFXS rewards should be distributed. There is merit to both buying back and distributing FXS and distributing a stable coin such as sFrax or sfrxEth. In the end users can swap for the token they want (albeit liquidity can differ between the tokens).

The token of choice should be one that “does work” for the protocol and user. The more work done, the better the token choice. For example on Curve the fee token was originally 3Crv LP token. This was because having deeper liquidity on 3Crv was a major source of protocol fees. Curve has now switched to crvUSD as each crvUSD in distribution is equivalent to a crvUSD being lent out and creating fees.

One possible choice for Frax could be sFrax. sFrax does a lot of work for the user, but not all that much is gained on the protocol level. This can be an okay tradeoff though if claiming continued to be on mainnet since gas costs are higher and thus times to claim could be much longer for most users.

On Fraxtal however, gas costs are much less of an issue. Thus reward tokens should be more oriented for Protocol work. This is both good for the user in an indirect way, as well as users can withdraw and convert to something more oriented for their yield whenever they want.

The best asset choice for the protocol to issue would thus be an FXB. The protocol makes revenue in the background while the frax is waiting to be matured. If users claim and convert the FXB on the market, the protocol still has the underlying working. FXBs themselves also are yield bearing for the user (albeit at probably a slower rate than sFrax).

This proposal seeks to change veFXS revenue to be distributed as a wrapped version of the FXB20291231 issued on Fraxtal. The FXS buyback as part of the FLE system will stay the same.

The wrapper for this token will automatically use the underlying FXB as collateral in FraxLend and borrow frax for sFrax if interest rates are profitable. Users will gain compounded FXB tokens and can withdraw at any time. FraxLend AMO will also gain some interest by lending to the FraxLend pair.

Wrapper can be found here (frax-cvx-platform/contracts/contracts/fraxtal/cvxFXB.sol at main · convex-eth/frax-cvx-platform · GitHub) and is currently under audit. Audit must be cleared to satisfactory levels before being used as the veFXS reward token.

As of note, the wrapper will contain a migration function to move underlying fxb to a different fxb type. The admin role for setting this migration will be held by the Frax comptroller multisig or Frax Governance.

Also the current name of the token (cvxFXB) is subject to change if we or the Frax team decide on something better before deployment.

Fees

There will be a standard market fee of 10% as a management fee.
This fee is only applied to revenue gained via the borrowing aspect of the wrapper and in no way applies to underlying vefxs rewards.

Voting

For: Change veFXS reward token distribution to the cvxFXB FXB wrapper.
Against: Do nothing.

7 Likes
2

Will there be any chance of systemic risk when so much money will be used as a underlying collateral to borrow Frax for sFrax when rates are profitable? Would look bad for the protocol if suddenly our staking rewards/revenue got liquidated.

3

There’s no price volatility risks with the fxb oracles. Only risk of liquidation is by interest fees growing too far.

2 Likes
4

Love it. Think some of us have been asking for a more stable form of yield to be distributed and this would achieve that while also helping to grow Frax interest rate curves, no pun intended.

1 Like
5

@C2tP-C2tP

Thank you for adding information regarding the 10% fees.

I know that Frax is pushing for full transparency in a simplified format for all revenues generated on the Frax ecosystem.

Will Convex provide a UI so that any user can see how much Convex profited over the last week/month/year in fees for this borrowing aspect of the wrapper?

Thank you,

6

Is this a standard fee of 10%? Personally I think this is rather high, and would want to settle on around 2% since it is potentially a lot of funds you will manage. 2% is still quite high when comparing to traditional fund management.

If 2% is a no-go for Convex, I think we should meet a middle ground. 10% considering the revenue potential seems high in my opinion.

7

I think most funds get a percentage of AUM rather than just the revenue generated from those assets.

8

That is true lol. My bad.

9

What would happen with the FXS that remains to be bought back? just used in the LP pairings?

10

How would the bonds being purchased change in the future. For example, in 2030 we can’t buy FXB20291231. Is the idea to purchase bonds that mature in 5-6 years (e.g., 2024->2030)? I’d be nice if there was a flexibility strategy so we don’t need to governance vote each time we need to migrate to a different bond.

11

This proposal is up for voting here: Snapshot

12

Seems like a trivial query that anyone could make if they wanted to see it.

I get the feeling people are overestimating what it will be

13

You most definitely want a governance vote to change the underlying. Not really something to just toss about on a whim.

14

I wasn’t thinking to change it on a whim, but to have a system. For example, we buy bonds that mature December 31st of the fifth year (e.g., in 2024 buy FXB20291231, in 2025 buy FXB20301231, in 2027 buy FXB20311231). That way it’s predictable, repeatable, and we’re always buying equivalent bonds (e.g., without a vote, well buy bonds that expire in 5 years now and in 1 year in 2028).

Alternatively, just leaving it up to Frax/Convex to manage instead of having a fixed bond type.

If it’s going to require a governance vote, I assume Frax or Convex will be accountable for drafting and getting alignment on a new bond before FXB20291231 bonds expire or they no longer make sense for this purpose? I don’t think we should rely on the community to manage.

What happens if in 2030 a new governance vote hasn’t passed?

15

Just hoping for the developing mindset of: transparency is part of any new feature.

Example: in any web2 protocol with a mature team: they don’t build something unless success can be easily measured, therefore, the team not only builds the feature, but, they build ways to track success metrics as well.

In my opinion, all revenue that comes in/out/ or is involved with the Frax ecosystem should be transparent and easily digestible as part of building any feature.

The transparent mindset is one of the many ways that the Frax ecosystem can win long term and it would be awesome if you could lead by example and create a standard for all other development.