HAPI Governance Protocol

What is HAPI?

Read more about HAPI here: https://www.hapi.one/

HAPI authority committee

HAPI authority committee (HAC) is an organization consisting of members of the HAPI team and external trusted third-parties that are responsible for proposal execution.

Proposal lifetime and voting

A new post on a governance portal should be created for every stage of proposal: http://gov.hapi.one/.
Post must meet requirements listed below. Posts that don’t meet requirements will be deleted by moderators.

Posts for proposal stages must be created sequentially. If the proposal post hasn’t passed previous stages, it will be deleted by moderators.

Voting for a proposal is conducted via Snapshot service on Ethereum blockchain in a space dedicated to HAPI: hapione.eth. Exact parameters of a proposal on Snapshot depend on a particular type and stage, but here are the basic rules:

  • Proposal must be a single choice vote
  • Proposal must contain an option to not change anything
  • Proposal must be conducted in within two weeks after creation

General proposal requirements

Proposal title must contain:

  • Proposal stage in square brackets (i.e. [PROBE])
  • Brief proposal description

Proposal body must contain:

  • Detailed proposal description
  • A link to pull request at Github (if applicable)
  • List of voting options
  • A link to proposal page at Snapshot

Proposal types

Type 1: Changing smart contract logic

Proposals of this type are the most important ones, as they have the biggest impact on infrastructure. They are responsible for business logic adjustments.

Stages:

  1. PROBE - low threshold voting to detect general interest in a proposal.
  2. IMPL - medium threshold voting for a particular set of changes that should be implemented.
  3. DEPLOY - high threshold voting to deploy changes to the smart contract.

Type 2: Adjusting smart contract configuration

Proposals of this type are responsible for basic smart contract configuration adjustments: reward rates, thresholds.

Stages:

  1. PROBE - low threshold voting to detect general interest in a proposal.
  2. DEPLOY - high threshold voting to apply changes to the smart contract configuration.

Type 3: Reporters and data providers management

This type of proposal is very important for the ecosystem to welcome new data providers and punish the bad agents.

Stages:

  1. DEPLOY - decision is made in a single stage with a previously decided threshold.

Type 4: Data regulations

This type of proposal does not impact onchain infrastructure directly, but governs Oracle data sourcing algorithms and approaches, as well as support of different networks.

Stages:

  1. PROBE - low threshold voting to detect general interest in a proposal.
  2. IMPL - medium threshold voting for a particular set of changes that should be implemented.

Type 5: Procedural changes

These proposals are meant to modify the HAPI Governance Protocol itself. All positively voted changes must be reflected in this document.

Stages:

  1. PROBE - low threshold voting to detect general interest in a proposal.
  2. IMPL - high threshold voting for a particular set of changes that should be implemented.

Type 6: Roadmap changes and adjustments. Protocol implementations

These proposals mostly are used to indicate community’s general interest in HAPI being integrated on the not yet announced or implemented blockchains. This type of proposal can also be used to signify the community’s initiative and willingness to adjust the announced Roadmap.
The proposals of this type are exclusively used as an indication of the overall community’s sentiment.

Stages:

  1. PROBE - low threshold voting to detect general interest in a proposal

Type 7: Address risk score and/or category amendment

These proposals are used to amend risk scoring or category for an address (or multiple addresses of the same case) based on evidence that shows that existing data is obsolete or incorrect.

Stages:

  1. IMPL - medium threshold voting for a particular risk score or category to be assigned to the address (or set of addresses).

Type 8: Token related changes including liquidity transfer, utility implementation and other potential changes to the tokenomics or token related activities

This type of proposal refers to any changes related to the tokenization of the HAPI Protocol as well as any adjustments to the liquidity on Decentralized Exchanges.

Stages:

  1. PROBE - low threshold voting to detect general interest in a proposal.
  2. IMPL - high threshold voting for a particular set of changes that should be implemented.

Proposal execution

After a successful vote on a proposal, it is up to the HAC to enroll the proposed changes to the production environment within a two week period after final proposal vote. The resulting transaction(s) hash must be posted on the proposal’s page.

3 Likes