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 gauge voting is similar to the one pioneered by Curve Finance for use with their liquidity pools.

The gauge voting flow then consists of two steps:

1. Voting Power Snapshot Submission
2. Gauge Voting

Voting Power Snapshot Submission

Before the gauges can be voted on for a given cycle, a governance-assigned party known as the Snapshot Submitter first snapshots and submits the voting power of all of the individual stakers on the Initia L1 at a certain block height.

Gauge Voting

Once the voting power snapshot is taken, the gauge voting process begins. Each VIP-whitelisted rollup has a “gauge” that determines the ratio of the total Weight Pool rewards they are eligible to receive. Stakers with staking tokens on Initia L1 use their voting power to increase the weight of the gauges for the rollups they prefer. Stakers can allocate their entire voting power to a single rollup’s gauge or spread it across multiple gauges.

All gauge voting is conducted on Initia L1.

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, while including 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