[CL]: cannot add cl full range asset to superfluid without spot price

[czarcas7ic]

Background

CL pools act differently than balancer pools in that we don't require a position to be created when creating the pool. Because of this, it is possible for CL pools to have no spot price. Without a spot price, the CL denom is unable to be added as a superfluid asset, since we are unable to determine the underlying osmo to synthesize for superfluid staking.

Suggested Design

We need to agree on this, but I think we should just make it a requirement to create an initial position when creating a CL pool. This rids us of this odd edge case, as well as any other future issues we may come across due to this.

Acceptance Criteria

TBD

[p0mvn]

This is not a launch blocking issue and IMO can be changed in a future upgrade. To limit the scope and focus on the remaining blockers, I'd like to propose that we keep this issue but assign it a low priority for now

[czarcas7ic]

@p0mvn the problem is that if we don't implement this (which I think should be an easy lift), we will have to work around it in some way in the upgrade handler in order to give the pool a spot price before adding the cl liquidity share as a superfluid asset

[p0mvn]

Worst case we can create a separate gov prop to add an SF asset after the upgrade.

There are quite a few tests that rely on the initial position being created separately from the pool creation

Given the likely breakage, I think this has a high likelihood of becoming a 1-2 day lift on top of verifying all edge cases in review.

I'm all for investigating and/or addressing this after we complete all outstanding launch blockers. However, I don't think this issue has to be addressed prior to achieving our goal of merging all launch blockers this week.

Someone can do it while we all are doing an internal review, right before or even during the audit

[czarcas7ic]

Yeah that sounds good to me! The only problem I see with that worst case scenario is then we would need to block all migration messages until the superfluid asset was approved a week after upgrade. To circumnavigate all of this what we could do is, in the upgrade handler, get the TWAP of the balancer pool we are migrating from, create a single full range position with the module account that reflects that TWAP, and then everything else should be good from there.

Would like to discuss this and potentially other options on our next CL call.

[p0mvn]

Wait until everything else in v16 scope is addressed. If we don't get to it this week, let's not do this for v16 scope reasons

[p0mvn]

@czarcas7ic do you think we still want this addressed or can this be closed?

[czarcas7ic]

Yeah this can be closed, it really only matters when pools are permissioned which should end soon