The current workflow for creating new Feeder Pools is quite involved:
- protocol due diligence
- governance proposal
- ProtocolDAO vote
- vMTA vote
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.
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.
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
- Is this structure feasible and a good way to move mStable forward?
- Is this feasible to develop and integrate into the current set of products mStable offers?
- How complex would this be to develop a Feeder Factory?
- What open questions need to be addressed first?
- What else did I miss?
This is just at the stage of Ideation. All feedback, comments, and concerns are highly appreciated.