[VS Incentives]: Investigate whether creating gauge ref keys is necessary for group gauges

[AlpinYukseloglu]

Background

Investigate whether ref keys need to be created for group gauges. It seems this was added without fully exploring/understanding whether it is necessary so it should be double checked.

Suggested Design

• Confirm necessity of ref link creation at end of CreateGroupGauge

Acceptance Criteria

• Issue is settled and captured in comments & tests

[p0mvn]

As it currently stands, we have a Group and a 1:1 mapped group Gauge after the rename in #6432 is completed.

Previously, we have discussed and converged on the need for implementing lifecycle management via #6434

Gauge ref keys are focused exactly on this lifecycle - (upcoming, active, finished).

However, I propose refactoring the helpers so that we are able to write group Gauge ref keys into separate store prefixes. This would allow us to avoid having redundant reads and skipping of the group Gauge while distributing the regular gauges:

osmosis/x/incentives/keeper/distribute.go

Lines 534 to 537 in 74c396a

	// Do not distribute if LockQueryType = Group, because if we distribute here we will be double distributing.
	if gauge.DistributeTo.LockQueryType == lockuptypes.ByGroup {
	continue
	}

This decoupling will also simplify gauge management overall, reduce risks, and decrease code areas that require testing.

Now, the only open question remains to be whether we need to manage the lifecycle of Groups themselves since these are 1:1 mapped to group Gauges. In the latest discussion, we made a decision to lift up reading Groups from state from AllocateAccrossGauges (see this). We predicted that it might be redundant to read all Groups that have become finished

[p0mvn]

For speed of delivery, I propose the following:

• Groups do not have a lifecycle. If Group's underlying group Gauge has finished, the Group becomes unusable
• We gate Group creation by a high fee and governance

• As a result, Group creation can either be achieved via high price r waiting for 5 days in voting

• Similar to CL pools, we create a sub-dao that can bypass governance and the fee for ease of management of internal incentive

This approach will ensure that there are no spam Groups created, requiring many after-epoch iterations. Additionally, it will reduce code complexity from having to manage the lifecycles of both Groups and Gauges.

If we end up having too many Groups even with the restrictions, these can be pruned in the upgrade handler.

[p0mvn]

more context: all external incentives use non-perpetual gauges. If we want external incentivizers to support, we should allow non-perpetual.

If we go with non-perpetual and no pruning, should leave opportunity to prune in the future

Explore pruning both groups and group gauges, keep separate store indexes:

• high group creation fee
• governance
• subdao to bypass both

[p0mvn]

Conclusions from this issues have been discussed. The outcomes are transferred into TDD and follow-up issues.

Next step: #6434

Closing this