Allow Permissionless Basepools for Stableswap NG

Proposals
#1

Summary:
Proposal to allow any eligible pool to be used permissionlessly as a basepool for Stableswap-NG metapools.

Currently, only “whitelisted” pools can be used as basepools. Additional pools can be added to the whitelist by vote using the admin-only method add_base_pool in the Stableswap-NG factory. Currently, the following pools are whitelisted: 3pool, FraxBP (FRAX/USDC), wBTC/sBTC, FRAX/USDP, FRAX/pyUSD, 3payLLama (pyUSD, crvUSD, FRAX), PayPool (pyUSD/USDC)

The proposal is to remove the admin-gating on this method by deploying a new admin contract that allows this method to be used permissionlessly. This will also entail some UI updates to support the new functionality.

Motivation:
This proposal aims to make pool creation as permissionless as possible. Currently, launching new basepools requires a cumbersome governance process (see FraxBP proposal) which may deter novel developments and arguably favor incumbents. Allowing permissionless basepools can significantly broaden the pool design space by removing these hurdles.

The initial logic behind basepool whitelisting was to prevent liquidity fragmentation away from 3pool. However, additional whitelistings have shown that whitelisted basepools do not automatically become liquidity sinks. Rather, their TVL seems to be market-driven in the same manner as typical pools.

With whitelisting removed, new stablecoin issuers are likely to continue to use currently preferred basepool to benefit from their large and generally “sticky” liquidity. However, removing the whitelisting restriction will facilitate novel developments for those wishing to implement new approaches, and allow market forces to dictate new basepool preferences if they arise.

Finally, it is worth noting that the current whitelist procedure can already be circumvented by using an LP token as a pool asset and using its virtual price as an oracle. However, this approach would not benefit from the clean UX of “proper” metapools, since users would have to manually trade and deposit/withdraw to/from the LP token.

Specification:
This proposal requires deploying a new admin contract that allows the add_base_pool method to be used permissionlessly. Other method safeguards (no rebasing tokens, no native tokens) would be retained.

If this “temp check” is received favorably, the specific implementation will be prepared for review and formal vote. Any necessary UI updates would be prepared by the Curve UI team.

For:
Makes metapool creation more permissionless and flexible

Against:
May pull liquidity away from current basepools

7 Likes
#2

Actually great to see this proposal as we Napier Finance had planned to do such a proposal

I believe the permission-less base pools will significantly expand Curve’s design space, leading to exponential growth in that ecosystem

1 Like
#3

permissionless is the way! i support this, great proposal @nagaking

2 Likes
#4

I have tremendous respect for nagaking and the team. Thank you very much for all that you do!

While I agree there was some gatekeeping for many aspects of Curve in the earlier days, most noticeably gauges, this is all very much in the past. Much has been streamlined and is no longer onerous. There is very much a “rising tide” mentality embraced by all regular governance participants.

The FRAX/pyUSD, 3payLLama, and PayPool basepools were all voted in quite seamlessly and without fanfare.

For example, PayPool started as a regular pool and it was after discussion and contemplation that it was proposed and then consequently voted in as a basepool.

For now, I do not see the issue with other protocols adding pools, finding PMF, and then later voting those pools in as basepools as the needs arise or evolve.

1 Like
#5

Its a fair point that the whitelisting process is not hugely onerous at this point, and for the typical use case you’ve outlined above, arguably not “too much to ask”. Still, my mindset is that everything should be as permissionless as possible, unless there is some significant risk/downside to doing so. My sense is that there is no such risk/downside here.

Another factor to consider is that there is a huge unexplored design space that could benefit from meta-pool architecture, but for which the basepool doesn’t really operate as a “privileged” component. For example, imagine you want to launch a three asset pool with two assets that are tightly correlated, and one asset that is more volatile. It might make sense to launch a basepool with high A for the tightly correlated assets, and a metapool with the more volatile asset with lower A and/or higher fee. The metapool architecture allows you to “partition the variance” across assets in a liquidity-efficient way. Another simple example might be that you just want to launch a pool that is 50%/25%/25% across the 3 assets.

In those exampes, I don’t think the basepool is operating in a privileged way: in fact it may only serve as a basepool to that one particular metapool. For those types of use cases, it seems like gathering support, waiting for 1 week vote, etc. doesn’t make as much sense.

4 Likes
#6

Thank you, nagaking! Really appreciate you taking the time to broaden my horizons.

2 Likes
#7

I think the flexibility you mentioned of base pools giving a subset of an LP distinct parameters would be a really exciting unlock.

My only concern would be does having more basepools have impacts on the cost of routing in the same vein that more assets in a lending pool makes the whole lending pool more expensive?

I assume no, but figure I’d confirm.

2 Likes
#8

That’s a good question. In general, metapool trades are slightly more expensive than plain pool trades because they require trade + LP token withdrawal. But, this cost would not increase unless you had a nested design that required multiple levels of withdrawals. That kind of thing is probably infeasible on mainnet, but could make sense in some rare cases on L2. Some UI development would be required to support it.

2 Likes