System Governance and Ability to Shape Cybersecurity Space Together

On the path of creating a decentralized autonomous system that will operate on the basis of community-defined development and subsist on the communal efforts, it’s mandatory to establish a type of governance protocol that will feature and incentivize interconnectedness. HAPI Protocol first and foremost is a neutral observer and reporter that is fitted according to the predetermined configurations of an entity using it. The protocol can be augmented in various ways that would define the all-encompassing institution of regulatory means (AML, CTF) and appendment of illicit addresses and unlawful liquidity manipulation into the database.

System governance will include adding new organizations of different kinds (incident reports, fund trackers, possibly government structures that can sanction individual's assets based on international laws) to network, management of reward structure, and case-by-case courts.

The governance structure of HAPI will consist of a committee. The committee is an inner circle of decision-making. HAC (HAPI Authority Committee) is one of the cogs in the governance body that consists of members of the HAPI team and external trusted third parties that are responsible for proposal execution.

The main voting power within the protocol is concentrated in the native token of the protocol - HAPI. HAPI token essentially is used as a vote delegation tool and each participant is able to delegate their vote accordingly.

Each proposal can be divided into stages and types. Each stage defines the process of approval. Every type reflects the complexity of an alteration in question.

Stages:

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

IMPL - medium threshold voting for a particular set of changes that should be implemented.

DEPLOY- high threshold voting to deploy changes to the smart contract.

Type 2: Adjusting smart contract configuration

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

Stages:

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

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:

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

Type 4: Data regulations

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

After a successful vote on a proposal, it is up to the HAC to enroll the proposed changes to the production network within a two-week period after the final proposal vote.

Each participant is able to submit data on the address deemed to be fraudulent. By issuing a proposal and supplying it with enough evidence of a given address being related to the malicious activity, a consummated verdict can be enacted. If a verdict is positive and the proposal is assented to, the address is moved to the database of HAPI SC and flagged as risky. Submission of an address for examination requires a certain amount of HAPI to be proposed. This is implemented for two reasons. Firstly, to avoid a deluge of addresses and time-consuming effort of sifting through each and giving it a respective appraisal and, secondly, to ensure a reward structure for validators within the governance system.