# Stablecoin Governance HeLa introduces **HLUSD**, a stablecoin with **on-chain governance** to ensure transparency, decentralization, and community-driven decision-making. This document explains how governance works, what roles exist, and how developers can interact with the governance system. Most stablecoins today are governed **centrally** (by one company or team). HeLa changes this with a **decentralized voting system**, where decisions about minting, burning, whitelisting, blacklisting, and configuration are made **on-chain by multiple roles**. Key Features: * **On-chain proposals & voting** for all actions. * **Multiple roles** for checks and balances. * **Transparent process** (all actions recorded on-chain). * **Community insurance fund** as a safety net. Before you begin, please ensure that you have set up the command line wallet with the appropriate network and default account. ### Chain Initiator Chain Initiator is an HeLa address (`hela01qrmyx4d...`), hard-coded in `paratime/src/libs/chain_initiator` field. Its primary function is to initiate the chain roles, as defined below. Please note that the Chain Initiator can only be used once, and after initiation, the address will be set to that of a normal user. Subsequently, all roles management should be carried out through the propose-voting system. Currently, this action can only be executed via the command line using the following Command: ``` ./hela managest initowners [addr1 role1] [addr2 role2] ... ``` **Note** : Each address can only hold **one role**. If multiple roles are assigned, the **last one overrides** the previous. ### Roles : Roles define **who can propose** and **who can vote**. There are 12 kinds of roles defined in our system, which are as follows. | Role | Capabilities | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Admin** | Only admin can `propose` and `vote` for all other roles and config the values for `mintQuorum`, `burnQuorum`, `whitelistQuorum`, `blacklistQuorum` and `configQuorum`. | | **MintProposer** | Both mint proposer and mint voter can propose to mint stable coins to a `WhitelistedUser` user. | | **MintVoter** | Only mint voter can vote the proposals from the `MintProposer`, and only the `mintQuorum` is reached, the `mint` action can take effect. | | **BurnProposer** | Both burn proposer and burn voter can propose to burn stable coins from a `WhitelistedUser` user. | | **BurnVoter** | Only burn voter can vote the proposals from the `BurnProposer`, and only the `burnQuorum` is reached, the `burn` action can take effect. | | **WhitelistProposer** | Both whitelist proposer and whitelist voter can propose addresses to be a `WhitelistedUser` user, but this proposed address should not be `BlacklistedUser` user | | **WhitelistVoter** | Only whitelist voter can vote the proposals from the `WhitelistProposer`, and only the `whitelistQuorum` is reached, the `whitelist` action can take effect. | | **BlacklistProposer** | Both blacklist proposer and blacklist voter can propose addresses to be a `BlacklistedUser`, but this proposed address can only be a normal `User`. | | **BlacklistVoter** | Only blacklist voter can vote the proposals from the `BlacklistProposer`, and only the `blacklistQuorum` is reached, the `blacklist` action can take effect. | | **WhitelistedUser** | The `WhitelistedUser` can be the beneficiary address of minting and burning besides the functions of a normal user. | | **BlacklistedUser** | The `BlacklistedUser` can not send any transactions to change the state of the specific runtime, even query. | | **User** | Normal users can exercise general functions provided by our system, like transferring money, deploying smart contracts etc. | **Update:** All the voters' role can also raise proposals as proposers'. ### 3. Action The governance system supports **6 on-chain actions**. Each action is submitted as a **proposal** in JSON format, then voted on. #### a) SetRoles `SetRoles` action allows `Admin` to propose a role to some address, the proposal is like the following which should follow the json format (the role is in the snake manner, e.g., mint\_proposer, mint\_voter, burn\_proposer, whitelist\_proposer, blacklist\_proposer, whitelisted\_user etc.). ``` { "action": "setroles", "data": { "address": "hela01qq3slqgrp55hshh7znra4j9dskjvy55n6crgf0lk", "role": "admin" } } ``` #### b) Mint **Mint** `Mint` action allows `MintProposer` to propose minting specific amount `5000000000000000` to a `WhitelistedUser`. ``` { "action": "mint", "data": { "address": "hela01qrfp4gltu9h5433zm434mtvzezsrj3uytqts2x6x", "amount": "5000" } } ``` Note: HLUSD has 18 decimals. or the exponent for the runtime is 18, which means 1 HLUSD = 10^18 base units. #### c) Burn `Burn` action allows `BurnProposer` to propose burning specific amount `5000000000000000` from a `WhitelistedUser`. The proposal json file is similar with the Mint one. #### d) Whitelist `Whitelist` action allows `WhitelistProposer` to propose whitelisting some address. ``` { "action": "whitelist", "data": { "address": "hela01qrfp4gltu9h5433zm434mtvzezsrj3uytqts2x6x" } } ``` #### e) Blacklist `Blacklist` action allows `BlacklistProposer` to propose an address with a normal `User` role to be a `BlacklistedUser`. The proposal json file is similar with the Whitelist one. #### f) Config **Config** `Config` action allows `Admin` to propose new values for `mintQuorum`, `burnQuorum`, `whitelistQuorum`, `blacklistQuorum` and `configQuorum`, at least one value is required in the data field, otherwise, this proposal will be declined. ``` { "action": "config", "data": { "mint_quorum": 90, "burn_quorum": 90, "blacklist_quorum": 90, "config_quorum": 90 } } ``` ## Proposal and Voting ### Propose: All proposals can be made with the following command: ```bash ./hela managest propose proposal.json ``` View proposals: After the proposal is broadcast, the users can show the proposals with the command: ```bash ./hela managest show [number] ``` By default, the latest proposal will be displayed if the `[number]` is left blank. ### Vote: The voters with the specific role can vote proposals with the following command: `./hela managest vote [proposal ID] [options]`. Each proposal gets a unique ID, which can be found by the `./hela managest show [number]`command. The `[options]` field can be `yes`, `no` or `abstain`. Rules: * Only correct role holders can vote. * Proposal passes if quorum (threshold %) is reached. * \[ Update ] Voters can not vote for the same proposal many times. ```bash ./hela managest vote [proposalID] [yes|no|abstain] ``` The users can look up the vote result by the same `./hela managest show [number]` command, where the latest result of the voting is shown in the `Results` row. *** ## Insurance on HeLa Chain HeLa also creates a **community-controlled insurance fund** to protect users from unexpected disasters (like hacks). #### How it works: * Every time you pay a transaction fee, **90% goes to compute nodes**, and **10% goes into the insurance fund**. * The fund is governed by the **HeLa DAO (community)**. * In case of a loss event: * A **community proposal** can be submitted to use funds. * If passed, funds can **compensate affected users**. **This adds an extra layer of protection for everyone** using HeLa. ### Countermeasure to Stablecoin Devaluation What if Stablecoins Lose Value? Here’s a real problem, **fiat-backed stablecoins** like HLUSD are pegged to dollars, but dollars **lose value over time** due to inflation. This creates two issues: * Compute nodes receive **less real-world value** over time. * Insurance fund assets slowly **devalue**. ### HeLa's Fix : The **HeLa DAO** can **vote to adjust transaction fees** over time. * If HLUSD becomes weaker, fees can be **raised** slightly to keep node rewards fair. * This helps maintain a balance between **cost for users** and **incentives for validators**.\