VIP Gauge Voting
To decide how much of the total Weight Pool rewards are distributed to each minitia 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:
Voting Power Snapshot Submission
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 minitia 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 minitias they prefer. Stakers can allocate their entire voting power to a single minitia'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 minitias:
| User | Total Voting Power |
|---|---|
User 1 | 30% |
User 2 | 50% |
User 3 | 20% |
Each user decides to vote on the gauges as follows:
| User | Minitia 1 Gauge | Minitia 2 Gauge | Minitia 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 minitia.
After the voting period ends, the final Weight Pool reward distribution is calculated as follows:
| Minitia | Percentage of Total Rewards |
|---|---|
Minitia 1 | 55% |
Minitia 2 | 40% |
Minitia 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
the snapshot in the challenge proposal is used for this cycle
the Snapshot Submitter is replaced by the challenger
the challenger receives their INIT deposit back
Last updated
