Governance Process Update

General Protocol
1

Introduction

Since Hearth Upgrade is happening soon, which features a brand new staking infrastructure, we will take the opportunity to also update the token used for governance and formalize the governance process. The proposal outlines the general framework of Vesta’s governance in the immediate term.

Specification

Given that Vesta is inherently a liquidity protocol and that we want to ensure that the protocol rolls out successfully, we aim to strike a balance between being fully decentralized and nimble at the same time.

There’s two path when it comes to protocol modification.

  1. Emergency Change
  2. Change via Governance Vote

Emergency Change

The Emergency Change path enables quick decision-making in the event of critical bugs or necessary fixes that require immediate action.

If the fix can be announced before the implementation, it would be done through Vesta’s social media channels and website to allow every users of the protocol to acknowledge the upcoming improvement. However, quite often announcing the change ahead of time may cause harm to the protocol. In that case, a post-implementation announcement, along with a justification for the change, would be posted as soon as possible.

The Emergency Change path ensures that critical bugs and necessary fixes can be addressed quickly and efficiently, while also maintaining transparency through public announcements of any changes to the protocol.

Change via Governance Vote

Any other changes to the protocol will go through governance voting.

Process

Governance may make changes to the protocol by following a three step process:

  1. RFC
  2. Discussion Period
  3. Snapshot Vote

RFC

Individuals must request changes to the protocol by writing a Request for Comments (RFC) on Curia. The primary objective of an RFC is to engage in discussions with members of the community and obtain feedback regarding the proposal. Anyone may write and post a RFC, provided it complies with the following guidelines:

  1. Concise and clear title beginning with the acronym [RFC]
  2. The following structure applies:
    • Motivation
    • Objective
    • Proposal Details
    • Additional Information (non-mandatory)

RFC Guideline

  • Specific: the RFC must address a single improvement.
  • Complete: the RFC must provide sufficient details and specifics.
  • Clear: the RFC should be written in an understandable language, without conflicting or ambiguous interpretations.
  • Brief: the RFC should be concise and to-the-point, only including the essential information necessary to convey its objectives.

Discussion Period

By default, an RFC remains open for 7 days before moving to the following step of the governance process. During this period, participants are encouraged to post their comments and share their thoughts to improve the proposal. At the end of the 7 days, Vesta core contributors should address all concerns and replies, and make a decision as to whether or not the RFC should proceed into a Snapshot vote.

There will be three outcomes at the end of the discussion period:

  1. Proceed with voting.
  2. Continue discussion: if the core contributors sees valid reasons for extending the discussion, such as the need for clarifying further or waiting for a external risk report, then the discussion shall be extended.
  3. Closed: if the RFC receives no attention or not enough support, then the RFC is closed.

Snapshot Vote

Once an RFC passes the discussion period, it would be moved into Snapshot voting. Snapshot is the last step of the governance process.

Some changes are simpler than the others, and so they will have a faster turnaround time relative to a full-fledged proposal. There are two specific types of proposals that have expedited treatment.

  • Interest rate change halt
  • Parameter modification

Any other types of proposal, such as collateral collateral addition/cancellation, feature upgrades, etc, fall under the Full Proposal category.

The Snapshot stage would have the following specifications:

Interest Rate Change Halt Parameter Modification Full Proposal
Voting duration 9 hours 72 hours 120 hours
Delay None 24 hours 72 hours
Quorum 2% of float: 300k 2% of float: 300k 10% of float: 1.4m
Proposition threshold 0.5% of float: 70k 0.5% of float: 70k 2% of float: 300k
Grace period None 24 hours 48 hours
Voting result >70% support will pass >50% support will pass >50% support will pass

Float is defined as the amount of VSTA circulating, which could be queried at https://www.coingecko.com/en/coins/vesta-finance

Once the vote passes, the proposed changes shall be implemented. In case the result of the vote is Unfavorable, the proposal will be closed and effort to revive the proposal would need a new RFC.

Token Used for Voting

  1. Nominal VSTA amount in staked VSTA LP
  2. VSTA staked in VSTA staking module
  3. bVSTA

Execution of protocol modification: multi-sig

Execution is done via a multi-sig with 4 individuals, which is composed of two team members and two advisors. The advisors will be solicited and published later this month. Once a consensus is reached, members of the Committee have to sign the on-chain transaction and the change can be pushed to the protocol.

In the near term, we will move to a fully on-chain governance system to achieve full decentralization of the protocol.