The Voting Process

All esVSP tokens are eligible to participate in Vesper governance votes. VSP holders can acquire esVSP by locking their tokens.

Within Vesper, token-locking users will receive esVSP, enabling them to vote on various pool parameters through Vesper Improvement Proposals (VIPs). This includes many different decisions such as strategy proposals, asset inclusions, protocol-specific matters, and more.

There are two types of votes: on-chain and signal. VIPs can be introduced as a signal or on-chain vote. Initially, most voting will comprise of signal voting through Snapshot. Over time, more and more votes will be executed on-chain with executable code, ultimately relinquishing all administrative responsibilities and controls directly to the esVSP holders.

Signal Voting

Signal voting through Snapshot is a casual process, with the outcome being executed in good faith of the sentiment of voters. Initially, only whitelisted "core" addresses are permitted to create snapshot proposals.

Voting weight on Snapshot is determined by a user's esVSP balance. esVSP represents a user's locked VSP tokens plus a boost multiplier based on their lock duration. The longer a user locks their VSP (up to 2 years maximum), the higher their voting power will be, with a maximum multiplier of 4x. More here.

Snapshot requires a block number to poll balances, which will be estimated at three hours prior to the start of the vote. Snapshot votes run for 72 hours in length.

Votes require at least 30,000 esVSP voting in favor with majority approval to meet quorum and pass. This quorum requirement may increase over time as esVSP supply increases and holders become more accustomed to voting.

*VSP holders may still vote on Snapshot with VSP if they wish.

Proposal Introduction (Off-Chain)

Proposals begin by being published on the Vesper forums to encourage community discussion and feedback, enable a deeper understanding of the proposal, and prepare users for the upcoming voting period. A proposer must hold at least 25,000 esVSP to create a proposal on-chain, and any proposals that go directly on-chain without having been posted on Vesper forums for at least 7 days before voting begins will be vetoed.

Proposal Creation (On-Chain)

Following the forum discussion, the proposal can be introduced on-chain. Alternatively, users have the option to initiate the proposal on-chain at the same time as the forum discussion. However, this on-chain proposal creation needs to occur at least 7 days prior to the beginning of the voting period. The on-chain proposal will remain in the 'proposal stage' for 1 week.

The propose function in the VesperGovernor contract can be called by a proposer who has at least 25,000 esVSP tokens (as defined by proposalThreshold()). For more details or to interact with the governance contract, visit the Vesper DAO governance page on tally.xyz. Once a proposal is created, it will transition to a PENDING state until the voting begins.

Voting Phase

The voting will begin after a votingDelay() of 7 days. During the votingPeriod() of 3 days, proposals will be in an ACTIVE state, and users will be able to cast their votes FOR or AGAINST. A snapshot of voting power will be taken and will no longer be able to be delegated or transferred.

For a proposal to be successful, at least 4% of the total voting power must participate in the vote, determined by the quorum function. In order to achieve the required 4% quorum for a proposal, the total voting power is calculated by adding the VSP supply to the esVSP boost supply, then subtracting the VSP balance locked in the esVSP contract to avoid double counting. If a proposal passes, it will change to a SUCCEEDED state. If not it is marked as DEFEATED.

TimeLock

A SUCCEEDED proposal can be queued and will be executed after the minDelay() of 2 days. The validation and execution of the proposal is performed by the timelock executor. A successfully executed proposal state is EXECUTED. If a queued proposal has not been executed before expiration, then the proposal state is CANCELLED.