[Idea] Feeder Pool Factory

Current Workflow

The current workflow for creating new Feeder Pools is quite involved:

  • protocol due diligence
  • governance proposal
  • ProtocolDAO vote
  • vMTA vote
  • deployment.

The Issues

The current approach is not very effective.

Firstly, it involves a lengthy process in governance and many dev hours.

Secondly, because we are actively choosing which assets to add, we are legitimizing some stable assets that way.

Take for example Uniswap with their different approach. Anyone can add any asset at any time. Uniswap does not guarantee for any added assets, because it’s permissionless to add those.

In our current workflow, we do exactly the opposite. We need to evaluate each asset that we consider adding and in a sense vouch for these assets once we choose to add them. That is great for a small project, but as mStable grows, this becomes less and less feasible. Additionally, having the team to investigate each stable asset puts the burden on the team and in case something does go wrong with another stable asset also puts the blame on the team.

What is a Feeder Factory

A Feeder Factory can add new Feeder Pools to mStable in a permissionless way. These Feeder Factories could be new smart contracts that can be used to deploy Feeder Pools with a given ERC-20 token and mAssets.

The Feeder Pools created from the Feeder Factory would not accrue any MTA until Governance decides to do so.

How does it benefit mStable?

This gives mStable a great way to grow into more assets, without the risk associated.
A lot of the issues around the current slow process would be mitigated and mStable can add a lot more assets to its current set of Pools

Open questions

  1. Is this structure feasible and a good way to move mStable forward?
  2. Is this feasible to develop and integrate into the current set of products mStable offers?
  3. How complex would this be to develop a Feeder Factory?
  4. What open questions need to be addressed first?
  5. What else did I miss?

This is just at the stage of Ideation. All feedback, comments, and concerns are highly appreciated.

5 Likes

Love this idea.

  • Permissionless deployment of fPools will be a key lever for growth as changes mStable as a product to more of a platform. We can allow any project to benefit from mUSD as a bridge asset
  • We separate the protocol from the team
  • It probably still needs dev work to be displayed on the UI
  • Any way to maintain a source list of deployed and incentivised fPools?
1 Like

Hey there,

Definitely like this idea very much, as it would add a lot to the permissionlessness of the protocol. A couple of thoughts around this:

This pretty much would go in line with what Curve has recently implemented, correct?

I think if we consider doing this, we should definitely have a very clear differentiation of what is a curated Feeder Pool by the core contributors, and what is a pool created by anyone else. I think PoolTogether has a very similar approach, where they let anyone make a pool, but not necessarily have it presented on their front-end.

We could think of having a community (experimental) front-end, or a switch to flick between the available deployments, but in any case I would definitely have certain requirements, similar to the ones described above, in order to avoid trolling or having a pool pair created that simply never gets used.

If it’s displayed on our site, we also should have at least a basic community-led diligence process in place to go through for any new assets, simply to ensure that our brand name remains professional and looked at as being of high quality.

Thinking of Uniswap, with the recent removal of synthetic derivatives, their front-end is not really permissionless anymore either, whereas other front-ends using the Uniswap contracts are, so it feels accurate to project the same idea here.

If it’s on a separate UI or deployment, I think it’s fine to open the floodgates :smile:

1 Like

After a bit of thinking, I would actually prefer to have a whitelisting process for the pool creation. Any address that is whitelisted, can deploy one (What we just did with Rari Capital). This would still mean some governance control over the pools, but we can deploy them faster and make sure no blatant scams can just add pools.

3 Likes

Great idea. Completely agree there should be a voted whitelisting process.

3 Likes

Hi,

I very much like this idea, plus having a community led front-end.

One remark though on the absence of mta accrual in these feeder pools : wouldn’t it make sense to launch a governance vote(automatically or define a rule ) once a factory feeder pool reach a certain threshold ?

My reasoning is that we should intencivise the successful pools in order to maintain the protocol TVL and help it grow even more.

Yes, this is pretty much in the pipeline: gauges for reward distribution. :slight_smile:

2 Likes