[Discussion] Extend buyback and make to Feeder Pools

Would like to start the ball rolling on extending the current implementation of buyback and make as outlined in MIP-8 and discussed previously in this forum thread to include system revenue from feeder pools in addition to Save.


  • Great reflexivity effect on the MTA token value which boosts APY % (which in turn boosts liquidity and swap fees)
  • Feeder Pools directly drive system revenue in the mStable ecosystem through deeper liquidity and higher swap volume
  • We could easily direct some system revenue to MTA without sacrificing a lot of returns to liquidity providers

What do you guys think of enabling the system fee from fPools?


Definitely in favor of this, would be good to talk a little bit about numbers here, as I’m sure they are somewhat different than system revenue from our other pools, right?

1 Like

Great idea. Goal should always be to ensure every feature accrues value back to the token and reinforce the powerful reflexivity behind mStable. This idea achieves that. Same 10% allocation as with Save revenue makes logical sense.


Thumbs up from me. Also agree with Cold Summer, 10% would be logical.

You are on the ball as always derc, I’m also in support of making this change!

Makes a lot of sense to enable system fees on the fPools. 10% seems like the logical choice.

Yes, mStable can extract gov fee from a variety of ways, from Save, from COMP/AAVE/BAL rewards liquidation, from feeder pools, from swap fees etc.

1 Like

fPool revenue is basically:

  • swaps from mAsset → fAsset (which includes paths from a main pool asset → mAsset → fAsset)
  • fpToken redemption
  • lending market interest (currently GUSD is on AAVE v2)

The fees are collected in fpToken terms. An idea for executing this proposal could be to convert the fpToken → mAsset, then send that mAsset to be collected with the rest of the mAsset revenue when the collection happens. Thus all revenue is converted into mAssets.

I think that given the MTA APY’s are so high on the fPools, and native pool APY takes second order, we have an opportunity to extract some value here.

In favour of starting with 10%.

1 Like

Thanks for elaborating on the intricacies, and that makes a lot of sense to me. Definitely thinking that 10% is a good number to start with, and hope this will make it towards a formal proposal and vote soon.

This suggestion was put into a formal proposal: PDP 20