VIP Gauge Voting

To decide how much of the total Weight Pool rewards are distributed to each rollup in a given stage, a gauge weight voting process is used. This is similar to the one pioneered by Curve Finance for use with their liquidity pools.

​

Voting Cycles

Voting on VIP gauges occurs at regular intervals called cycles. Every VIP-whitelisted rollup has a “gauge” that determines the ratio of total Weight Pool rewards it can receive. INIT and Enshrined Liquidity stakers can then use their voting power to increase the weight of the gauges for their preferred rollups. They can allocate their entire voting power to a single rollup’s gauge or distribute it across multiple gauges. All gauge voting occurs on Initia L1.

​

Gauge Voting Power

For VIP Gauge Votes, a user’s voting power depends on their staking position. For INIT staking, their VIP voting power matches their voting power in the Initia L1 governance. However, for Enshrined Liquidity staking positions, an adjustment factor is applied to their voting power. This adjustment factor varies for each staked LP token pair.

​

Example Scenario

Consider a case with 3 users and 3 rollups:

User	Total Voting Power
User 1	30%
User 2	50%
User 3	20%

Each user decides to vote on the gauges as follows:

User	Rollup 1 Gauge	Rollup 2 Gauge	Rollup 3 Gauge
User 1	10%	15%	5%
User 2	25%	25%	0%
User 3	20%	0%	0%

*Percentages represent the portion of each user’s total voting power allocated to each rollup.

After the voting period ends, the final Weight Pool reward distribution is calculated as follows:

Rollup	Percentage of Total Rewards
Rollup 1	55%
Rollup 2	40%
Rollup 3	5%

In this case, the Weight Pool rewards for the cycle will then be split 55:40:5.

​

Challenging Snapshot Submission

In case of incorrect or malicious Snapshot Submissions, anyone can challenge the submission by submitting a new snapshot. To do this, they need to submit a challenge proposal to the gauge contract and include the following information:

• Merkle Root: The merkle root of the correct snapshot
• API URI: An API endpoint that can prove that the new submitted Merkle Root is valid
• Snapshot Height: The block height at which the snapshot was taken (needs to be the same as the original snapshot submission)
• Challenge Deposit: Proposal deposit in order to start a challenge proposal, paid in INIT tokens. INIT tokens will be returned to the challenger if the proposal was successful.

​

Challenge Proposal Timing

Within an cycle, a challenge proposal can be made any time after the original Snapshot Submission, while leaving enough time for the challenge proposal to be voted on.

For example, given

• cycle duration: $10$ units
• Snapshot submission time: $t = 1$
• Challenge proposal voting period time: $3$ units

Therefore, a challenge proposal can be made anytime between $t = 1$ and $t = 10 - 3 = 7$.

​

Voting on Challenge Proposals

Once submitted, users can start voting on the challenge proposal. Eligible voters include those who participated in gauge voting during the previous cycle, with each voter’s voting power on the challenge proposal equal to the total voting power they used to vote on the gauges during the previous cycle.

For example, if a user has 100 total voting power in the previous cycle but only 50 of it was used to vote on the gauges, their voting power on the challenge proposal would be 50.

If the “Yes” votes on the challenge proposal passes the quorum set within the challenge voting period, then the proposal is successful and

1. the snapshot in the challenge proposal is used for this cycle
2. the Snapshot Submitter is replaced by the challenger
3. the challenger receives their INIT deposit back