Stablecoin Governance
HLUSD 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.
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:
./hela managest propose proposal.jsonView proposals: After the proposal is broadcast, the users can show the proposals with the command:
./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.
./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.
Last updated